A bias, vagy a border értékét nem lehet csak karakter pontosan pozícionálni a képernyőn? Egész délelőtt ezzel szórakoztam, megpróbáltam összehozni egy bias által színezett képet, egy soron belül 7x vált, és ezt szerettem volne eltolni negyed karakterrel, ami az utasítások miatt adott is lenne, de bárhogy játszottam vele, csak karakteres eltolás valósult meg. Ezt is úgy olvassa a nick, mint az LPT-t?

Szerintem nem (de majd Zozo vagy István kijavít), viszont a Z80 csak a NICK ciklushatáraira időzítve tudja írni nem csak a videó memóriát, hanem a NICK regisztereit is.

A NICK portok hozzáférésének az időzítése csak karakteres felbontást tesz lehetővé soron belül. Valódi gépen egyébként a BIAS vagy keret új értéke nem pontosan karakter határon lesz érvényes, hanem néhány pixel eltolással (talán 1/4 karakter), de a pozíció ott is csak karakteres lépésekben változhat.

Az jó is lenne, ha negyed karakter eltolással lehetne érvényesíteni a kezdőpozíciókat (a z80 utasításhosszakból gondoltam, hogy negyed karakteres pozícionálás lehetne), utána már a 4 karakter hosszú bias jó is lenne (OUTI), mindig csak a kezdő sort kellene eltolnom negyed pixellel. Mivel lusta vagyok összerakni a gépet, ezt most akkor abba is hagyom.

Jaa, értem, köfi.
Erre a demóra gondoltam, amikor olvastam a postod, még arra is emlékeztem, hogy a Nick portokat használja időzítésre, arra nem, hogy hogyan.

Annak a megoldásnak egyébként lehetne hasznát venni, ha a BIAS vízszintes pozíciója fix lenne, és helyette a pixel adat mozogna nagy felbontással?

Úgy gondoltad, hogy soronként lehet különböző biast beállítani, és úgy a scroll?

Sor közben is változhatna, de ha állóképhez kellene az effektus, akkor nem lényeges. Ez egyébként valamilyen új átirat lesz, például ez a játék?

Sor közben is változhatna, de ha állóképhez kellene az effektus, akkor nem lényeges. Ez egyébként valamilyen új átirat lesz, például ez a játék?

Ön megnyerte az 1ft-os kérdést
Annak álltam neki, eredetileg a bias-szal szerettem volna a hátteret megoldani, de koncepciót váltottam, és a bias adja a majd a játék színeit
Gondolkoztam még az attributum módban is, de ott a labda lenne rossz a háttér miatt, és figurákat tartalmazó négyzetek se lennének az igaziak.
Viszont a sor közben állított biasnál elromlana a pixel színe finom scrollozásnál, nem?

Lehetne a játéknak külön téma. EP-n is 4K-s lesz (ha lehetséges), vagy továbbfejlesztett változat készül, például új zenékkel?

Ha jól látom, csak a négyzetek elfogyasztanak 15 színt ("alap" színek - R, G, B, C, M, Y - és a szürke normál és fényes változata, és fekete). Tehát csak egy szabad szín marad, talán még az sem ha a BIAS színek közül az egyik nem hasznos. Eredetileg villog a labda (az aktuális szín fényes és a normál és a fényes közötti árnyalatát váltogatja), de ezt nem biztos, hogy fontos lenne pontosan átírni. A hátteret valószínűleg nem lehetne minőségromlás nélkül konvertálni, és a program a színeket véletlenszerűen választja. Talán lehetne egyszerű ditherelt színátmeneteket használni.

Egyelőre úgy tervezem, hogy megpróbálom a 4K-s útvonalat. A négyzeteknél azt tervezem, amit a karaktereknél már végrehajtottam, hogy csak a 7 Bias árnyalat lesz, csak itt a világosabbik oldal 3fh lesz, míg a karaktereknél a sötétebbik szín a 38h-s szürke, nem lesz olyan szép, de egész jól néz ki,  a paletta a következőképp fog kinézni:
0 fekete, vagy a legsötétebb színek, 0-6 színek lesznek a háttér színei, 7. szín a kis szürke négyzet világosabbik szürkéje, 8. a kis szürke négyzet sötétebbik szürkéje, 9-14 négyzet színek, 15 a négyzetekben használt világos színek.
A labdaa vagy fehér lesz folyamatosan, vagy az aktív négyzet színét fogja megkapni, viszont a kijelzőben az életek színe a az aktív négyzet színét kapja meg.
A Ditherelelt színátmenetet néztem, az nem tetszett annyira, igaz még a BIAS-os megoldáshoz, és elég nagyok voltak a különbségek a színek között, egyelőre próbálkozok a 0-6 szín használatával.