| Szerző |
Üzenet |
BSzili
Tag
|
# Elküldve: 2015. Jún. 19. 11:01
Illene, de amíg a scalerek nincsenek újraírva, addig kétséges, hogy sikerül-e két számjegyű FPS-t produkálni. Az ECS tökéletes lesz, OCS + ~300 KB chip + 1 MB fast körülbelül elég neki... na meg egy 060 :D
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 20. 18:08
Na felnyomtam, akit érdekel ki lehet próbálni:
https://www.dropbox.com/s/upuxn8vv4wffhqm/refcatabyss-113?dl=0
http://www.classicdosgames.com/game/The_Catacomb_Abyss.html
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 21. 19:43 - Szerkesztve: charlie
Mondjuk felrakhattad volna ugy is, hogy classic Amigara ne 3 lepesben kelljen leszednem... :P (A DropBox altal hasznalt SSL-t mar nem eszi az IBrowse...)
Szerk: Na, leszedtem, elindult. A keyboard kezeles nem mukodik, ergo nem tudok belepni a jatekba, vagy barmit kivalasztani. Es az inditokepernyoket is ugy kellett vegigvarni, mert mar ott sem ment tovabb enterre, vagy ilyesmire.
Szerk#2: Ja es nem tiltotta le a multitaskot. Nem ugy volt h. letiltod?
Szerk#3: Ja es kilepni se lehet, a fenti keyboard-kezelesi mizeria miatt. A fomenuben az egerkurzor is a kepernyon marad.
Szerk#4: Az executable a shellben lebreakel CTRL-C-re, de nyitvahagy screent-ablakot-tokot-vonot... Reboot. :)
Sserk#5: Fura, reboot utan masodik inditasra mar mukodik a keyboard kezeles. Lehet h. a screenvaltas boritja meg? Most teszt.
Szerk#6: Rajottem, hogy miutan belekattintasz a kepernyobe, utana nem megy a keyboard. Mintha valami mas ablak lenne aktiv, mint amin az eventek bejonnek.
Szerk#7: Na tovabbi magyarazatok helyett a sebesseg-videot felraktam ide: http://charlie.amigaspirit.hu/temp/private/catacomb-1st-060.mp4
Megegyszer, ez egy A2000/060@50Mhz (Blizzard2060 CPU kartya), nativ ECS kepernyon (PicassoIV flifi-n at). A kartya szinte teljesen azonos teljesitmenyre egy B1260-nal amugy, csak persze a chip-mem iras lassabb mint AGA-n, de itt nem az szamit, szerintem... :P
Szerk#8: Ami a GitHubon van, az a latest kod? Ja es, mivel forditod? GCC v. VBCC?
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 22. 10:07
Argh, elnézést a dropbox miatt. Elfelejtettem, hogy az AmiSSL-t még mindig nem frissítették.
1) Működik az, csak a végtelen bölcsességemben a képernyő megnyitása előtt adom hozzá a keyboard handler-t. Ennek az a kellemetlen mellékhatása, hogy ha a shell ablak nem aktív a WB képernyőn, akkor nem fog meghívódni a handler. Mindjárt javítom.
2) Le fogom a végleges verzióban, de egyelőre kisebb gondom is nagyobb a multitaszknál.
3) A kilépést az általam igen gyorsan összeeszkábált audio.device-os PC speaker emuláció akasztja meg. Anélkül ügyesen ki tud ám lépni. Az egérkurzort hogy tudom eltüntetni, ha nincs ablak nyitva csak egy screen? Tiltsam le a sprite-okat?
4) Áhá, kösz! Ezt majd jól letiltom benne, vagy megbütykölöm hogy valami értelmeset csináljon.
5) 6) Lásd 1) :)
7) Hát igen, kb ilyesmire számítottam. A játék csinál némi chip-ram másolgatást, de ahogy mondtad kisebb gondom is nagyobb.. :D
8) Majdnem a legújabb. Egy függvényt újraírtam, hogy a képernyő kitöltése egy színnel ne vegyen el ugyanannyi időt, mint maga a grafika rajzolása. Ezt mindjárt pusholom is.
GCC-t használok, de szerintem VBCC-vel is lefordulna. Ahogy néztem azokat a C99 bővítéseket támogatja amiket NY00123 használt (változó deklaráció for loopban, és hasonló nyalánkságok).
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 22. 23:55
@BSzili:
Az egérkurzort hogy tudom eltüntetni, ha nincs ablak nyitva csak egy screen?
Miért nem nyitsz egy üres backdrop ablakot a screenre? Akkor mindent csinálhatnál, amit egy ablakkal lehet, pl. az aktiváció is rendesen működne.
Ami az Amiga notesben van "hot" függvény lista, az még érvényes?
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 23. 11:23
Szerintem ha a képernyő megnyitása után adom hozzá az input handlert azzal megoldódik a billentyű probléma. Igazából nekem kényelmesebb a képernyő mint az ablak, mert egyszerűen tudom changevpbitmap-pel cserélgetni a tartalmát. Intuition üzenetekre meg IDCMP-re nincs igazán szükségem. Egy képernyőni ablak nem enne meg plusz chip RAM-ot?
A hot lista még félig érvényes, a BE_ST_EGAUpdateGFXPixel4bppRepeatedly-t azóta ráncba szedtem amennyire tőlem tellett. Talán beszédesebb a hívási fa fentebb, ahol szétszedtem, hogy mi hívogat mit:
https://github.com/BSzili/refkeen/blob/amiga/amiga-notes.txt#L62
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 23. 11:38 - Szerkesztve: charlie
@BSzili:
Értem, hogy classicon lehet hackelni, csak minek:
"Backdrop windows may often be used in place of drawing directly into the display memory of a custom screen. Such a technique is preferred, as backdrop windows are compatible with the Intuition windowing system. Using a backdrop window eliminates the danger of writing to the screen memory at a "bad" time or at the wrong position and overwriting data in a window.
To provide a full screen display area that is compatible with the windowing system, create a full sized, borderless, backdrop window with no system gadgets."
Idézet innen. :)
Egy képernyőni ablak nem enne meg plusz chip RAM-ot?
Csak a smartrefresh ablakok esznek plusz chipramot, szóval ha nem smartrefreshnek nyitod a backdrop ablakod, akkor nem fog többet enni. (AFAIK). Ellenben rendesen integrálja az alkalmazásod az Intuition messagingbe és a layerek közé (bár a layeringet te nem használod most, de attól még lehetne). Attól még te az alatta lévő screenen nyugodtan ChangeVPBitmap()-olhatsz. És akkor máris le tudod tiltani a kurzort megfelelően, nincs macera h. mi az aktív ablak vagy mi sem, stb. Szóval tegyél magadnak egy szivességet, és nyiss egy backdrop ablakot, kthx... :) A végén még az is kiderülhet, hogy a multitaskot sem kell letiltani, végülis nem Atarin vagyunk, vagy mi! :P
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 23. 15:53
Értettem, ablak hozzáadva! :D
Erről jut eszembe, a FreePascal szöveges képernyője hogy van megoldva? Ami a refkeen-ben eredetileg van az elég lassú, inkább nem emeltem át: https://github.com/BSzili/refkeen/blob/amiga/src/be_st_sdl_graphics.c#L1311
Egyelőre csak a shareware catacomb abyss használja kilépéskor (amigán a kék szmötyi), de a játékhoz tartozik egy szöveges shell, ami feltételezhetően belekerül majd a refkeen-be is. Ahhoz nem jönne rosszul a szöveges képernyő emuláció. Persze az is lehet, hogy csak kihányom a karaktereket az emulált B800 memóriából a shell ablakba.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 23. 16:22 - Szerkesztve: charlie
FPC az full hack, SetABPen() es BltTemplate()-zek egy Bochs-bol kirippelt VGA fontot, per karakter. Igy persze kurva lassu lenne ha folyton az egesz kepernyot frissitenem, szoval azzal van megfejelve, hogy el van tarolva karakteres formaban az "aktualis" kepernyo is, es deltazok, szoval csak a valtozasokat renderelem effektive.
De mondjuk annak csak annyi koze van a PC textmodhoz, hogy kompatibilitasi okokbol ugyanaz a belso "textmod" buffer felepitese, marmint karakter + attributumok, amugy mivel a cucc megy Linuxon meg Windowson is, meg minden szaron, ezert fel van keszitve a custom rendering rutinokra, sot a tetszoleges meretu terminalablakra is, meg egy rakas egyeb kapcsolodo szirszarra.
Meg annyi a trukk, hogy mivel OCS/ECS/AGA-n BltTemplate()-nek *nyilvan* a chip RAM-ban kell lenni a source adatnak is classicon, ezert miutan megvan az ablakom, foglalok egy Friend bitmapot hozza, ami ha BMF_STANDARD flaggel van megjelolve, akkor atmasolom oda a fontot (a chipset altal igenyelt alignmenttel), es utana onnan blittelek, ha meg nem BMF_STANDARD, akkor RTG-n (classic RTG, MorphOS, AROS) vagyok, es akkor kozvetlenul tudok a VGA font adatbol BltTemplate()-ezni. De ez teged nem erint, mert te egyszeruen MEMF_CHIP-pel foglalsz teruletet, font atmasol a megfelelo alignmenttel es kesz, onnantol mehet a BltTemplate.
Nagyjabol itt a forras:
https://github.com/graemeg/freepascal/blob/master/packages/rtl-console/src/amicommon/ video.pp#L426
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 23. 16:45 - Szerkesztve: charlie
@BSzili:
a BE_ST_EGAUpdateGFXPixel4bppRepeatedly-t azóta ráncba szedtem amennyire tőlem tellett
Ez gyanúsan sokat shiftel nekem, ami elég lassú 68k-n (060-at leszámítva). Bár persze meg kéne nézni h. a GCC mit fordít belőle, mert az számít.
Amúgy valószínűleg a 32bit expansion csak lassít rajta... Mondjuk chip RAM-ban nem tudom, de amúgy elképzelhetőnek tartom... 060-on pl. én írtam egy "hiperoptimalizált" vízszintes vonalrajzolót (assemblyben), ami pont ezt csinálta, hogy kiexpandolta a byte colort 32 bitre és aztán dwordoket írt, szigorúan 32bit aligned... Szépen, ahogy x86-on csinálnád... Na ez pont sokkal lassabb volt mintha simán byte-okat írnék tight loopban... :) Hiába, a 060 és az ő storebufja nem hazudik!
De ezt le kéne benchmarkolni.
Amúgy, tudnál egy olyan binárist gyártani nekem tesztcélból, amin a BE_ST_EGAUpdateGFXPixel4bpp nem függvény hanem egy makró? Ergó nincs per pixel függvényhivás... Csak kiváncsi vagyok, mert én így kezdeném az optimalizációt, kb... És nem csak a függvényhívás miatt, de a 68k a stacken passzolgatja a paramétereket, szóval van ott jócskán memóriaturkálás is hozzá. Még akkor is ha a 060 cache megfogja a többségét, jobb neki ha nem kell. :)
Szerk:
plane0color |= ((color & 1) << currBitNum);
plane1color |= (((color & 2) >> 1) << currBitNum);
plane2color |= (((color & 4) >> 2) << currBitNum);
plane3color |= (((color & 8) >> 3) << currBitNum);
Itt meg, nem tudom a 68k-s GCC amit használsz, abban mennyire jó az optimizer és kiteszi-e a loop elé a color változó maszkolását és konstanssal shiftelését, aminek mind a 8 loopban ua. lesz az eredménye...
Szerk#2:
Igazából az egész loop és a planecolorok shiftelgetése és vagy-ozgatása nem kell. Mutatom:
plane0color = -(color & 1);
plane1color = -((color & 2) >> 1);
plane2color = -((color & 4) >> 2);
plane3color = -((color & 8) >> 3);
Ha color adott bitje = 1, akkor 0-1 = -1 lesz, minusz 1 pedig = 0xffffffff-fel, vagyis sikeresen kiexpandoltad a bited az egész uint32-re. Egyébként meg 0-0 = 0...
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 24. 10:38 - Szerkesztve: charlie
Oké, volt még 15 percem, a fentiek alapján ránéztem a BE_ST_EGAUpdateGFXPixel4bpp-re is... Hát ez nem is csoda h. kicsit lassú...
Szerintem első körben valami ilyesmivel érdemes próbálkozni:
void BE_ST_EGAUpdateGFXPixel4bpp(uint16_t destOff, uint8_t color, uint8_t bitsMask)
{
g_sdlVidMem->egaGfx[0][destOff] = (g_sdlVidMem->egaGfx[0][destOff] & ~bitsMask) | (-(color & 1)) & bitsMask);
g_sdlVidMem->egaGfx[1][destOff] = (g_sdlVidMem->egaGfx[1][destOff] & ~bitsMask) | (-((color & 2) >> 1) & bitsMask);
g_sdlVidMem->egaGfx[2][destOff] = (g_sdlVidMem->egaGfx[2][destOff] & ~bitsMask) | (-((color & 4) >> 2) & bitsMask);
g_sdlVidMem->egaGfx[3][destOff] = (g_sdlVidMem->egaGfx[3][destOff] & ~bitsMask) | (-((color & 8) >> 3) & bitsMask);
}
Teljesen untested, de a koncepció talán átmegy. Egyébként most néztem azt is, hogy az Repeatedly-s függvényvariáns az általad megoptimalizált verzióban ignorálja a bitmaskot, ami nem tudom mennyire jó ötlet.
És ezután már tényleg be lehet tenni - és érdemes is - a 4bpp függvényt inkább makróként. (Sőt, igazából már az egyetlen plane módosítását is ki lehet makrózni, és utána csak azt kell 4x egymás után.)
Ha ezekkel a változásokkal sem lesz elég gyors 060-on, akkor majd assemblyzünk is egy jót! :P
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 11:19 - Szerkesztve: BSzili
A 32-bitre kiexpandolást az egyik amigás Wolf3D portban láttam. Ott is bevágja a színértékeket 32-bites regiszterekbe, és azokkal sorban teleírja a képet. Néztem disassembly-t, és bár sokat nem értek belőle, a GCC is valami ilyesmit fordít belőle. A maszk elhagyása szándékos, mert az összes hívásnál 0xFF az értéke. A minuszolós trükköt mindjárt megnézem, hogy működik. A függvényhívásoktól való megszabadulás valószínű elkerülhetetlen.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 24. 11:53 - Szerkesztve: charlie
Na, most tákolok egy 68k C keresztfordító környezetet is magamnak, a Pascal mellé, persze Cahir/Whelpz! cuccával. Te azt használod amúgy? Aztán leforkolom utána giten a RefKeent tőled, csak majd accepteld a pull requesteket (ha lesznek)... :)
Szerk:
A 32-bitre kiexpandolást az egyik amigás Wolf3D portban láttam.
Hát ha ott is így csinálja és per pixel, akkor ez megmagyarázná miért döglassúak az Amigás Wolf3D portok... :)
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 12:24
Én GCC 3.4.0-vel (fúj! (?)) fordítok, mert a refkeen használ 1-2 C99 fícsört, amit nem volt kedvem kigyomlálni. Tényleg az lenne a legtisztább, ha te is le tudnád fordítani, mert ha nekem kell a binárisokat gyártani az igen csak lelassítja a folyamatot :)
A fentebb javasolt optimalizáció amúgy gyorsított egy kicsit a dolgon, a makró viszont furcsamód nem segített. Sőt egy kicsit meg is bolondította a scalert, és az első frame-nél teleszemetelte a buffert. Lehet, hogy a GCC optimizer szart el valamit benne. Static inline függvényként is megnéztem, úgy nincs sok változás.
Még be kell húznom pár változtatást a main branch-ből, és push-olom ami eddig megvan.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 24. 12:39
@BSzili:
A fentebb javasolt optimalizáció amúgy gyorsított egy kicsit a dolgon, a makró viszont furcsamód nem segített. Sőt egy kicsit meg is bolondította a scalert, és az első frame-nél teleszemetelte a buffert.
Esetleg a hívó kódban más a destOff, vagy a bitmask típusa vagy mérete, (pl. 32bit, nem 8, vagy mittudomén), emiatt a makró máshogy kezd el viselkedni.
A "nincs sok változás" az milyen hardveren?
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 12:49 - Szerkesztve: BSzili
Lehet, hogy egy pár kasztolás megoldaná, megnézem hogy hívja a függvényt. Csak WinUAE-ben teszteltem cycle exact A1200 módban. Tudom, hogy a 020 emulációnál vannak különbségek még CE módban is, de olyan vasam jelenleg nincs amin elfutna a játék.
szerk: A változóméretek stimmelnek, valami más lesz a bibi. Ha esetleg nem akarsz a fordító fordításával vesződni, akkor kas1e oldalán van "kulcsrakész" GCC 3.4.0 linux és cygwin alá is:
http://kas1e.mikendezign.com/zerohero_crosscompilers_backup/cross-compiler_os3.html
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 24. 15:16
Hova kell betenni a makrót h. egyszerűen megtalálja?
Már lefordult 1 GCC amúgy, csak 2.95.3, és elvileg tud 3.4.6-ot is, de most nem akarom kimatekolni, szóval azt találtam ki hogy belehegesztem az optimalizációkat az SDL-es függvényekbe, mert azok is szarok és akkor Linuxon is tudom futtatni... Utána ha ott megy minden, már egyszerű lesz az Amiga port, szerintem.
És akkor lehet h. az SDL-es optimalizált verziót is elfogadják pull requestben... Nem mintha számítana, mai hardveren, csak olyan ocsmányul szuboptimális a kód hogy fizikailag fáj... :) (A legszebb, hogy mindezt a "cleanup" jegyében tudják elkövetni manapság.)
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 15:38
Nem a sebességre hajtott rá, az biztos. Ahogy elnéztem inkább az atomtengeralattjáró-biztos portabilitás volt a cél, meg az eredeti játék viselkedésének hű emulálása. Ezekből csak az utóbbit tudom értékelni.
A be_st.h szerintem jó hely lesz a makrónak. Azt két másik headeren keresztül (szinte?) minden forrásfájl beinkludálja (de szép magyar szó).
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 17:58
Közben sikerült életre kelteni a szöveges képernyőt. Köszi hogy belinkelted a forrást, erre a BltTemplate-re biztosan nem találtam volna rá egy darabig :)
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 24. 18:33 - Szerkesztve: charlie
Csinálsz nekem egy binárist az aktuális állapottal, benne a működő optimalizációkkal? Még melóhelyen vagyok, de otthon kipróbálnám. Csak hogy motivált legyek és összerúgjam azt a kib*szott GCC-t. :)
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 24. 18:41
Oké, feltettem ide egyet:
http://bszili.morphos.me/stuff/refcatabyss-113
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 25. 10:48
Na hát ez tényleg nem lett lényegesen gyorsabb... :S Nnna, akkor lássuk... *sóhaj*
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 26. 18:01
Az egér kezeléssel van egy kis gond. Szokás szerint bigfoot input handlerét emeltem át, amivel MOS-en, AROS-on meg OS4-en az egérnél deltákat kapok az input event-ekben. AmigaOS 3.1-en abszolút koordináták jönnek, ami azért gáz, mert hiába deltázgatnék "kézzel", ha a képernyőt szélét eléri a kurzor, akkor a változás mindig 0 lesz. Hogy tudom rávenni az input.device-t, hogy deltákat tegyen az egér eventjeibe?
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 26. 21:54
Nem az ujdonsült backdrop ablak message-ivel clashel össze? Elvileg van IDCMP_DELTAMOVE... Vagy ha nem akarod az ablak üzeneteit kezelni, akkor mivan ha kiveszed belőle a WFLG_ReportMouse-t? Akkor meg egyáltalán nem megy a mouse event handler...?
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 26. 22:22
Úgy rémlik, hogy ablak nélkül is ugyanezt csinálta, de mindjárt megnézem WFLG_ReportMouse nélkül is. Ha van egy mód rá, nem szívesen cserélném le az input handler-t IDCMP-s pollingra. Az is lehet, hogy ez valami WinUAE nyűg, és igazi hardveren delta eventeket küld, mint MOS-en.
|
AliveMOon
Tag
|
# Elküldve: 2015. Jún. 26. 22:40 - Szerkesztve: alivemoon
Nem tudom menyire segít, de lehet nem jutott eszedbe az a trükk.
A problémát miszerint, ha abszolút koordinátákat ad a rendszer, eltüntetik és minden elmozdulás követően vissza teszik középre, így minden mozdulatnál a delta lesz az eredmény.
A deltákból pedig saját magad számolhatsz abszolút értéket amire kiteszel egy saját pointert.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 27. 00:43
Jáj... Mindig ez a körbehekkelés meg trükközés...
|
AliveMOon
Tag
|
# Elküldve: 2015. Jún. 27. 01:15
Quoting: charlie Jáj... Mindig ez a körbehekkelés meg trükközés...
Jaj... érintő képernyőn vagy lightpen-vel mindig abszolút pozíciót kapsz.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jún. 27. 02:04 - Szerkesztve: charlie
Csodálatos! Tehát akkor ott tartottunk hogy EGÉR koordináta...
@BSzili:
A zistennek nem tudom ezt én GCC-vel leordítani. Mert már maga a GCC sem működik. A Cahir féle 3.4.6 nekem változatos módokon széthal fordítás közben (platformfüggően), a kas1e-féle (ami igazából Zerohero-féle, ha jól értem) GCC 3.4.0 meg cygintl-3.dll-t keres, ami kb. nem létezik már, legalábbis én csak cygintl-8.dll-t találtam a gépemen a felrakott CygWinben... Szóval akkor most még egy Linuxot is fel kéne lökdösnöm valami VirtualBoxba, jáj...
|
BSzili
Tag
|
# Elküldve: 2015. Jún. 27. 08:33 - Szerkesztve: BSzili
Egyre gyanúsabb, hogy csak a winuae kavar be, mert rémlik, hogy a púderbukk touchpad MorphOS-en is abszolút koordinátákat küldött. Majd elválik, hogy igazi hardveren mit művel az egér.
Azt hiszem már nekem is külön kellett cygintl-3.dll-t vadászni. Inkább feltöltöttem az egész keresztfordítót:
https://www.dropbox.com/s/3s83kd5zm1tr56t/m68k-amigaos.tar.gz?dl=0
ééés a cygintl3.dll-t:
https://www.dropbox.com/s/2oz81udlsfs888c/cygintl-3.dll?dl=0
|
