Á, szép álom volt, de a csillagmozgás beborította, szóval vissza a legkorábbi felálláshoz:
f8 - common
f9 - stars
fa - sprites
fb - samples
fc - video ram + sprite graphics
fd - video ram + sprite graphics
fe - video ram + sprite graphics + lpt
ff - exos (kenje a hajára)
b0:
f8 - általában ez van itt, és csak ideiglenesen lapozzuk el
f9 - ha meghívtuk a csillagkirajzolást
fa - ha meghívtuk a sprite kirajzolást
b1:
fc - általában ez van itt, és csak ideiglenesen lapozzuk el
f9 - ha be akarunk valami paramétert állítani a csillagkirajzolónak hívás előtt
fa - ha be akarunk valami paramétert állítani a sprite kirajzolónak hívás előtt
fb - hangmegszaknál a megszak lapozza be magának hogy elérje a hangmintákat
b2:
fd
b3:
fe
Alapgép: 128K -s EP. 64K -s gépre nem csinálok verziót.
Bővített gép: minimum kb. 4-8 szegmenssel bővített memóriájú gép. Ha végül lesz ilyen verzió, akkor szerintem inkább 8.
common:
Általános kódok, bufferek, cache -ek, táblák, magas szintű játéklogika, ellenségmozgatások.
Ez a szegmens fog saját maga alól kilapozós cross-segment hívásokat kiadni és azok ide térnek majd vissza.
Természetesen ezek a hívott szegmensek is tartalmazni fogják az első 100H -át, ami tartalmazza magát a teljes hangmegszakot,
és a sajátmaga alól kilapozós cross segment hívási és visszatérési kódokat, valamint a stack -et is.
Ha a stack esetleg kicsi lesz valamiért akkor az első 200H lesz ismételve, vagy ilyesmi.
Ezek jelenleg a stars és sprites kódokat tartalmazó szegmensek lesznek.
Ezekből bővített gépen több is lehet persze, alapgépen mindegyikből csak egy lesz.
stars:
Egy 46* 256 bájt méretű csillagmozgatás táblázat (gyakorlatilag előre letárolt animáció) egy speciális formátumban,
melynél gyakorlatilag nem találtam jelentősen gyorsabban megjeleníthető formátumot, ami méretben ne lett volna
minimum dupla, de akár 3-4 szeres méretű.
sprites:
Grafikát is inline magába foglaló sprite fázis kirajzoló rutinok, köztük az eltolt fázisokkal és a törlő rutinokkal.
Ezeket a rutinokat ellenségváltás közben (bővített gép esetén, ahol lehetne hozzá háttérszegmens, esetleg konkrétan játék közben)
remélném generálni a raw grafikából.
Sajnos csak 8-16 (*4 eltolás) darab sprite fázis fog beleférni a szegmensbe, ami mondjuk azt jelentheti egy rosszabb esetben,
hogy ha a főhős karakternek van 4 fázisa, akkor mondjuk az ellenség csupán 1 darab 4 fázisú dolog lehet, vagy 4 db 1 fázisú, stb ...
Arról még lövésem nincs, hogy milyen gyorsan tudom majd generálni ezt a szegmenst a raw grafikából.
Remélem nem fogja a gameplay -t nagyon beszaggatni.
samples:
Hasonló mint az előző, csak nem sprite kódokat cache -el egy pillanatnyi játékhelyzethez, hanem hang mintákat.
Előzőhöz képest különbség, hogy alapgépen csak fel lesz töltve és kész, mert nem lesz honnan összemásolni másik készleteket.
Bővített gépen éppúgy ahogy a sprites kódokat, ezeket is ellenségváltáskor vagy menet közben tervezném összemásolni.
Olyan 8-16 hangminta fog beférni a szegmensre, amit random módon lejátszogathatok játék közben.
sprite graphics:
Raw sprite grafika, ami a 100h -ás sorok közeiben van elrejtve, 1-2 sprite fázis fér el egy közben. Leíró táblák a common szegmensen.
Innen generálom le a sprites szegmenst. Olyan 100-300 sprite fázis fér be még alapgépen is, szóval hely az lesz a grafikának, csak grafika is legyen ...
lpt:
Scanline -onkénti lpb -kből álló lpt, két végén annyi plussz lpb -vel, hogy azok a sprite -ok melyek lpt -t (színeket) is manipulálnak azok ne kelljen
figyeljenek a vágásra függőlegesen itt sem. Lesz jó sok szín ...
exos:
Mivel a legújabb erővonalak mentén haladva játékmentést is akarok, esetleg pálya adat betöltést is, ezért mégsem nyírhatom ki az exos -t.
Szóval a szegmensét egyszerűen kihagyom. További exos kompatibilitásra azonban továbbra sem törekszem.
video ram:
Sokat nyűglődtem, hogy megtartsam -e a 100h -ás scanline -okat vagy sem, illetve ha meg is tartom (és így a video RAM 3 szegmensre is szétnyúlik)
akkor megkövetelhessék -e a rajzoló kódok hogy mindhárom szegmens folyamatában be kell legyen lapozva miközben rajzolnak,
vagy tanítsam meg a kirajzolókódokat vágni függőlegesen és lapozzák be maguknak mindíg a szükséges szegmenst.
Különösen problémás a helyzet amiatt, hogy digi hangokat tervezek a játékhoz, aminek a 4K -s megszakítása folyamatosan működik (ami kb. 80 hívást jelent 50Hz -enként ugye),
és azt a megszakítást értelem szerűen a lehető leggyorsabbra kellene megírni, így árnyékregiszteresre lett megoldva, ami nem csinal mást mint beírja a két hangerőportot
(HL),(DE) -ről, majd növeli HL,DE -t. Namost ha a video ram 3 és a 0 -as lapon levo kirajzoló kód 1 lapot igényel, akkor hova rakom a hangmintás szegmenst kirajzolások közben.
Felmerült még bennem, hogy 50 Hz -en másolom a 0 -as lapra a 2* 80 körüli hangmintát, amit aztán a hangmegszak onnan játszhat a következő 80 hívódásakor,
de ez egyrészt nem tetszik, mert ez kb- mínusz 1-2 sprite lenne időben, amiből amúgy is kevés lesz, másrészt pedig ne felejtsük, hogy sajnos a 0 -ás lap sem fix,
az is változik 50 Hz -en belül N -szer ...
A sprite kirakó kódokat még viszonylag 0 időveszteséggel meg lehetett volna tanítani függőlegesen vágni a szegmenshatárokon, viszont a csillagmozgást képtelen voltam
kitalálni nem lassabbra, de lapozást kezelőre. Nem beszélve az esetlegesen közben felmerűlő egyéb rajzolókódokról, amiket még nem is tudom mik lesznek.
Szóval úgy döntöttem megmarad a 100h -ás scanline, sőt vágni sem tanítok meg semmit, a rajzolókódok igényelni fogják a 3+1 lapot,
és a hangmegszakba rakok mégis lapozást.
Remélem ezzel bukom a legkevesebbet, bár még nem mértem ...
Ez volt a régi hangmegszak:
void IRQ() __naked
{
__asm
IRQ_B:
ex af, af
exx
ld a, #D_Ints+ 0x2
out (0xb4), a
ld a, (de)
out (0xa8), a
inc de
ld a, (hl)
out (0xac), a
inc hl
exx
ex af, af
ei
ret
IRQ_E:
__endasm;
}
És ezt kell kibővíteni még a lapozással:
ld a,b //hangszegmens be
out (0b1h), a
ld a,c //video szegmens vissza
out (0b1h), a
Ez fog 80X meghívódni plusszban egy 50Hz -es időintervallumban ...