érdekes, hogy csak maga a rajzolás kb. 8 mp.EXOS hívások nélküli ASM változat:
Ez 2.31 másodperc alatt fut le, amiből 0.35 s az inicializálásAz igen! :shock:
Nem tartozik ugyan közvetlenül a témához, de az ep128.hu-n található Fractals.rar-ban a VL formátumú képeket IVIEW-ra konvertáltam.Kösz! Kicseréltem.
Még néhány konvertált fraktál rajzoló program:Brutális ez a tempó!
Fraktál rajzolás témában itt egy újabb program azoknak, akiknek van türelmük kb. 82 percet várni a teljes lefutására (illetve emulátoron gyorsítva kevesebbet). :)Nagyon jók!
Ez 2.31 másodperc alatt fut le, amiből 0.35 s az inicializálás (memória foglalás 640K-s konfiguráción és a képernyő törlése).hogyan méred az időt?
hogyan méred az időt?Ezzel a Lua scripttel:
Nagyon jó, az elején még néztem, hogy változik a kép turbó módban, aztán meg a végét :D24 bites egészekkel (fix pontos ábrázolás) valamivel gyorsabb lehetne kisebb pontosság árán. Nagyon nagy különbséget nem jelentene, de talán kevesebb, mint egy óra alatt futna le a program. :)
Ezzel a Lua scripttel: timer.luebiztos én vagyok béna, de nekem runtime error-t ír ki a LUA script futtatásakor...
A végeredménye ugyanaz lesz a programnak mindig (nincs benne rnd)?Igen. Tehát hatékonyabb lenne az eredményt egyszerű képként menteni. :) De az megoldható lenne, hogy választani lehessen a program indításakor, vagy a koordináták beírásával, vagy pedig több előre definiált érték közül (ilyen formátumban egy "kép" csak 16 byte, esetleg valamivel több ha mindegyiknek más palettája lehet).
biztos én vagyok béna, de nekem runtime error-t ír ki a LUA script futtatásakor...A monitor ablakban mi a hibaüzenet ? A script egyébként csak 2.0.8 (ami ugyan elég régi) vagy újabb ep128emu verzión működik.
24 bites egészekkel (fix pontos ábrázolás) valamivel gyorsabb lehetne kisebb pontosság árán. Nagyon nagy különbséget nem jelentene, de talán kevesebb, mint egy óra alatt futna le a program. :)Valóban, első próbálkozásra ez a módosítás 4916 másodpercről 3430-ra gyorsította a programot. Azonban az eredmény kissé eltér (az első kép az eredeti lebegőpontos verzió, a második pedig a módosított változat):
epInit(40, 200, 0x42)
...
x0 = -0.0238281246
y0 = -0.8064778447
x1 = 0.0011718748
y1 = -0.7908528451
...
local i, r2 = mandelbrot(x0 + ((x1 - x0) * (x / videoWidth)),
y0 + ((y1 - y0) * (y / videoHeight)), 4.0, 88)
i = math.floor(i * 0.125 + ditherTable[(y % 4) + 1][(x % 4) + 1])
Azonban az eredmény kissé eltér (az első kép az eredeti lebegőpontos verzió, a második pedig a módosított változat):A hibát túlcsordulás okozta,ezt javítva már csak kisebb eltérés van a kerekítési hiba miatt. Az új verziók:
Kösz! Kicseréltem.Néhány file hibás (első ránézésre úgy látszik, azért, mert az eredeti VL formátumú file kicsomagolva nem pontosan a megfelelő méretű, és ez a konvertálásban hibát eredményezett). :oops: Ezeket hamarosan javítom.
Néhány file hibás (első ránézésre úgy látszik, azért, mert az eredeti VL formátumú file kicsomagolva nem pontosan a megfelelő méretű, és ez a konvertálásban hibát eredményezett). :oops: Ezeket hamarosan javítom.Ok! Kösz! Várom! ;-)
hú ez jó! tetszik ahogy kirajzolja. és elég gyors is!128-as iterációval 5:31, 64 iterációval már csak 3.40
lehetne még gyorsítani, mert sok a lapozás (pl. video RAM 0x8000-től, de a Data és Done tömbök is.Kb. 1200%-os emu sebességgel igen jó. De alap sebességgel is egész tűrhető idő alatt kirajzolja.
128-as iterációval 5:31, 64 iterációval már csak 3.40ó, véletlenül 8 Mhz-re állított emuban néztem :-)
lehetne még gyorsítani, mert sok a lapozás (pl. video RAM 0x8000-től, de a Data és Done tömbök is.
A tömbök méretét csökkenteni lehetne a képernyőt kisebb részekre bontva és több menetben rajzolva. Így ugyan valamivel kevésbé hatékony az algoritmus, viszont minden elfér lapozás nélkül.kicsit átvariáltam azóta, a 128x192 pixel Data és Done tömbje pont elfér 48kB-on, most már csak a PutPixel során kell csak lapozni. Az x, y koordinátához tartozó Done tömb most a 0x4000 + 256y + x címen van, a Data tömb pedig 0x4000 + 256y + x + 128 címen.
PC verzió:
(Attachment Link)
(Attachment Link)
(Attachment Link)
(fordítás az itt (https://enterpriseforever.com/ep128emu/ep128emu/msg70792/#msg70792) található MinGW csomaggal: gcc -m32 -Wall -O2 -IC:/mingw32/include mandel.c -o mandel.exe -lmingw32 -lSDL -lSDLmain -lm -s)
EP-s változatban lehetne még próbálkozni a korábbi programokban használt egész számos aritmetikával.
Kisebb pontosságú és valamivel kevésbé lassú változat:szép lett! nem semmi, hogy még dither-t is raktál bele :-)
(Attachment Link)
na most ezt lenne érdemes átírni asm-be, megnézni, mennyit gyorsítana vajon
EA változtatások 583.5 másodpercről 498.6 másodperce javították a futásidőt 4 MHz-es gépen, de ezen még tovább kellene gyorsítani.
Egyébként miért pont 88?
Még lehetne próbálkozni 16 bites egész aritmetikával (pl. 1 bit előjel + 3 bit egész + 12 bit tört rész)2 bit egész nem lenne elég? ha jól számolom, akkor úgy 3.9999... lenne a legnagyobb ábrázolható szám, de ha r2+i2 >= 4, akkor úgyis a végtelenbe tart, szóval ott elég lenne csak az overflow-t figyelni, nem?
2 bit egész nem lenne elég?
static unsigned char Iterate(int x, int y)
{
unsigned char iter;
long r=x;
long i=y;
for(iter=0; iter<MAXITER; ++iter)
{
long r2 = (r*r)/8192, i2 = (i*i)/8192;
if (r2+i2 >= 32768) break;
i = (r*i)/4096 + y;
r = r2-i2 + x;
}
return iter;
}
úgy vettem észre, hogy a jobbra shift az nem aritmetikai shift-et csinál, ezért az osztás
Valóban jó ötletnek tűnik ez a pontosság, egyelőre 299.8 másodperc lett, de valószínűleg lehetne jobb is:mondjuk már szerintem itt is pontatlan egy kicsit, nem teljesen szimmetrikus a vízszintes tengelyre, bár én nem foglalkozok a kerekítési hibákkal.
ez egyébként mennyivel gyorsabb, mint azok, amik annak idején, az EP idejében készültek?
Összehasonlítás (bal oldalon látható a 24 bites változat):Jó lett! Annyira nem látszik, hogy vészes lenne a 16 bites se!
Hány bit egész részt használsz végül (24 és 16 bites esetben is kíváncsi vagyok, nem néztem még a zip-et, lehet, hogy benne van a forráskódban a válasz) :-)
Nekem az a logikus, hogy a legutoljára kitolt bitet hozzáadjuk az eredményhez.
http://ep.lgb.hu/jsep/demo/?disk=http%3A%2F%2Fpovi.uw.hu%2Fmfx8.com&diskhack=load&autostart=yes&mem=128Jó gyorsan kirajzolta. :D
Tiny Mandel :-)
8 bites fixpontos számokkal (Q2.5)
http://ep.lgb.hu/jsep/demo/?disk=http%3A%2F%2Fpovi.uw.hu%2Fmfx8.com&diskhack=load&autostart=yes&mem=128
Jó gyorsan kirajzolta. :D1 mp a a mandelbrot kiszámolása a rajzolással együtt
Ezt a snapshotot hogyan hoztátok létre?föl kell tölteni valahová a futtatható fájlt. Aztán a linkben, ami van a hozzászólásban ki kell cserélni a
föl kell tölteni valahová a futtatható fájlt. Aztán a linkben, ami van a hozzászólásban ki kell cserélni aAkkor ennyivel a hozzászólásokhoz csatolt fájlok is megnyithatók a webes emuban, ha annak a linkjére cseréljük le a linkben a kérdéses részt, és a egyetlen fájlból áll a program? Mert akkor akár a hozzászólásokhoz is lehetne mindig csatolni a webes emus linket. Vagy akár valahogy megoldani, hogy a fórum generáljon egy ilyen linket az egyfájlos EP-s csatolmányokhoz.
http%3A%2F%2Fpovi.uw.hu%Fmfx8.com
szöveget a kérdéses linkre :-)
Akkor ennyivel a hozzászólásokhoz csatolt fájlok is megnyithatók a webes emuban, ha annak a linkjére cseréljük le a linkben a kérdéses részt, és a egyetlen fájlból áll a program? Mert akkor akár a hozzászólásokhoz is lehetne mindig csatolni a webes emus linket. Vagy akár valahogy megoldani, hogy a fórum generáljon egy ilyen linket az egyfájlos EP-s csatolmányokhoz.
hasonló effekt C64-en:Egyrészt a felbontás 80*50-es, és az effekt ennél lényegesen kisebb területen jelenik meg. Másrészt egyáltalán nem biztos, hogy nem tömörített animáció. Én legalább is el tudom képzelni, hogy viszonylag egyszerű algoritmussal is lehetséges ilyen alacsony felbontású mozgóképet tárolni. Mondjuk nem fogok megpróbálni utána járni.
https://youtu.be/wAZ5Nk_ShGU?t=206
kicsit, mintha ott gyorsabb lenne
Egyrészt a felbontás 80*50-es, és az effekt ennél lényegesen kisebb területen jelenik meg.Ahogy nézem, ott is ugyanakkora a felbontás, a barna "kör" 62x50 pixeles, én 64x48-at jelenítek meg.
Kísérletek Julia-halmazzal:
http://ep.lgb.hu/jsep/demo/?disk=http%3A%2F%2Fpovi.uw.hu%2Fjul8.com&diskhack=load&autostart=yes&mem=128
Kb. 2.8 frame / sec
Közben gyorsítottam egy kicsit rajta (a link maradt ugyanaz), most már 3.21 FPS átlagosan, vagyis a 72 frame-et 22.46 sec alatt rajzolja ki (az eddigi 25.855 helyett)
még kb. 10%-ot lehetne gyorsítani, ha az iterációt lejjebb viszem, a C64 demóban 8 színt használnak, én 10-et.
Egy fontos dolog, az JSep nem emulalja azt, hogy a video memoriaba irni (vagy onnan olvasni, stb) az lassabb, mint nem videomemoriaba. Tehat valodi gepen + jobb emulatoron (ep128emu) valoszinu nem pont ugyanez lenne az eredmeny. Igaz, gondolom sok kulonbseg azert nem lenne, ha nem olyan hatalmas mennyisegu adatot irsz adott ido alatt, illetve, nyilvan nem is ez viszi el az ido nagy reszet amugy sem, hanem a szamitas :)
jaja, az lehet, de az időket ep128emu-val mértem :-)
Közben gyorsítottam egy kicsit rajta (a link maradt ugyanaz), most már 3.21 FPS átlagosan
OUT 191,12-vel már emun is fölszökött a sebesség átlag 3.98 FPS-re!!! :-DA POKE 56,akármennyi, talán 201 meg a megszakításokat kapcsolja ki, attól még gyorsabb lehet. Hát még ha Zzzippel lenne fordítva a program... Ja, azt Assemblyben nem lehet. :D
75 mp (1:15) 64 iterációval úgy, hogy a négyzetre emelés egy 16384 elemű (32kB-os) táblázatból van, így már nem fut 128kB RAM-mal.No, az István féle LPT trükkel nyertem egy szegmenst, így már elég a 128kB RAM.
A táblázat generálása 1.7 mp.
na, sikerült az álom fél perc alá leszorítani... 29.78 sec! :-) 64 iterációval!Szép teljesítmény :)