Amennyire én tudom a demó definíciójában az is szerepel, hogy a gép képességeit minél jobban kihasználó program.
Ezek a képek (ill. a megjelenítő program) amelyeket endi említett elég rendesen kihasználják gépünk grafikai képességeit, szóval akár demónak is tekinthetjük. Sőt, ilyen képekkel bármelyik demót fel lehetne dobni. Annak aki akkor látná először biztos tátva maradna a szája. A demókba egyébként is szoktak képeket rakni, átvezetésnek is. Ezeknek a képeknek a megjelenítése szép teljesítmény gépünktől és persze Istvántól és Zozotól. Pár másodpercnyi érdekességnek semmiképp sem nevezném.

Na jova, ugy laccik jobb lesz, ha csendbe maradok, mer meg kihuzom a gyufat ... raadasul nem is abba az iranyba megyunk amerre szerettem volna, nem a definialgatasok, meg ilyenek lennenek a cel, megha pongyolan fogalmaztam volna, vagy akar tokhulyesegeket is ...

Istvan es Zozo teljesitmenyenek megkerdojelezese meg veletlen sem allt a szandekomban. ( Mint emlitettem az emuban dolgozok, amit a mai napig nem ertek hogyan lehet csak ugy jatekbol, kedvtelesbol elkesziteni ennyire jora, mikozben Zozo a mindenkori helpem, barmi van, mindig tole kerdezek )

Es valo igaz, kihagytam, hogy a felfele scrollt engedelyezi az ep hardware- e, a c64- e meg tulajdonkepp csak a vizszintest, ugyhogy 1-1.

Nem is ezen cirkuszoltam, hanem hogy az ember mikor regen gepet vett, akkor az volt neki, es semmi mas, es azt varta, hogy mindent lehet, csak meg kell neki tanulnia. Es mikozben szepen megtanulta rajott, hogy hat azert nem lehet mindent ...

Es most mikor +15 ev programozas utan ujra probaltam valamit, ujra ledobbentett, hogy milyen marha lassan lehet akar csak par pixelt is szoftverbol (nem nick trukkel) megmozgatni a kepen.

A wopus tippedrol ( a keperol ) jutott eszembe, hogy ja tenyleg, a felfele scroll az tamogatott, a nick kepessegeit kihasznalva meg lehet mozgatni egy teljes kepernyonyi grafikat fuggoleges iranyaban. Ennek a kodnak az elemzese azonban nem szukseges, mert ezt tudom hogy kell csinalni.

Csakhogy ha hiszed ha nem, az mar hogy egy par sprite- ot kirakj arra a felfele scrollozodo kepre, foleg ha az 50Hz hataron belul ( legfolyamatosabb mozgasu kep, rangatozas nelkul ) az mar egy z80- t probalo feladat. Sot, ha engem kerdezel, igazabol az en izlesem szerint, el is bukik az EP a megmerettetesben. Pld. sztm az kielegito lehetne, ha mondjuk 4 szinu uzemmodban, 32*32 pixeles sprite- okbol ki lehetne tenni ugy 16 darabot 50Hz- el, ugy kb 50% cpu idovel...

Az viszont erdekelne hol irnak olyat hogy bitleptetesekkel remekul lehet scrollozni... egyreszt sztm a kepernyo felso ket pixelsorat lehetne max megmozgatni ( trukk nelkul! ) z80- al ...

Amikor scanneltem a könyveket viszont pont az feltűnt, hogy a gépi kóddal foglalkozó könyvek megemlítik, hogy a rengeteg bitléptető-, rotáló utasítással nagyon hatékonyan lehet vízszintes scroll-t csinálni.

Igaz, csak a képernyő egy kis részén Még a legegyszerűbb esetben (2 színű LPIXEL mód) sem lehet bitléptető utasításokkal megoldani egy "Spectrum méretű" képernyő scrollozását másodpercenként 50-szer, csak kb. a felét, és akkor másra már nem is nagyon marad idő.
Vízszintes scrollra fel lehet használni az LPT-ben az LD1/LD2 címek módosítását, bár így csak fél karakteres felbontással lehet mozgatni a képet (PIXEL módban, egyébként csak egész karakterekkel), ami vagy túl gyors, vagy darabos és nem túl jól néz ki. De talán a másodpercenként 25-ször fél karakter elfogadható.

EP-s demo készítésénél az LPT valós idejű módosítására (video cím, paletta, margók) érdemes építeni, mert így sokkal kevesebb adatot kell feldolgozni adott idő alatt, mint maguknak a pixeleknek a változtatásával. Egy nagy, előre kiszámított állóképből ilyen módon érdekes effektusokat lehet létrehozni. Ennél a scrollnál például csak a 8 paletta szín változik:
[ Guests cannot view attachments ]
Egy kép vízszintes mozgatását vagy "hullámoztatását" meg lehet oldani úgy is, hogy a video cím (és esetleg a margók) állításával fél karakteres mozgatás legyen, és ezen kívül 2 vagy 4 kép legyen a memóriában a fél karakteren belüli fázisokhoz.
Talán a karakteres módokat is fel lehet használni; a karakterek vagy a karakterkészlet változtatásával szintén gyors animációt lehet elérni.

Pld. sztm az kielegito lehetne, ha mondjuk 4 szinu uzemmodban, 32*32 pixeles sprite- okbol ki lehetne tenni ugy 16 darabot 50Hz- el, ugy kb 50% cpu idovel...

PIXEL módban ilyenből (egy sprite 8*32=256 byte) szerintem 2-t lehet megoldani, ha fontos, hogy a sprite-ok megfelelően takarják a hátteret, és az eredeti pixeleket vissza is lehessen állítani. Egyszerű XOR művelettel valamivel gyorsabb, de nem sokkal. A byte-ok felülírásával kb. kétszeres gyorsulást lehet elérni.
A karakteres mód, a sprite-oknak a karakterkészlet egy részét fenntartva jobb, mert a háttér mentése/visszaállítása csak a karakterek, és nem a pixelek másolását jelenti. Természetesen a leggyorsabb a karakteres mód takarás nélkül (de a sprite-ok tartalmazhatnak például egyszerű fix hátteret, amely minden karakternél egyforma), így már talán nem probléma a 16 4x4 karakteres sprite.

Timeslip -ben az volt a lenyeg, harom palya volt, attol meg a c64 hw alapbol az egesz kepet eltolja, idozitessel kell allitani a hw scroll regisztert az osztott scrollhoz, de meg lehet csinalni az a lenyeg, vizszintesen, kb. 0 prociidovel.

Tobbi felsorolt jatek (ha jol emlekszem mind) spectrum atirat, tehat az attributum grafikat scrollozzak /sprite- oljak, sztm nem elegseges performanciaval. ( lassu akadozos cuccok ... ) anyam... en leszek az EP fekete baranya ...

Azt nem lehet gépi kódú programozással megoldani, hogy a képet fordítsa el 90%-kal? Mert ezzel a függõleges scrollból egybõl vízszintes lehetne.
(Másik megoldás, ha a tévét/monitort fordítjuk el 90%-kal. )