Hmmm ... lehet, hogy csak a spanyolviaszt találtam fel, de ha így van, én akkor is csak most világosodtam meg. Ugyan régebben is hallottam, hogy vízszintes scroll -t lehet csinálni EP -n karakteres módban, de én ezt sosem találtam igaznak, de most mégis bekattant nekem is, hogy lehetne megcsinálni, és miért is lenne jó.
A dolog előnye egy standard grafikus módban elkövetett vizszintes scroll -hoz képest (egy olyanhoz képest pld. amit IstvanV csinált legutóbb), hogy a tile -ozottan tömörített grafika megjelenítése hardverből támogatott lenne, és hogy a dupla képernyő nem a pixel információt duplázná, hanem csak a karakteres (index) memóriát.
Vagyis igaz rá, hogy egy diszkrét karakterszettből aztán hatalmas nagy pályákat lehetne a memóriában tartani, és a maga a scroll ideje egy a maximum képernyőre csak kiférő (tehát fullos méretű) képernyőnél szerintem nem lenne több 6-10 pixelsor raszteridőnél. Vizszintes scroll -hoz ez pedig marha jó EP -n.
A dolog egyik hátránya hogy igen erősen kéne tile -ozni, ráadásul igen erősen szögletes tile -ozni, mert csak nagyon kevés számú tile (karakter) állna a rendelkezésre a pálya összerakásához.
A dolog másik hátránya pedig, hogy a karakteres módokban a grafika LORES, vagyis a megszokott felbontásunk feleződne az adott színüzemmódokban. Ami azt jelenti, hogy normál "320 -as" felbontásunkkal nem 4 hanem csak 2 színnel a "160 -as, téglás" felbontásunkban pedig nem 16 hanem csak 4 színnel rajzolhatnánk.
Ugyan a grafikus módokkal szemben a karakteres módoknál bizonyos karakterhatárok és karakterszámhatárok betartásával ki lehet használni a palettánknak mind a 16 színét, ezeknek felhasználása csak egesz extrém körülmények között lenne lehetséges akkor, ha az atributum jellegű sprite átszíneződéseket ki akarjuk zárni. Részemről az attributum hibák a létező legocsmányabb dolgok a világon, csak a lehető legkevesebb játéknál tudták ugy használni őket, hogy az ne legyen iszonyat gány. Szóval én inkább a kevesebb, akár 2 szín mellett vagyok, ha az attributum hibák megjelenéséről lenne szó.
Egyszóval vizszintes scroll, karakteres módban, hatalmas de durván tile- os pályák jól tömörítve, nagyon gyorsan, de kevesebb színnel és/vagy rosszabb felbontással mint a megszokott grafikus hires mód:
S= space karakter kód (üres karakter, csupa 0 a grafikus területe)
A,B,C,D= négy különböző karakter kód
X,Y=még két különböző karakter kód
Egyszerűség kedvéért legyünk "320 pixeles" két színű karakteres módban (hozzáértőknek: LORES 2 szín), de igaz minden színüzemmódban.
SSSSSSSSSSSSSSSS
SSSSSABSSSSSSSSS
SSSSSCDSSSSSSSSS
SSSSSSSSSSSSSSSS
Ezzel a sormintával a karakteres képernyő memória kis darabkáját ábrázoltam ahol sok space közé be van rakva négy karakter.
Képzeljük el, hogy az A,B,C,D karakterek 4 olyan karakter, ami egy 2X2 karakteres blokkot alkot, vagyis ugye itt most 16X16 pixelt, és ebbe a 16X16 -os blokkba bele van rajzolva egy láda (vagy barmi más tile).
Vagyis a nagy semmi kozepén van egy 16X16 pixeles tile- unk.
( Namost ha ezt az A,B,C,D -t a kepre több helyre is felraknánk, akkor ugye az összes helyen megjelenne a 16X16 pixeles grafikánk, de ezt most nem tesszük, csak simán egy marad.)
Namost azt akarjuk, hogy a képernyőnk kezdjen el scrollozni. (Egyenlőre csak jobbról jöjjön a pálya és balra menjen, de lehet 2 irányba is, dupla karakterkészlettel mint egy irányba.)
Ehhez végigmegyünk a pályán egy preprocesszáló kóddal (vagy kézel, ha űber kevés tile -lal dolgozunk) és balról jobbra megnézzük, hogy hány olyan kombinációt tudunk találni, úgy, hogy egy karakter mellett egy másik karakter van. Ezeknek a kombinációinknak a száma nem szabad meghaladja majd a teljes pályaelemkre szánt karakterkódjainknak a számát. Mivel a karekterkészletünk 64,128,256 darab karakterből allhat mindössze, és a mozgó elemek megjelenítéséhez is igen sokat kell majd fenntartani, ezért igen szűkre szabott ez a szám.
A fenti példánál ez a kombinációkeresés azt fogja eredményezni, hogy ugye ezeket a kombinációkat találjuk:
- olyan kombináció, ahol S mellett S van, vagyis ha scroll -ozási irányt is nézzük: S<-S, és mivel tudjuk hogy ez üres teljesen, ezért ezt a kombinációt továbbra is S karakterkóddal fogjuk ábrázolni.
- aztan lesz olyan kombináció, ahol S mellett A van, vagyis: S<-A, itt már A -nak van mintája, ezért erre a kombinációra felveszünk egy új X karakterkódot
- aztan előbbi mellett: A<-B, itt meghagyjuk az eredeti A karakterkódot, hogy a példa egyszerű legyen, valójában ezt A vesszővel kéne jelölni, mert ez már nem az eredeti A karakter kód lesz, hanem ugye az A<-B átmenetet jelképező karakter kód.
- aztan a: B<-S, ami B marad.
- aztan lesz még: S<-C, amire felvesszük Y karakterkódot.
- meg: C<-D, ami C lesz.
- es az utcsó: D<-S, ami D lesz.
mindezek után módosítjuk a karakteres memóriánkat így:
SSSSSSSSSSSSSSSS
SSSSXABSSSSSSSSS
SSSSYCDSSSSSSSSS
SSSSSSSSSSSSSSSS
És csinálunk 8 teljes karakterkészletet, amelyekben az X,A,B és Y,C,D karakterek (tehát vegyük észre hogy nőtt a tile -unk helyigénye 4 -ről 6 karakterre!) scrollozása előre ki van számolva, minden karakterkészletben egy pixellel balra vannak tolva a dolgok.
Ha ezután nem nyúlunk egyáltalán semilyen memóriához, tehát meg a karakterkód memóriához sem, csak valtogatjuk az LPT -ben (vagy akár előre generált 8 LPT -vel, abszolút csak LPT portváltással) a karakterkészletet, akkor a tile 7 pixellel el fog scroll -ozódi hardverből. Ha a most már 6 karakteres (X,A,B,Y,C,D) tile -unkat több helyre felteszük a képre, akkor természetesen minden példány el fog scrollozódni.
Természetesen a nyolcadik pixelhez visszaváltjuk a normál karakterkészletre az LPT -t, és a karakter kód memória címét állítjuk egy karakterrel arrébb. Ehhez kell már memória írás, de mivel karakteresek (8 pixelsor) az LPB -jeink magasságban is, ezért csak nagyon kevés címet kell arrébb állítanunk. Természetesen a bejövő karakterkódokat pótolnunk kell a jobb oldalon, és hogy ne kelljen egy teljes képernyőnyi karakter kód memóriát másolgatni, ezért a karakterkód memóriánal ugyanazt a duplázást lehet használni mint a pixeles vizszintes scroll- nál, vagyis inkabb minden (nyolcadik pixel után) esetben 2 helyre másoljuk ki a belépő karakter kód oszlopot, így két képernyőt építünk, melyre egy teljes képnyi scrollozás után visszaválthatunk.
Ezek után a mozgó dolgokat már valós karakterkód és karakterkészlet memória manipulációval ki kell rakjuk, kicsit még bonyolultaban is, mint a grafikus mód esetében, de nagyságrendileg ugyanannyi idő alatt, mint a grafikus módnál.
Így viszont maga a vízszintes scroll sztm 10 rasztersor alatt tartható, vagyis szinte a teljes idő a sprite -ok kirakására és minden másra fordítható ...
