Welcome, Guest. Please login or register.


Author Topic: game00 (Read 34649 times)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #60 on: 2013.November.10. 11:14:46 »
Quote
Én a sima sprite rámásolást választanám, nem hinném, hogy annyira zavaró lesz 1-2 pötty pár pixellel korábban való eltűnése


Én is ebben gondolkodok először, azzal a kis módosítással, hogy ugye 4 pixel van egy bájtban, mikor nincs elcsúsztatva a sprite, akkor mondjuk egy 16 pixel széles sprite -hoz 4 bájtot fogok kimásolni, és a sprite meg jól ki van rajzolva a befoglalója széléig.

Mikor egy pixellel van jobbra tolva, akkor 5 bájtot fogok másolni de a jobb szélső bájtot, ahol most épp 3 üres pixel van, azt azért valamilyen módon maszkolni fogom. Aztán mikor kettővel van eltolva, akkor mindkét oldalon 2 pixel luk van, akkor csak simán kimásolom az 5 bájtot, amikor meg hárommal van eltolva, akkor bal oldalon van 3 pixel luk, akkor a bal oldali bájtot fogom maszkolni.

De nem tudom a gyakorlatban ez elég jó lesz -e, arról nem is beszélve, hogy az ellenség kódok is olyanok kelle legyenek így, hogy a sprite -ok egymással se kerüljenek fedésbe ...

Nem eccerű dolgok ezek.

Arról nem is beszélve, hogy még a csillagmozgás sincs készen ... csillagmozgast csinálni egyszerű, de gyorsat csinálni abból sem egyszerű ...
« Last Edit: 2013.November.10. 11:30:08 by Z80System »
Z80 System

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: game00
« Reply #61 on: 2013.November.10. 11:29:30 »
Quote from: Z80System
Mikor egy pixellel van jobbra tolva, akkor 5 bájtot fogok másolni de a jobb szélső bájtot, ahol most épp 3 üres pixel van, azt azért valamilyen módon maszkolni fogom. Aztán mikor kettővel van eltolva, akkor mindkét oldalon 2 pixel luk van, akkor csak simán kimásolom az 5 bájtot, amikor meg hárommal van eltolva, akkor bal oldalon van 3 pixel luk, akkor a bal oldalt fogom maszkolni.
Ezt mindenki így csinálja (aki gyors kódot akar) az ősidőktől fogva. :)
Vigyázat! Szektás vagyok! :)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #62 on: 2013.November.10. 11:36:43 »
Quote
Ezt mindenki így csinálja (aki gyors kódot akar) az ősidőktől fogva.

Jajj, be hiányzott is már értékes kontribúcióid eme szép példánya ... érzem a pszichés támogatás erejét ... ahogy igyekszel biztosítani az utam helyességéről ... jajj, be szép is ez ... jajj, be szerencsés is vagyok ...
« Last Edit: 2013.November.10. 11:43:38 by Z80System »
Z80 System

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: game00
« Reply #63 on: 2013.November.10. 11:37:54 »
Sőt, nagyon gyors kódhoz szoktak olyat is hogy kóddá konvertálják az adatot is. Azaz nem olvasgatják valahonnan a sprite adatokat meg másolgatják, hanem írnak egy kódot ami felépíti a sprite kirakó kódját úgy, hogy beleépíti a sprite adatokat brute force módszerrel.
Ezzel lehet a legnagyobb sebességet elérni, persze eszi a memóriát is. .)
Vigyázat! Szektás vagyok! :)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #64 on: 2013.November.13. 20:21:04 »
Minden különösebb magyarázat nélkül bemásolom az eddigi csillagmozgás ciklusmag elmélkedéseim eredményét. Lehet valakinek poen. Nincs itt mind, de a lényegi irányvonalak ezek :) :

;------------------------- 18.25 us
 ld d, (hl)
 ld e, #0x00

 xor a
 ld (de), a

 ld a, c
 add d
 cp b
 jr nc, Stars_Overflow
 ld d, a

 ld a, #0x00
 ld (de), a

 ld (hl), d
 inc l
;------------------------- 16.5 us
 ld d, (hl)
 ld e, #0x00

 xor a
 ld (de), a

 ld a, c
 add d
 and b
 ld d, a

 ld a, #0x00
 ld (de), a

 ld (hl), d
 inc l
;------------------------- 19 us
 ld e, (hl)
 ld a, (de)
 ld b, a
 ld c, #0x00

 xor a
 ld (bc), a

 inc e

 ld a, (de)
 ld b, a

 ld a, #0x00
 ld (bc), a

 ld (hl), e
 inc l
;------------------------- 19 us
 ld e, (hl)
 ex de, hl

 ld b, (hl)
 ld c, #0x00

 xor a
 ld (bc), a

 inc l

 ld b, (hl)

 ld a, #0x00
 ld (bc), a

 ex de, hl
 ld (hl), e
 inc l
;------------------------- 7.75 us
 ld hl, #0x0000
 ld (hl), a
 ld h, #0x00
 ld (hl), b
;------------------------- 8.5 us
 ld hl, #0x0000
 ld (hl), a
 ld hl, #0x0000
 ld (hl), a
;------------------------- 15 us
 ld a, (de)
 ld h, a
 ld (hl), b
 inc e
 inc e
 ld a, (de)
 ld h, a
 ld (hl), c
 dec e
 dec e
 inc d
 inc l
;------------------------- 9.5 us
 pop hl
 ld (hl), a
 pop de
 ld h, d
 ld (hl), e
;------------------------- 10 us
 pop hl
 ld e, l
 ld l, c
 ld (hl), d
 ld h, e
 ld (hl), b
 inc c
;------------------------- 10 us
 pop de
 ld h, d
 ld l, c
 ld (hl), a
 ld h, e
 ld (hl), b
 inc c
;------------------------- 8.5 us
 pop hl
 ld (hl), a

 pop hl
 ld (hl), a
;------------------------- 11 us
 ld d, (hl)
 ld (de), a
 inc l
 inc e

 ld d, (hl)
 ld (de), a
 inc l
 inc e
;------------------------- 10 us
 pop de
 ld h, d
 ld (hl), a
 inc l
 ld h, e
 ld (hl), a
 inc l
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #65 on: 2013.November.15. 22:36:20 »
Hát sajnálattal kell bejelentsem, hogy 64K gépet elvben is kizártam, tehát még opcionális feature -ök (pld. hang :)) nélkül sem fog menni a cucc 64K gépen.

128K alatt meg sem fog nyikkanni, és egyenlőre az LPT -m is az FF szegmens legelejétől van, és ha így marad (és egyenlőre úgy tűnik), akkor még EXOS kompatibilis sem lesz ... :(
Z80 System

Offline Mayer Gábor

  • EP fan
  • *
  • Posts: 216
  • Country: hu
Re: game00
« Reply #66 on: 2013.November.16. 00:39:09 »
no problem

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #67 on: 2013.November.16. 15:56:03 »
Na az assembly topikban ergoGnomik felvetései alapján elgondolkodtam pár dolgon,

és bár valszeg az IstvanV által megadott számítások megértéséhez szükséges időt nem fogom soha rászánni a EP alapú fejlesztésekre (így kb. soha nem lesznek olyan mély ismereteim a z80 és EP memória működéséről, amivel igazán optimális megoldásokat lehetne találni, de még az is lehet, hogy ez nem is akkora baj abból a szempontból, hogy ha ilyen szintű optimalizálásokat is figyelembe veszek, az még hatványozná a különböző verziók és lehetőségek számát, így a fejlesztési időt is.)

De mindenesetre (függetlenül attól, hogy a sprite kimásoló ciklusmagom mennyit lassul/gyorsul ha a forrása "fast" RAM -ban van, vagy nem) abból baj nem lehet, ha a sprite adatokat, és az őket kirajzoló kódot egy az assembly topikban már említett módon kölön szegmensre rakom, mely a nullás lapra lapozódik majd be.

Annál is inkább, mert ezt a gondolatot tovább vittem, és további jóságok (annak tűnő dolgok) derültek ki belőle.

Mi is a szitu:

Alap lapkiosztás:

F8 - általános kód és adat
FC - video ram 256 -os scanline- okkal, melyeknek első 104 byte -ja alkotja a scanline- t, és a második 152 byte -ja pedig szabad (ide kerültek volna eredetileg a sprite adatok).
FD - ugyanaz mint FC
FE - ugyanaz mint FC csak az utolsó 6KB már üres, jelenleg itt vannak a hangok, innen játsza le a 4KHz hangmegszak a mintákat, 4KHz -enként 2 byte kiolvasása a video RAM -ból.

Háttérben, nem állandóan belapozva:

FF - az elejét felülírtam az LPT adatokkal
F9 - csillagmozgatás kód + adat (csillagmozgatás fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a csillagokat.
FA - sprite kirajzolás kód + adat (sprite fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a sprite -okat.
FB - jelenleg még üres.

A sprite -oknak használ (nem tudni pontosan mennyit) ha "fast" RAM -ban vannak, és mivel egy sprite- jaim 16X16 pixelesek (duplázott méretű pixelek!), ezért eltolt fázisokhoz 5X16 byte kell, a szín keveréshez pedig fázisonként 2 db grafika, ezért 5X16X2 = 160 byte egy fázis. Egy lapra 102 fázis férne el, de lesz ott kód, és miegyéb, tehát mondjuk 64 fázis, ami akkor mondjuk 8 darab 8 fázisú, vagy 16 darab 4 fázisú, sprite grafika férne el, ami sztm. simán elég lehet. Vagyis a sprite -oknál veszíteni ezzel nem veszítünk semmit.

A plussz jó dolog meg az, hogy mivel a hangok úgyis a video RAM -ból vannak játszva, ezért ha már megy a csillagmozgás, meg a sprite- ok a jelenlegi kb. 6 hangos bufferrel,
akkor opcionálisan ki tudom terjeszteni egy módszerrel a hanglejátszást a kiűresedett scanline közökre.

Ugye 4Khz -en egy video "megszak" (50 Hz) alatt kb. 80X van hang megszakítás. Vagyis egy 80+pár byte -os puffer elég ahhoz, hogy 50 Hz -enként kelljen csak legyen a hang lejátszás ellenőrizve. Ez már most is így van a kódban.
Namost nekem 152 byte -om van a scanline -ok között üresen, ha lecsökkentem kicsit a hang frekijét 4KHz -ről pld. 3.5 KHz -re, akkor már elfér a 152 byte -on két 70 byte -os minta chunk (ami a 3.5KHz alatt kb. elegendő lesz 25 Hz -re), és 6 - 6 byte a két végén overhead, ami a minta korábbi ill. későbbi 6 -6 byte -ját fogja tartalmazni a minta chunk 2 végén.

Ezek a plussz 6-6 byte -ok arra kellenek csak, mivel nem tudjuk azt pontosan, hogy vajon a 3.5Khz -es megszakunk tényleg darabra megérkezik -e a videomegszakok ideje alatt.

Na ez még nekem is bonyolult volt, próbálom tisztábban:

A hangmegszak kicsit rosszabb kell legyen, mint 4KHz, mert 4KHz -en 80 byte kell egy 50 Hz -es intervallum alatt, és ha egy 50 Hz -es megszakításnyi időre csak 80 byte -ot tárolok bele a 152 byte -os területembe akkor sok memória pocséklódna el még mindíg. 2 db 50 Hz -es megszakításnyi idő meg már 160 byte lenne, nekünk meg csak 152 folyamatos byte -unk van.
Továbbá nem tudjuk az 50 Hz -es megszakjainkban pontosan elkapni darabra a hangmintákat, lehet hopgy 2 video megszak között egyszer 78 egyszer meg 83 minta játszódna le. Ezért kell kétoldalt egy kis ráhagyás, átfedés a minta chunk -ok között. Ami tovább növeli a byte -ok számát.

Tehát kicsit lejjebb megyek a hang frekivel úgy, hogy 152 byte -ba beférjen 2 50 Hz -es megszak idejéhez szükséges hangminta + az átfedések. Ez kb. úgy 3.5 Khz körül lesz.

Beállítom a hanglejátszást a hangmintám első darabkájának az elejére, és elindítom a lejátszást.
A hangmegszak az eddig megismert módon semmivel nem törődve, maximális sebességgel tolja a hangot.
Majd 2 50 Hz -es megszakításnyi idő múlva (mert tudom, hogy ennyi időre biztosan van elég hangmintám) , átírom a hangmegszak címét egy olyan rutin címére, ami elvégzi a csekkolást is, nem csak a hangot adja.
Ez a megszakítás megnézi (csak 25 Hz -es lefutással ugye), hogy a hangom pontosan melyik mintánál jár (nyilván az átfedő 6 byte -os részen kell legyen), és úgy állítja a következő scanline üres helyére elhelyezett hang chunk -ra, hogy ott meg a kezdő 6 byte -os tűrési zónán belül a megfelelő "folytatás" hangminta legyen.
Ezután a megszak címet persze visszaállítja a gyors lefutású hangmegszakra.

Igy akkor az össz sebesség szerintem növekedni fog, mert levettük a hangferit 3.5 KHz -re, és csak 1/25 Hz -enként nézzük meg részletesen a hangminta pozícióját.

És kapunk még 16K-18K hang memóriát a meglévő 6K -hoz ... lesz kb. 24K hang buffer ... az már akkor kb. 7 másodperc hang ... vagyis lehetne pár hosszabb is ...

És mindez opcionális, ráérek akkor ha már látszik valami, és a futáson csak gyorsítani fog.
« Last Edit: 2013.November.16. 16:05:20 by Z80System »
Z80 System

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 9898
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: game00
« Reply #68 on: 2013.November.16. 21:13:35 »
Quote from: Z80System
lapkiosztás
Akkor ez valami kártyajáték demó lesz? :D
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #69 on: 2013.November.16. 22:35:29 »
Nem akar összejönni nekem ez a nulláslap váltás ...

A nulláslap első 100H -ját természetesen átmásoltam az összes olyan szegmensre, amiket be akarok lapozni a nulláslapra.

Megy ugyan egy aktív megszakítás (4KHz hang), de az gondolom elvégzi a dolgát annak a szegmensnek a 100H alatti területébe, ami be van épp lapozva, és mire visszatér, addigra minden ugyanaz mintha nem is lett volna megszakítás. (A megszak nem lapoz, meg semmi, és csak a hármas lapról olvas.)

Szóval lehet, hogy csak én bénázok el valamit, de elég érthetetlen jelenségek vannak egyenlőre a debuggerben, szóval lehet van itt valami elvi hiba, amiről nem tudok ?

A megszak úgy van bekapcsolva, hogy a 0x38 -ra van írva egy "JP megszakom". Olyan szegmenseket is használok, ami lehet, hogy az EXOS -nál van, de ha én nem hívok EXOS -t, akkor ezzel a megszak bekapcsolással az EXOS ki van zárva, igaz ?

Lehet itt valami elvi hiba ?
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #70 on: 2013.November.16. 23:26:01 »
Na meglett ... amikor átváltom a nullás lapot, akkor az IRQ rutin kódja nincs duplikálva az új lapon ... :oops:
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #71 on: 2013.November.16. 23:37:08 »
Quote
mér nem gyün?

Hát mer itt bénázok vele, látod ...

Napokig optimalizáltam itt a csillagokat, erre 3 sorral lett rövidebb ...

Most meg mikor kiderült, hogy sprite -okat is külön szegmensre teszem, ezért megcsináltam ezt a "DLL" funkciót általánosra, és így nem kell már kódokat írjak, ami összerak egy másik nulláslapra szánt szegmensen egy programot, hanem rendesen különálló forrásokból, egy teljesen önálló programot fordítok ezekre a funkciókra, és a programom képes betölteni őket és funkciókat hívni rajtuk.

Tehát mint a DLL -ek, vagy mint az EXOS bővítők úgy működnek most ezek a programok, így csak a rendelkezésre álló szegmensek limitálják, hogy hány szegmensen lehet a kód.

Persze a nulláslap lapozgatásának nehézségei miatt csak jó "nagy" feladatokra érdemes ilyet használni, mint pld. "csillagok" egyben, vagy "sprite -ok" szintén egyben ...
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #72 on: 2013.November.16. 23:37:41 »
Magyarul nem fícsőrt írok, hanem engine -t fejlesztek ... :)
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: game00
« Reply #73 on: 2013.November.16. 23:48:43 »
Megszakítás probléma megoldva. Fogtam a 18 bájtból álló hang megszakomat, és bemásoltam konkrétan a 0x0000 -ra, még azelőtt, mielőtt lemásolom a dinamikusan betöltött új kód szegmensekre az első 100H -t.

Magyarul az összes nulláslapon használt szegmensen ott lesz 0x0000 -tól a megszak kódja. Igy most fut.

Jól gondolom, hogy legális azt a területet használni ?
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: game00
« Reply #74 on: 2013.November.17. 12:52:45 »
Quote from: Z80System
Magyarul az összes nulláslapon használt szegmensen ott lesz 0x0000 -tól a megszak kódja. Igy most fut.

Jól gondolom, hogy legális azt a területet használni ?
A 0-2Fh terület szabadon használható 5-ös fejlécű programban. De ha a játék futása közben már nem kellenek az EXOS hívások és az EXOS megszakítás kezelője, akkor célszerűbb 38h-ra másolni, és megtakarítani a JP utasítást. A RESET gomb lenyomásakor az EXOS visszamásolja az eredeti kódot a 30h-5Bh területre. De a játék is elmentheti és visszaállíthatja az EXOS 0. lap kódot, ha szükség van rá a játék közben is (általában nincs).