| Szerző |
Üzenet |
BSzili
Tag
|
# Elküldve: 2015. Sze. 23. 17:22 - Szerkesztve: BSzili
Kicsit visszatértem a Catacomb-hoz, hogy megnézzem mit is művel a scaler. Eredetileg EGA-n a write mode 2-t használja, szóval hardveresen megy a C2P. Amigán hiába generálna 68k kódot a scaler, a pixelenkénti C2P valószínű nem lenne nyerő. Főleg, hogy a játék oszlopokként rajzolja a falakat/sprite-okat.
Lehet érdemes lenne kihasználni, hogy ketté van szelve a képernyő (pálya / status bar), és a játék grafikáját egy chunky bufferbe lehetne rajzolni, majd azt egyben C2P-zni.
|
Lazi
Mr. AmiCon
|
# Elküldve: 2016. Ápr. 12. 12:07 - Szerkesztve: lazi
Ez mennyire portolhato Amigara?
Tesseract OCR
|
BSzili
Tag
|
# Elküldve: 2016. Ápr. 13. 18:39
Portolhatónak tűnik, de valószínűleg iszonyú lassú lenne.
|
Lazi
Mr. AmiCon
|
# Elküldve: 2016. Ápr. 13. 20:08
Kiprobaltam kisebb darabokkal, instantnak tunt nem tul komoly gepen futo windoz alatt.
Jelenleg csak a gocr van nekunk, de eleg regi es nem tul okos.
Szolj, ha motivalhatlak valahogy! :-)
|
BSzili
Tag
|
# Elküldve: 2016. Ápr. 13. 21:41
Ez biztató, majd kiderül, hogy mit produkál NG masinákon. Most csak az motiválna, ha végre meglenne a diplomám, addig csak vegetálok.
|
Lazi
Mr. AmiCon
|
# Elküldve: 2016. Ápr. 13. 22:29
Quoting: BSzili ha végre meglenne a diplomám
Elvesztetted?
:-)
Sok sikert!
|
dino
Kék troll
|
# Elküldve: 2016. Ápr. 13. 22:36 - Szerkesztve: dino
BSzili
Quoting: BSzili Most csak az motiválna, ha végre meglenne a diplomám, addig csak vegetálok.
Sok sikert.
|
Aragon
Tag
|
# Elküldve: 2016. Ápr. 17. 14:07
BSzili:
Vegul mindig sikerul
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 19. 16:46
Hétvégén ügyködtem egy kicsit, és újraírtam a Catacomb3D leglassabb részeit. Került bele egy rendes chunky scaler, és a kéz kirajzolása sem kerül már bitenként(!) 2 függvényhívásba. Akit érdekel megnézheti valami táposabb amigán:
https://www.dropbox.com/s/alap1vq2tqufnzv/reflection-catabyss?dl=0
http://www.classicdosgames.com/game/The_Catacomb_Abyss.html
Epilepsziára hajlamosak óvatosan bánjanak vele, mert benne hagytam a debug raszterhurkákat:
sárga: status bar
kék: falak
türkiz: sprite-ok
zöld: WriteChunkyPixels()
piros: kéz
A legtöbb időt sajnos a WriteChunkyPixels() OS függvény viszi el, blazewcp vagy hasonló ajánlott hozzá. Ha valakinek van ötlete honnan szerezhetnék valami gyors 4 bitplane-es C2P kódot, ne fogja vissza magát.
|
dh1
Mr. DTP
|
# Elküldve: 2016. Júl. 20. 00:08
Shapeshifter MAC emuhoz irtak ilyen C2P cuccokat ha jol tudom es nem tevedek. A leggyorsabbat pedig magyar srac irta, Phoenix. Mar ha jo az ide ... Savage neven futott es valoban nagyon gyors volt. Vele kene konzultani. ChainQ jo haversagban van vele ha jol tudom!
|
AliveMOon
Tag
|
# Elküldve: 2016. Júl. 20. 17:33 - Szerkesztve: alivemoon
Savage MMU-t használ!
Csak azt konvertálta ami különbözött!
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 20. 17:49
Igazán nagy trükközések nem kellenek ide. Az is elég lenne, ha mondjuk Kalms '020-as C2P kódjából tudna valaki 4 bitplane-es verziót kreálni:
https://github.com/Kalmalyzer/kalms-c2p/tree/master/bitmap
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 20. 18:16 - Szerkesztve: charlie
@BSzili:
https://github.com/Kalmalyzer/kalms-c2p/blob/master/bitmap/c2p1x1_6_c5_bm.s
Ebbol, torlod a 265-tol a 389-ig terjedo sorokat, valamint az 594-tol a 723-ig terjedoeket. Ja es az 53. sorban a #6-ot atirod #4-re. Untested. :P
Ha a sorok torlese utan lefagy, akkor csak a 388, 389, 671 es 697 sorokban levo move.l-eket kommentezd ki. Igy lassabb lesz, mert nem letezo bitplane-eket is konvertalni akar, de legalabb nem fog a nemletezo bitplane-ekbe irni.
(Ps: eppen Berlinbe koltozom, es utana is altalanos vilagvege a program, az osszes Amigam dobozban, ido meg arra se jut amire kene, szoval jo esellyel nem fogom tudni tesztelni, hogy tenyleg jo-e amit mondtam, de nagyjabol ez a vonal...)
Szerk: kozben rajottem h. a sorok torlese 1:1-ben biztos nem jo, mert az kikommenteli a chunky forras olvasasat is, pointer inkrementtel... Bar a fene se tudja, mert elotte visszaallitja a korabbi forras pointereket, lehet h. megis mukodik, probald ki. :)
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 20. 18:33 - Szerkesztve: charlie
@dh1/AliveMOon:
ph03n1x irta a MooVid-ot is, ami ugye egy classic AVI/MOV player, szoval igen, a Savage-t leszamitva is nagymestere volt a "barmit Amiga bitplane-ekbe" konverzioknak (pl. ugye a videokhoz szukseges YUV formatumok 2x/4x szeles HAM-be konvertalasahoz, meg ilyen finomsagok). Sajna nekem csak a 8 bitplane-es verzio van meg, de mar en is a Kalms fele C2P-t hasznalom inkabb, mert az a "demoscene standard", meg a ph03n1x kodjaban van egy kis overhead, mert az a verzio ami nekem van, az nem teljes frame-ek konverziojara lett kitalalva, hanem deltazasra (de MMU nelkul). Eredetileg asszem valami MakkMarci (regi szep #amigahu idok, anyone?) fele soha el nem keszult strategiai jatekhoz irodott, aztan valahogy kikotott nalam ilyen "most ez van hirtelen, jo lesz?" cimszoval, amikor C2P-t kerestem, valami lame introhoz amit takoltam 1 partyn... De ez kb. 2002-ben volt, vagy ilyesmi, sacc. :) Marmint mikor megkaptam a kodot.
Irhatok ph03n1xnek, ha nagyon nincs mas, de nem tudom mikor kapcsolta be az Amigait utoljara. Szerintem nem ebben az evtizedben. Update: De egyebkent a fent linkelt #amigahu oldalon levo e-mail cime a mai napig el, meg talan iden is leveleztunk, mert az amigaspirit.hu hostolasahoz o adja a netet. :) Szoval mas is irhat es sztem valaszol.
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 20. 22:08
charlie
Oké, teszek egy próbát. Egyelőre ott leragadtam, hogy mivel készítsek ebből object fájlt. A GNU assembler nem eszi meg, mert nem tetszik neki a szintaxis, a vasm meg valami érdekes szöveges kimenetet produkál belőle. Más nem-natív assemblerről nem tudok.
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 20. 22:57 - Szerkesztve: charlie
@BSzili:
A vasm egy rakas objekt formatumot ismer kimenetnek. Nem tudom a 68k GCC mit csinal (file parancs megmondja) ugyanazt kell megadni a vasm kimenetenek is az -F opcioval. Valszeg -Fhunk vagy -Faout, esetleg -Felf kell neked.
Szerk: Es mintha a default az valoban a sajat vobj formatuma lenne, ami ha jol emlekszem tenyleg egy szoveges formatum (de a vlink kapasbol tud belole dolgozni).
|
dh1
Mr. DTP
|
# Elküldve: 2016. Júl. 21. 00:53
Quoting: alivemoon Savage MMU-t használ!
miert, egy jateknal nem lehet MMU-t hasznalni?
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 21. 07:32
charlie
Áhá, így mindjárt más. -Fhunk-al már szépen összelinkeli, viszont valószínűleg a -Faout lesz a nyerő, mert azzal még a binutils-os strip is elboldogul. Kezdetnek foglalok két kamu bitplane-t AllocRaster-el a bitmap-ekbe, aztán ha úgy megy jöhet a kísérletezés kora.
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 21. 08:07
@dh1:
miert, egy jateknal nem lehet MMU-t hasznalni?
OFF:
Lehet, csak nincs ertelme. A Savage azert hasznalt MMU-t, mert az MMU megmondta a drivernek hol valtozott a Mac OS kepernyo tartalma, igy csak azt a reszt kellett konvertalni. De ha egy jatek vagy, akkor a valtozasok kovetesehez nem kell MMU, hiszen nem egy masik alkalmazas, hanem a sajat valtoztatasaid koveted, amit szoftverbol igen egyszeru megtenni, es az MMU lap meretenel joval precizebben is kovetni tudod, hogy mi valtozott, igy meg kevesebbet konvertalsz feleslegesen, valamint nem kell az also hangon negyfele 68k MMU-hoz tamogato kodot irni, plusz nem kell a jatekodhoz MMU-t igenyelni.
Szoval roviden, a Savage MMU hasznalata egy nem tul idealis hack volt, amit a szukseg szult, a dolog specialis termeszetebol fakadoan, es idealis esetben jobb ezt elkerulni. Es el is lehet.
ON.
|
dh1
Mr. DTP
|
# Elküldve: 2016. Júl. 21. 12:21
Aha, ertem! Koszi! :)
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 21. 23:17 - Szerkesztve: BSzili
Siker! A 6bpl verzió működik, a sebességnövekedés drámai. Most már kb annyit visz el a c2p mint a sprite scaler. Cycle exact A1200 módban elértem az 1FPS-t :) Most a falakhoz használt scaler szöszmötöl a legtöbbet, ami nem csoda, hiszen borzalmas optimalizálatlan C kód, amit én írtam.
edit: Műxik a 4bpl verzió is! Kösz a segítséget, úgy érzem jó irányba haladunk :)
https://www.dropbox.com/s/alap1vq2tqufnzv/reflection-catabyss?dl=0
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 22. 00:34 - Szerkesztve: charlie
Melyik 4bpl verziot hasznalod vegul, a kitorloset, vagy csak a 4db move.l-t kommentezted ki? :) Egyebkent a DropBox URL nekem nem mukodik.
Amugy sztem C2P-vel sosem lesz eleg gyors egy bovitetlen A1200-on. Szoval arra ne is szamits. Ilyen 030/50 korul kezd hasznalhato lenni a C2P, meg akkor is ha csak 4 bitplane-rol beszelunk. A borzalmas optimalizalatlan C scalert lehet valahol latni kod ugyileg? :)
|
dh1
Mr. DTP
|
# Elküldve: 2016. Júl. 22. 02:00
dropbox url nem muxik, valoban
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 22. 07:25
Úgy tűnik túl sokan cuppantak rá a linkre, és a DropBox letiltotta egy időre. Megvan a mohóság eredménye! Komolyra fordítva a szót, majd keresek neki más tárhelyet.
A C2P-ből végül kitöröltem azt ami nem kell, és így megy. Ha már 030-on menne az se lenne rossz, persze a lázálmom az, hogy egy CD32-n elfusson két számjegyű FPS-el :)
A scalerek forrása itt van. Az olvashatóságra hajtottam rá, most még kicsit sokat számol rajzoláskor. Most hogy megy át akarok térni pointer aritmetikára:
https://github.com/BSzili/refkeen/blob/amiga/src/id91_11/cat_all/c3_asm.c#L236
https://github.com/BSzili/refkeen/blob/amiga/src/id91_11/cat_all/c3_scale.c#L750
A sprite-oknál még van némi maradvány az x86-os EGA kódból, de nem hiszem, hogy az most a legnagyobb gond. Ott a struktúrákba is bele kell majd nyúlni később.
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 22. 08:08 - Szerkesztve: charlie
Elkepzelheto hogy 020-on is fel lehetne gyorsitani egy kicsit, de ahhoz kozvetlenul az Amiga bitplane-ekbe kene renderelni sztem. Esetleg valami blitter-assisted C2P-t bevetni, mert olyan is van... De pucer CD32-n szerintem sose lesz eleg gyors, ne felejtsuk el, hogy mar az a teny, hogy csak Chip RAM van is mennyire agyonvagja az amugy sem oriasi CPU teljesitmenyt...
Hulye kerdes: fel tudod tolni valahova az .S fajlokat amiket a GCC fordit ebbol a ket fajlbol? Jo lenne latni, mennyire hasznalhato kodot fordit belole a GCC, mielott optimializalasi tanacsokkal traktallak. :) Asszem --save-temps vagy valami ilyesmi.
Szerk: amugy ranezesre (aritmetikailag) a legtobbet ugy lehetne rajta gyorsitani, ha kiforditanad a belsejet, tehat nem a forras kepen iteralnal vegig, es azt scaleznad fel, hanem kiszamolnad hogy mekkora a vegeredmeny negyzet pl. spriteoknal, 1x beclippelned a kepernyore es aztan a kepernyo koordinatakon menni vegig, es frissiteni a forras pointerbol az adatot ha kell, mert pixelhatart leptel at. Ekkor a legbelso scanline-fillezot at lehet irni assemblybe (kb. egy 10 soros assembly a vegeredmeny), plusz nem kell per pixel clipelni. Extra nehezseg, hogy ilyenkor pl. baloldali/top clippingnel ki kell szamolni hogy hol kezdodik a forras kepen amit ki kell rajzolni, nem lehet csak vegigiteralni aztan "ja most mar bent/kint vagyok a kepernyon, kezdhetek rajzolni", hiszen nem letezo kepernyokoordinatakon sosem iteralsz vegig.
Nem tudom erted-e mit makogok itt.
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 22. 08:45 - Szerkesztve: BSzili
Itt van a mostani változatból gyártott asm kimenet:
http://pastebin.com/XkfjxXc2
http://pastebin.com/hH1v6Psd
Nagyjából értem, első közelítésre ez jobban hasonlít arra, amit a Wolf3D csinál. Az rendes raycaster, ahol minden képernyőoszlopra jut egy scaler, és nem scanline raszterizáció megy. Apropó Wolf3D, kéznél van a Mac-es port forrása, megnézem majd azt is, hogy mit művel. Először megnézném, hogy a meglévő megoldással lehet-e kezdeni valamit. Ez nem tudom mennyit gyorsítana:
uint8_t *destPtr = &g_chunkyBuffer[colNum + startpix*VIEWWIDTH];
for (;startpix<endpix;startpix++)
{
for (id0_unsigned_t i=0; i<wallwidth[colNum]; i++) destPtr[i] = wallSrcPtr[src];
destPtr += VIEWWIDTH;
}
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 22. 09:10 - Szerkesztve: charlie
Igen, ezert kertem el az asm forrast, hogy megeri-e az ilyesmi matekot kitenni a ciklus ele. Ugy nez ki, hogy nem, mivel a GCC-ben van common subexpression eliminator, es egesz jo, szoval eszreveszi hogy ott a szorzas eredmenye nem valtozik, es kiteszi a ciklus ele a generalt assemblyben amugy is... :)
Pont ezert kezdtem el masfajta algoritmusban gondolkodni, mert a GCC ezekben a trukkokben eleg jo magatol is...
|
BSzili
Tag
|
# Elküldve: 2016. Júl. 22. 09:51 - Szerkesztve: BSzili
Na ja. Kíváncsiságból megnéztem, egy pár move utasítást meg lehetett spórolni vele, de nem ez fogja megváltani a világot. Itt tényleg az lesz a tuti ha rendesen képernyőoszloponként megy a rajzolás.
szerk: Felraktam Google Drive-ra egy friss exe-t:
https://drive.google.com/open?id=0BzblJSPJy3DCQ3gxUm5LVmNSOVU
|
Chain-Q
Divatamigás
|
# Elküldve: 2016. Júl. 22. 10:39 - Szerkesztve: charlie
Azon agyaltam, ha ennyire oszloponkent rajzol, akkor nem-e lenne ertelme elforditani a kepernyot a memoriaban, igy lehetne "scanline" fillert irni az oszlopokhoz es nem kene minden akalommal egy scanline-nyit skippelni. Ezt aztan akar a C2P-be integralva vissza lehetne forgatni... Bar 020-on es tsain annyit nem szamit, mert nincs (nagy meretu) cache ami buntet ha szarul hasznalod, mint 060-on.
Bar gondolom ez a megabrutal kategoria ujrairas... :)
|
dino
Kék troll
|
# Elküldve: 2016. Júl. 22. 10:52
Na es mondjuk az utodban, az Amigas Doomban ez a technikai resz, hogy van megoldva? Abbol nem lehet meriteni? Mert, hogy az eleg jol megy egy 14Mhz s 020 on is, es nemileg tobb texturaval.
|
