|
|
|
|
az Ifekkel nagyon vigyázni kell, két féle if van
az egyik az amikor a valoszinüség a 2 állapot között fifty-fifty, na ekkor már baj van , ez tud lassitani cefetül
a másik if pl amik ciklusoknál van az egyik állapot 90%> a másik kicsi
ilyenkor az utasitás pipelineban nem keletkeznek lyukak, ez szabadon használhato
persze azokon a procikon ahol mindkét ág végrehajtodik nem számit, nemtudom az uj intelek ilyenek e régota leálltam a követéssel
konzolon általában nem ilyen okos procik dübörögnek, bár relativ mit nevezünk okosnak 
|
|
|
|
érdekes egy algoritmus, de nem hatékony
mért nem jo dinamikus objectekre? csak tudod valamiröl hogy van vagy nincs
én ugy szoktam csináni hogy egy scenemanager felügyel mindent
és minden létezö object ID-t tartalmazza, ha valami megszünik törlödik
minden frame kirajzolás elött rendezés
|
|
|
|
Ezt a hozzászólást Asylum módosította (2008.04.26 18:12 GMT+1 óra, ---)
|
|
|
|
sok féleképpen lehet használni, engine-ben pl az objecteket lehet sorbarendezni, vagy pl az átlátszó polygonokat, stb...
|
|
|
|
ez ilyen edényrendezés féle nem? (valamikor én is tanultam) hasheléssel tényleg sokat lehet turbózni csak nem mindenhez lehet jó hash fv-t találni.
|
|
|
|
a radix alap, ha gyorsat akarunk irni, ha jol rémlik minimum 50-100-szor gyorsabb mint bármilyen más rendezö, , de ez nemcsak amiatt mert az algoritmus ennyire hatékony lenne
hanem mert stream olvasás kell hozzá, nincs véletlen elérés, optimizálhato pipeline szinten
és az algoritmus egyszerüsége folytán asm-ban szét lehet tuningolni
|
|
|
|
|
|
valahogy olyan hihetetlen hogy az egész rohadt számitogépet egy csomo ilyen kis vacak müködteti
és ráadásul strapabiro is többnyire
és hogy a programok is feszültségváltozásokbol állnak
|
|
|
|
több tranzisztor kell hozzá, a Cell-ben is csak 16 bites integer szorzás van , 2 menetben ugrik neki a drága , igaz hogy egyszerre 4 adatnak
|
|
|
|
hát ha a szorzást összeadással helyettesited az lassabb szerintem ugyanis a mod 2 maradékosztálytestben a szorzás is legalább olyan trivi mint az összeadás.
igazából nem értem h miért nem tudtak normális mul -t irni a processzorokhoz.
|
|
|
|
|
|
szeretnéd tudni, hogy hány müvelet egy logaritmus vagy egy exp?
|
|
|
|
a logaritmikus azonosságokat nem lehet használni? néha brutál gyors tud lenne
mivel a szorzásbol összeadás az osztásbol kivonás, a hatványozásbol szorzást csinál
exp(x*y)=log(x)+log(y)
exp(x/y)=log(x)-log(y)
|
|
|
|
sub eax, ebx
...
imul ...
asszem az imulnak nemmindegy hogy mi hol van
mov eax, [ebp+valami] ;indexet berakja
mov ecx, [esi+eax] ;tömb elemét berakja
szal szerintem az utóbbi gyorsabb de ezt csak igy hasból irtam
|
|
|
|
Melyik a gyorsabb: kivonás egy előjel nélküli byte típusú változóból majd az eredmény szorzása 4 byte-os lebegőpontos számmal (utóbbi tudom hogy lassú csak azt nem hogy mennyire) vagy egy 256 elemű előjel nélküli byte típusú tömb indexelése egy másik byte-tal (ez is lassú ha nincs cache-elve csak kérdés mennyire)?
Szerk: C opció: az első művelet MMX-el megoldva 8 byte-on egyszerre, a szorzás viszont két részletben (a szorzó le van bontva egy egész számra és egy osztóra ami kettő hatványa, az elsővel szorzok a második kitevőjével meg biteltolással osztok). Kiegészítésként megemlíteném hogy MMX-el nem tudok 1 byte-os számokat szorozni csak 2 byte-osakat és az eredmény is 2 bytenyi lesz szóval egy adag kombinálás kell mire a végeredményt megkapom.
Ezt a hozzászólást TheProGamer módosította (2008.04.18 08:39 GMT+1 óra, ---)
Reality is almost always wrong. - House
|
|
|
|
|
|
Ugyanezt csinálja az
Y = Y % 360
azaz modulo 2 pi 
|
|
|
|
Erről a modulo 2 pi-ről nem sok infót találtam
viszont egy kis fejtörés után sikerült 
Kód: while (Math::Abs(Y-X) > Math::Abs(Y-360-X))
Y -= 360;
while (Math::Abs(Y-X) > Math::Abs(Y+360-X))
Y += 360;
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
|
|
|
|
modulo 2 pi és müködni fog
|
|
|
|
Hi! Lenne egy (valószínűleg) egyszerű kérdésem. van egy X és egy Y változóm amik 1-1 szöget tárolnak. A loop folyamán az Y próbálja követni az X forgását az által hogy hozzáadok vagy kivonok belőle 1-et.
A problémám az hogy nem tudom hogyan lehetne úgy megcsinálni, hogy a legrövidebb úton kövesse az Y, ha a forgás során át kéne ugrani 360-ról 0-ra inkább teljes fordulatot tesz a másik irányba. Lehet hogy egyszerű kérdés, de én mindíg belezavarodok o_O
Jelenleg így néz ki a kód:
Kód: if(X > Y)
{
Y += time;
if(Y > X)
Y = X;
}
else if(X < Y)
{
Y -= time;
if(Y < X)
Y = X;
}
else
Y = X;
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
|
|
|
|
egy db gráf igen, lehet benne irányítatlan kör bár szerintem anélkül is megoldható.
amin még nekem is gondolkodnom kell, hogy ugye a transzformációk nyilván kombinálhatóak tehát pl.
forog -> Föld -> kering -> Hold
azaz a Hold forog is meg kering is tehát a mátrixokat valahogy kombinálni kell
a másik, hogy az anyagokat meg nem kombináljuk (igy ez nemis probléma)
a fényeket megint lehet kombinálni
szal vannak ilyen nyitott kérdések még
Ezt a hozzászólást Asylum módosította (2008.03.05 12:44 GMT+1 óra, ---)
|
|
|
|
Huh, ez scenegraph féle dolog, mi? Ez több fát jelent, vagy van valami általános gráfod, amihez mindent hozzá tudsz csatlakoztatni? Eléggé automatizált dolognak tűnik amúgy - erre ránézek.
|
|
|
|
nos hát igen rossz megoldás nálam is született már sok. én ugyan ennyire még nem tartok elöl de a következöképpen néz ki most:
vannak az erőforrások (mesh, textúra, effekt) ezekröl semmi plsuz infót nem tárolok.
vannak ezeknek megfelelö gráf csucsok pl. GeometryNode ehhez hozzá lehet kapcsolni egy mesh-t
vannak speciális csúcsok pl. TransformNode ennek gyerekként odaadok egy GeometryNode-t monjuk, és igy pl. forogni fog ha azt állitottam be. Ez eléggé memória takarékos megoldás szerintem. Fényeknek majd hasonloan lesz ilyen csúcsa, az anyagoknak szintén.
minden elntitásnak nem érdemes külön osztályt irni mert ugy 1) rengeteg osztályod lenne 2) még több objektum. meg pl. a kövek általában statikusak ahogy igy elnéztem a játékokat tehát beleépithetök a pályába.
egy csúcsnak ilyen általános függvényei vannak hogy pl. Draw() szerintem más nemis nagyon kell a mozgatásokhoz ott van a TransformNode.
a kamera szintén egy ilyen csúcs, rendereléskor innen indul el a bejárás.
gyakorlatban még ugy igazán nem teszteltem ezt a modszert szal vedd inkább csak egy ötletnek (de nagy része már implementálva van).
egyébként egy véletlenül talált VRML jegyzetböl jött az ötlet merthogy az pont igy oldja meg az egész bulit.
szerk.: ja a bejárás ugy történik, hogy paraméterben végigmegy egy akció objektum (ra mutató pointer) ami minden csúcsra végrehajt valamit, ez is elég gazdaságos.
|
|
|
|
Azt szeretném elérni, hogy minden objektum a gémben ugyanúgy elérhető legyen, függetlenül attól, milyen típus, egyelőre még csak kettő van, fal típus, meg fényforrás típus. A fal típusnak más változói (is) vannak, mint a fényeknek, de még ezután sokféle lehetne, pl npc-k, felvehető tárgyak, ilyesmi.
Mindegyiknek más adatstruktúra kell - nyilván más kell egy sziklának, meg egy embernek.
Jó lenne ezeket egy tömbben tárolni, sokmindent leegyszerűsítene.
Most plö a frustum-cullinggal szórakázok, és az minden objektumnak lekéri az AABB-jét, és megnézi, látszik-e.
Ha minden külön veszek, külön leszenk a kövek, fények, emberek stb., akkor mindegyikre meg kell írni mindent, pl a feljebb említett frustum-c-t is külön le kell futtatni mindre - kb ilyen esetben kéne tempate típust adni a fr-culling classnak (lehet nem is rossz ötlet!), minden objektumtípusra lenne egy példánya.
Az igazság az, hogy szeretném valahogy normálisabban megírni egyszer, mert rosszul már sikerült .
Ezen felül még van az, hogy minden objekthez tartozhat egy kis szöveg, ami kb. a script szerepét tölti be, amiben nevekkel lehet(ne) hivatkozni bármelyik objektumra, és generálna ott valami action-t, ha egy tömbben lennének, csak abban az egyben kellene keresni nevek után- mondjuk ez tán nem olyan nagy baj.
Még az jutott eszembe közepes megoldásként, hogy csinálok két fő irányvonalat, az egyik a sztatikus objektumoké, ezekből sokkal több van, a másik a dinamikus dolgok tömbje lenne, amit vituális cuccokkal lehetne bővíteni.
A sok tömb esetén viszont a két tömb közötti reláció lesz nehézkesebb, például, ha a szkriptek betöltésekor a neveket indexekkel akarom helyettesíteni, hogy ne kelljen közben keresgélni, akkor azt is meg kell mondani, melyik tömbben..
Lehet végül is ez lesz, talán jobb, mint a semmi (nemértekénehhez  )
|
|
|
|
hát ha közös erőforrásokat tudnak használni akkor vond őket össze valahogy...de ha konkrétabbat mondasz akkor talán tok mondani jobbat is.
|
|
|
|
Szerint-attack , ha van egy csomóféle objektum, aminek mind másféle adatstruktúra kell (más-más class), azt hogy érdemes megcsinálni, hogy egy tömbben legyenek, és könnyen le lehessen kérni a hasonló adataikat?
A legnyilvánvalóbb nekem a vituális fv-k lennének, minden egy alap class-ból származna, satöbbi.
De elég sok fv-hívás miegymás lenne velük (framenként több ezer akár), és biztos van gyorsabb módszer erre, mint ez.
Gondoltam arra is, hogy én foglalok le minden class példánynak annyi helyet, amennyi kell, egy mondjuk *void tömbbe, majd kényszerítem arra a típusra, amilyen, de sokféle class esetén ebből meg egy nagy switch-case blokk keletkezhet.
Van ezeknél gyorsabb/biztonságosabb?
|
|
|
|
Van egy ilyen probléma hogy scrollbar.
Ugye van egy sín amiben a gomb mozoghat, ezt elöre megmondjuk, hogy a kép melyik része legyen .
Amikor a képet átméretezem akkor nyilván a sínt és gombot is át kell, csak az a baj, hogy a kerekítési hibák miatt nem lesz pontos : /
oké látom a windowsban fix mérete van a scrollbarnak..de nincs mégis erre vmi algoritmus?
bár lehet azlesz hogy a szélessége fix amard és csak a magasságot lehet változtatni..szvsz kevesebb fejfájás...
vagy egy másik hogy a kép két szélét megtartom, a közepét pedig pumpálom mint a CSS...csak ez meg ugye lassúnak tünik...viszont nem fog torzulni a kép és a probléma is meg lenne oldva
Ezt a hozzászólást Asylum módosította (2008.01.11 15:22 GMT+1 óra, ---)
|
|
|
|
Hát, ha rajtam múlna, szívesen átadnám a helyem.
Van valami országos szintű tehetséggondozó program, és annak az egyik központja Győrben van.
Egyik szünetben lehívtak a titkárságra hogy kaptunk valami levelet és abban volt a meghívó meg a leírás. Hogy honnét szereztek rólam tudomást, arról a mai napig fogalmam sincs (a másik srác okés, mert besegített az e-napló fejlesztésébe és az bentvolt a Kisalföldben is).
Az interneten csak ezt találtam róla:
http://www.tehetsegpont.hu/96-15051.php
|
|
|
|
Nekem is küldhetnél 1 ilyen meghívószerűséget
|
|
|
|
[off]
nem is az én sulimban van az a szakkör 
hanem egy másik srác meg én kaptunk egy meghívószerűséget 1 másik iskolából...
[/off]
|
|
|
|
Én már azt hittem gaborlabor hirtelen ilyen májer lett.
Amúgy nekem is nagyon ismerős volt valamelyik OKTV-ről, és ahogy megnéztem, ha nem is pont ez, valami hasnló sokszor van OKTV 2. fordulón.
[off]Kár, hogy az én sulimban semmiféle számtech oktatás nem folyik, ill. ami van az egy vicc...[/off]
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
1ébként én is ilyen OKTV feladatnak kaptam tanártól, csak nekem nem volt mellé leírás mellékelve, csak oldjam meg  Mind1, igazából csak ezzel a feladattal volt gondom, meg egy geometriás feladattal, többivel megbírkóztam vhogy
|
|
|
|
Nagyon szívesen.
Az gondolom lerí róla, hogy nem én írtam. Mert nem én írtam...
Csak láttam, hogy felvetetted itt a problémát, és egyszer csak hirtelen eszembe jutott, hogy honnét olyan ismerős ez a feladat.
Én járok egy ilyen... "számtech-szakkör" szerűségre, aminek pont az a célja, hogy OKTV feladatokat oldunk meg, magyaráznak el, stb.
És ott volt ez a feladat is, és kaptunk egy doksit, amiben megvolt ez a leírás. Ez onnét származik.
Örülök, hogy hasznodra vált
|
|
|
|
Köszi h ilyen részletesen leírtad, mert bárhol próbáltam eddig normál leírást keresni din prog-hoz, nem találtam olyat, ami vmi normális példán keresztül érthetően el tudta volna magyarázni, mind úgy volt megírva, hogy azt tanár már elmondta v el fogja mondani, én meg magamtól tanulgattam, egészen az idei évig nem volt számtech tanárom. Szal köszönöm még1x
|
|
|
|
Megoldás:
Legyen {e1, . . . ,en} az ajándékok értékeinek egy felsorolása és jelölje E az összegüket. Feltehetjük, hogy A<=B. Mivel A+B = E,
ezért A a legnagyobb olyan szám, amelyre A<= E/2 és előállítható {e1, . . . ,en} egy részhalmazának összegeként.
Jelölje Fel az (A+B) div 2 értéket. Tegyük fel, hogy
A = ei1 +. . .+eik , i1 < . . . < ik
Ez akkor és csak akkor, ha
A−eik = ei1 +. . .+eik−1
azaz A−ei1 előállítható legfeljebb a első ik −1 (e1, . . . ,eik−1) szám v.m. részhalmazának összegeként.
Részproblémákra bontás:
Bontsuk részproblémákra a kiindulási problémát: Minden (X, i)(1<=X<=Fel,1<= i<=n) számpárra vegyük azt a részproblémát,
hogy az X érték előállítható-e legfeljebb az első e1, . . . ,ei szám valamely részhalmazának összegeként. Jelölje V(X, i) az (X, i)
részprobléma megoldását, ami logikai érték; V(X, i) = Igaz, ha az X előállítható, egyébként Hamis.
Kód: Program Testveri; Const
MaxN=100; {az ajándékok max. száma }
MaxFel=20000;{ Max. összeg }
Var
N,i,Osszeg,A : Word;
E:Array[1..MaxFel] Of Word; { az ajándékok értéki }
BeF, KiF: Text;
Function F(M : Word) : Word;
{ F(M) a legnagyobb olyan szám, amely <=M és előáll az E[1..N] számok
összegeként }
Var
V : Array[0..MaxFel] Of Boolean;
x,i: Word;
Begin
For x:=1 To M Do V[x]:= False; {inicializálás}
V[0]:=True;
For i:=1 To N Do Begin
{ V[x]=True <=> x előáll az első i szám összegeként }
For x:=M DownTo E[i] Do
V[x]:= V[x] Or V[x-E[i]];
End{i};
For x:=M Downto 1 Do
If V[x] Then Begin
F:=x;
Exit
End;
End (* F *);
Begin { Program }
Assign(BeF,’testveri.be’);
Assign(KiF,’testveri.ki’);
Reset(BeF); Rewrite(KiF);
ReadLn(BeF,N);
Osszeg:=0;
For i:=1 To N Do Begin
Read(BeF, E[i]);
Osszeg:=Osszeg+E[i];
End;
Close(Bef);
A:= F(Osszeg Div 2);
WriteLn(KiF, A,’ ’,Osszeg-A);
Close(KiF);
End.
Ha azt is meg kell adni, hogy az egyes testvérek mely ajándékokat kapják egy testvéries osztozkodást során, akkor nem elég
lineáris tömb, minden (x, i)-re tárolni kell a V(x, i) értékeket, hogy elő tudjunk állítani egy osztozkodást.
Kód: Procedure Osztozkodas(Const E:Ertekek; N: Word;
Var Db:Word; Var C :Megoldas);
Const
MaxN=100; {az ajándékok max. száma }
MaxFel=300;{ Max. összeg }
Var
N,i,Osszeg,A, F: Word;
E:Array[1..MaxN] Of Word; { az ajándékok értéki }
18
V:Array[0..MaxFel, 0..MaxN] Of Boolean;
i,X:Integer;
Begin{Osztozkodas}
Fel:=0;
For i:=1 To N Do Fel:=Fel+E[i];
Fel:=Fel Div 2;
For x:=1 To Fel Do
V[X,1]:=False; {az első sor, azaz V(X,1) számítása}
V[E[1],1]:= E[1]<=Fel;
For i:=2 To N Do {az i-edik sor,azaz V(X,i) számítása}
For X:=1 To E Do
V[X,i]:=(E[i]=X) Or V[X,i-1] Or
(X>E[i]) And V[X-E[i],i-1];
For x:=Osszeg Div 2 Downto 1 Do
If V[x,N] Then Begin
F:=x;
Break
End;
Db:=0; X:=F; i:=N { egy megoldás előállítása}
Repeat
While (i>0) And V[X,i] Do Dec(i);
Inc(Db); C[Db]:=i+1; {i+1 bejegyzése a megoldásba}
X:=X-E[i+1]; {X-E[i+1] felváltásával folytatjuk}
Until X=0;
End{Osztozkodas};
|
|
|
|
Először én is erre gondoltam de 1.: ez nem dinamikus programozás
2.: ha kipróbálod a példával, akkor az jönne ki, hogy: 52 45 (az optimális 48 49 helyett). Tehát továbbra is várom az ötleteket, hogy ezt mégis hogy a *** kéne DP-al megoldani...
|
|
|
|
Sztem először csökkenő sorba rendezed az ajándékok értékeit, majd utána sorban mész és mindig ahhoz a változóhoz adod az ajándék értékét, amelyiknek kevesebb az értéke
|
|
|
|
Hmm... sehogy sem tudok rájönni, hogy ezt a feladatot dinamikus programozással h kéne megoldani:
"Van 2 testvér és egy rakat ajándék [2;100] amiknek megvan az értékük [1; 200]. Ezeket az ajándékokat kéne úgy szétosztani, hogy minél egyenlőbb legyen és ki kell írni, hogy melyik testvér milyen értékben kapott ajándékot.
Pl. input:
28 7 11 8 9 7 27
erre ezt kéne adnia:
48 49"
|
|
|
|
Lenne egy kérdésem azok számára, akik egy kicsit is jártasabbak az algoritmusok világában.
Szóval az a feladat, hogy egy gráfban, meg kell határozni azokat a pontokat, amelyket egyessével kiszedve, még összefüggő a gráf (tehát bármely két csomópontot összeköti legalább egy útvonal.) Irányítattlan gráfról van szó, és szomszédsági listával van megvalósítva a gráf.
Jelenleg azt a módszert használom, hogy csinálok egy mélységi keresést, majd a az elérési idők mellett meghatározom az egyes pontokhoz tartozó apát, valamint van L(p) is, ami annak a csúcsnak az elérési idejét tartalmazza, amelyet egy p gyökerű részfából elérhetőek legfeljebb egy visszaélen keresztül. Ezek közül az értékek közül is a legkisebbet tartalmazza.
A gond ezzel, hogy ha kiszedek egy pontot, akkor újra meg kell vizsgálni az egész gráfot, hogy nehogy olyat a szedjek ki, ami esetén már nem lesz összefüggő.
Hogyan gyorsíthatnék ezen az algoritmuson? Ötletem sincs
Eredetit, újat és ötleteset - bárhol és bármikor... avagy nem vetem meg az ágyat, mert megvetem.
http://cow.isgreat.org
|
|
|
|
Unix alatt van truncate függvényhívás, meg régen (dos?) alatt volt olyan trükk - ha jól emlékszem -, hogy 0 hosszal kellett appendelni adott pozícióban.
|
|
|
|
Idézet
ShAdeVampirE :
pseudo kóddal:
Kód: if(last_existed_file_end != -1)
{
if( this_file_is_not_deleted )
{
copy(this_file, last_existed_file_end);
}
}
Alapból last_existed_file_end = -1, de ha már megvan, hogy hol törölsz file-t akkor onnantól mindíg a legutolsó létező (nem törölt) file végét mutatja, ahova be lehet illeszteni a következő létező file-t. Ezzel egyszerre akár több file is törölhető, mert ha törölni akarunk egy file-t, akkor mikor elérünk a file-hoz csak annyit kell tenni, hogy nem számoljuk ki a végét, ugyan annyin hagyjuk az offset-et és "ráírunk". Ez 1etlen dolog, ami itt gond lehet az a file végének törlése, mert ha mindent előre "tolunk" attól még a file vége megmarad és 2x is a file-ban lesz. Ezt utána talán átméretezéssel lehetne megoldani, de ezt nem tudom, hogy meg lehet e oldani.
Jaja ez nekem is eszembe jutott csak azt kéne kideríteni hogy hogyan lehet törölni a fájl végét.
Reality is almost always wrong. - House
|
|
|
|
Reality is almost always wrong. - House
|
|
|
|
Igen Kérdés csak az, h file végének levágását meg lehet e oldani...
|
|
|
|
szerintem sem úszod meg az átindexelést 
én spec azt csinálnám:
pack megmondja, honnan kezdődik a file, mekkora. Én a pack végéhez csapnám a filet újra, majd átoffsettelem az egészet ami az eredeti hely után van és a végén levágom a fölösleges filet.
remélem érthető
szerintem shade is vmi hasonlóról beszél
|
|
|
|
pseudo kóddal:
Kód: if(last_existed_file_end != -1)
{
if( this_file_is_not_deleted )
{
copy(this_file, last_existed_file_end);
}
}
Alapból last_existed_file_end = -1, de ha már megvan, hogy hol törölsz file-t akkor onnantól mindíg a legutolsó létező (nem törölt) file végét mutatja, ahova be lehet illeszteni a következő létező file-t. Ezzel egyszerre akár több file is törölhető, mert ha törölni akarunk egy file-t, akkor mikor elérünk a file-hoz csak annyit kell tenni, hogy nem számoljuk ki a végét, ugyan annyin hagyjuk az offset-et és "ráírunk". Ez 1etlen dolog, ami itt gond lehet az a file végének törlése, mert ha mindent előre "tolunk" attól még a file vége megmarad és 2x is a file-ban lesz. Ezt utána talán átméretezéssel lehetne megoldani, de ezt nem tudom, hogy meg lehet e oldani.
|
|
|
|
És ha csak kisebb részeket vennél egyszerre? Úgy értem, hogy mondjuk file-onként mennél végig rajta: ezeket ha nem kell módosítani nem módosítod, ha törölni kell, akkor a köv file-t előre mozgatod annyival. Ezt lehet memóriába betöltéssel is (addit memóriában tárolod a mozgatni kívánt file-t), de lehet egy temp. file is.
|
|
|
|
Idézet
ShAdeVampirE :
Ok, bocs, késő van már Akkor mást kérdezek: miért nem lehet egy ideiglenes file-t létrehozni v memóriába beolvasni annyi időre?
Memóba beolvasni azért nem akarom mert úgy csináltam meg a pack fájl-t hogy maximálisan 4GB méretü lehessen és szeretném ha egy ilyen 4GB-s fájlból itthon 1GB memóval is tudnék törölni. A temp fájlos módszerrel már nem ilyen bajaim vannak, egyszerűen sztem nem túl elegáns (Ha a 4GB-s fájlból törlök akkor a törlés idejére akár 8GB-t is elfoglalhat az egész), kell lennie jobb megoldásnak is.
Reality is almost always wrong. - House
|
|
|
|
Ok, bocs, késő van már Akkor mást kérdezek: miért nem lehet egy ideiglenes file-t létrehozni v memóriába beolvasni annyi időre?
|
|
|
|
Idézet
ShAdeVampirE :
Nem egészen értem a kérdést. Ez nem csak egyszerűen annyi, h pack leíró strukt-ban megkeresed a file leíró strukt-ját, ami meghatározza h a file hol is van (offset), oda seek-elsz, törlöd, leíró struct-ot is törlöd, és a bejegyzést is törlöd? Ennek van vmi akadája?
Annyi akadálya van ennek hogy nincs fájlból törlés funkció. Csak írni,olvasni és pozicionálni lehet a fájlban.
Reality is almost always wrong. - House
|
|
|
|
Nem egészen értem a kérdést. Ez nem csak egyszerűen annyi, h pack leíró strukt-ban megkeresed a file leíró strukt-ját, ami meghatározza h a file hol is van (offset), oda seek-elsz, törlöd, leíró struct-ot is törlöd, és a bejegyzést is törlöd? Ennek van vmi akadája?
|
|
|
Legutóbb frissített
project:
RogueLite Dungeons
Friss kép a galériából:
|
