Hát elég határeset ... IstvanV nem egy kókler, biztos nem lehet azt az oszlop hozzáadó+lpt hekkelő kódot nagyságrendileg csökkenteni időben (biztos nem teljesen rossz már az most sem), vagyis az bizony 40% ... Két vacak pixeloszlop frame -enként ... és ráadásul egy folyamatos memóriatérképről másolja, nem játékokhoz szükséges, karakterszerű blokkokból rakja össze. De még ha ez nem is számít, ez akkor is 30-40 % -a a rendelkezésre álló időnek.

Ez jelenleg frame -enként 400 pixel ( mindket képre egy plussz pixel oszlop ) megmozgatása ... ezt még duplázni lehet (vagy már lehet most is úgy van) azzal ha a forrás grafika is megvan eltoltan is letárolva, akkor 800 pixel per frame.

800 pixel tehát 40% processzoridő.

16 darab 16X16 pixeles sprite = 4096 pixel ... amit nem csak kirakni kell, hanem el is kell menteni ugyanennyi pixelt alóluk ... Naggyon - naggyon cipőkanalas dolog ez az 50 FPS -sel valami jatékgrafikat kirakni téma EP -n ...

Ez jelenleg frame -enként 400 pixel ( mindket képre egy plussz pixel oszlop ) megmozgatása ... ezt még duplázni lehet (vagy már lehet most is úgy van) azzal ha a forrás grafika is megvan eltoltan is letárolva, akkor 800 pixel per frame.

Nem pixel, hanem byte oszlopot kell mozgatni, tehát 400 pixelt beléptetni egyszerre két pufferbe, az egyikben egy pixellel eltolva (amihez szükség van a következő oszlopra is). Ezen kívül a jelenlegi kód először két byte oszlopot egy átmeneti pufferbe másol, és utána ezt használja a rajzoláshoz; itt lehetne optimalizálni kevesebb másolással.
Egyébként C64-en ennél valamivel több időt igényel egy teljes karakteres képernyő (de nem a szín memória) mozgatása, még ciklus nélkül 1000 LDA/STA utasítással is. EP-n a nagyobb probléma a hardveres sprite rajzolás hiánya, ezért célszerűbb játékoknál 25 fps-re korlátozni a sebességet.

16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:

Nagyon jó. 

Nagyon jóóó lett
Majd megnézem ,hogy mennyivel megy  a Sub Hunter.
Amúgy a 25fps-es mozgatás is folyamatos, egyáltalán nem darabos.

16 színű, 928x200 méretű kép pixel felbontású vízszintes scrollozása 160x200 méretű ablakban, 50 fps sebességgel:

Jó lett!
Viszont azt nem értem, miért foglalja le az összes szegmenst, akár 640kB, akár 1024kB RAM van a gépben... .-)

Hogy van az hogy 2 pixelsor kimásolása az 0.3 frame idő,
de egy teljes képernyő kimásolása meg belefér 2 frame időbe, sprite -okkal, mindennel ?

Ez így nem igazán hasonlítható össze, mert:
- a "2 pixelsor kimásolása" valójáben nem annyira egyszerű (egy byte feldolgozása viszonylag sok utasítás), és még lehetne rajta optimalizálni is
- a "teljes képernyő" a Sub Hunter esetében kis méretű
- a Sub Hunter valójában nem is scrollozza a képet, hanem csak egyszerű 1-4 karakteres ismétlődő animált mintát rajzol ki PUSH utasításokkal (C64-en ez egy fix háttér lenne karakters módban, a karakterkészlet animációjával)

Képet hogy tudunk konvertálni a scroll-rutinhoz?

Hát ez az ...

Hogy van az hogy 2 pixelsor kimásolása az 0.3 frame idő,
de egy teljes képernyő kimásolása meg belefér 2 frame időbe, sprite -okkal, mindennel ?

Nekkem itt valami büdös ...

Hát valahogy úgy, hogy a hullámok nem másolva vannak, hanem fixen a kódba van ágyazva minden képernyőre kerülő bájt, a sprite-ok kicsik, és kb a 24x30-as kép 2/3-án zajlik a játék, és ott nincs bitművelet se 400 bájton, ja ,és azt nem néztem, hogy pixelenkénti scroll van benne, vagy byte-onkénti.