Továbbgondotam a témát.
Általában a Z80-as rendszerekkel az a baj, hogy hiába fejlesztek ki 8bit/pixel, vagy ettől magasabb képmegjelenítést, ha a memória töltögetése rengeteg processzoridőbe telik, és a Z80 nem igazán tud ekkora mennyiségű adattal dolgozni.
Az EP karakteres megjelenítési módja (más gépeknél a csempe alapú rendszer) pont erre van kitalálva. Meghatározott csempeméretek esetén megsprórolható rengeteg byte.
320x240 és 1byte/pixel esetén a videomemóriában kell 72KB hely. Ez csak a "frame buffer, tehát amit látunk". Emellett szükség van memóriára, ahol a képelemeket tárolom. A játék nagyságától függően ez lehet akár ennek 2-3-4 szerese. Mai hardverrel nem probléma 3MB-ig kiterjeszteni a memóriát, csak nem szabad elfelejteni, hogy 8 MHz-es CPU-val dolgozunk, neki is van más dolga.
HA 8x8-as "karakterekkel dolgozom, akkor a 72KB / [8pix x 8pix ] = 1,12 KB elég a képtartalom vezérlésre. 16x16 csempe esetén ennek fele kb. 0,6 KB elég.
A másik dolog, hogy sok játéknál a padló/falak stb. ismétlődő sormintával rendelkeznek, tehát felesleges ezeket rajolgatni nagy mennyiségben.
Tehát arra jutottam, hogy az új módban, ahol 256 színnel dolgozok, kiterjesztem választhatóan 8x8 pixeles vagy 16x16 pixeles "karakteres módra", ahol a LD1 címen lévő 1BYTE/karakter adathalmazzal kijelölöm, hogy az LD2 címen lévő 8x8 vagy 16x16 és 1byte/pixel képecskékből melyiket kérem a képernyőre.
További extra a látható kép diszlokációja (eltolása x és y irányban) lehetséges lesz, azaz megadható, hogy egy adathalmazt hol kezdjen el olvasni. Ezzel a könnyű és gyors scrollozást szeretném bevezetni, mint ahogyan az EDITOR működik a basicben. Az egyszerűség és gyorsaság kedvéért úgy fogom megoldani, hogy kiad egy
OUT 8C,xx utasítást, ahol a 8 bit így néz ki
(MSB) xxxxyyyy (LSB)
xxxx egy előjeles eltolási érték ami lehet min:-6 és max:+6. A "1000" értéket megadva reseteli az eltolást 0-ra.
Egyszer kiadva az eltolási paracsot, csak egyet tol a képen. A következő eltoláshoz ismét ki kell adni. Az eltolás parancs megvárja amíg a félkép befejeződik és csak utána lesz érvényes, hogy ezzel elkerüljük a sorok közötti elcsúszást (screen tearing).
Még egy extra kellene szerintem, hogy az LD1 és LD2 mellett bevezetném az LD3 mezőt, ahonnan egyszerre olvasná a pixeleket az LD1-gyel, és a kedves programozó döntené el, hogy a két háttérképet hogyan kombinálja:
00: LD3 nincs megjelenítve
01: LD1 hátul LD3 elöl (LD2-ben valamelyik szín a 256-ból nem írja felül (áttetsző) a LD1 pixeleit)
10: teszt: LD1 és LD3 összeadódnak, és azt jelenítjük meg
11: teszt: LD1 és LD3 pixelei kivonódnak, és azt jelenítjük meg
A sprite ok tárolásán gondolkodok még. Nem hiszem hogy a háttérrel kellene spekulálni. Kellene egy 8x8-as SPRITE táblázat, ahol deklarálni lehet a SPRITE-okat, és eldönteni, hogy hol legyenek megrajzolva: LD1 háttér mögött, LD1 és LD2 között, LD2 előtt.
Erre nem nagyon tudok más megoldást, mint NICK 2.0-ban tárolt SPRITE táblázat, és memóriában tárolt alakzat. A sprite mérete még kérdéses, majd a tesztek megmutatják meddig lehet elmenni.
