Jól értem, hogy a sprite adatokat a videoszegmensekben akarod tárolni?
Hát sajnos jól ...
Az van, hogy nem tudom ez mennyit fog lassítani, még a csillagokkal vackolok mindíg, nem értem még el a sprite -okig, és az eddigi sprite tesztjeim persze "fast" RAM forrással történtek, de (eddig) abban reménykedtem, hogy itt EP -n ez a video RAM olvasás dolog majd nem sokat fog lassítani.
Mivel a kirajzoló kódok gyorsítása érdekében 100H -s képernyő scanline- okkal dolgozok (hogy ne kelljen a függőleges koordinátákat szorozgatni scanline mérettel), ezért a képernyőm megenne 3 szegmenst gyakorlatilag, és muszaly kihasználnom a közöket, nyilván helyfoglalás szempontjából adják magukat a sprite adatok.
Ahhoz hogy ne kelljen a közöket kitöltenem, ahhoz vagy szakítanom kéne a 100H -s scanline- ok módszerével (ami nem 100%, hogy hülyeség lenne, ha ez a video RAM olvasás dolog tényleg sokat lassíthat),
vagy pedig akkor a középső két lapon nem tarthatnám ott fixen a video szegmenseimet, hanem egyik egy forrás "fast" RAM szegmens kéne legyen, de akkor minden kódomat úgy kéne írjam, hogy a lapozgatást kezelni tudja.
Ami azt jelentené, hogy egy sprite egyik felét tudni kéne kirajzoljak mondjuk egyik lapozás mellett a kepernyő felsőbb, másikat másik lapozás mellett az alsóbb részére ... ami részint további bonyolódást jelentene, részint hát ott van a függőleges csillagmozgás is, ahol akkor a direktben tárolt 2 szegmensnyi adatot igénylő verziót kéne alkalmazzam, és egyrészt túlzásnak is tartanám, másrészt akkor már csak egy szegmens maradna mondjuk a grafikának, és már el is fogytak ... pedig egy ilyen kavarásnál már kijárna a hangnak is egy külön állandóan belapozott 16K -s teljes szegmens ...
Vagy pedig még azt lehetne, hogy 128K gépen sem mennék ... hanem kellene a 128K -n felül 1-2 plussz szegmens is ...
Szóval egyrészt nem tudom mennyi lesz ez a lassulás a video RAM olvasásból, másrészt nem tudom előzőek közül melyik kezembe harapjak.