4179 byte, nem tudom, érdemes-e próbálkozni azzal, hogy ez is 4K-s legyen:

Hát, sztem nem érdemes jópár órát eltölteni vele, hacsak nem a pályakihagyás lenne a megoldás, szerintem a legkevésbé tömöríthető 1-2 pálya meg is oldaná

A tárolt pontszám a kijelzettnek most csak a tizede, így 655350 a maximum, de a növekedése tízszer gyorsabb. Javítottam a 4-es pályán a hibát, a pálya neveket pedig töröltem, mivel C64-en nincsenek ilyenek.

Engem nem zavar a sokkal rövidebb pörgés. Megnéztem az összes pályát, hibát nem találtam, vagyis egyet, vérgecik a pályák

A sztereó effektusok és a 6 MHz kompatibilis hang törlésével elférne. Különösen az előbbi fogyaszt sok helyet.

Hát akkor hajrá ,szerintem még egy versenyre is benevezhetnél vele, vagy lehet az is, hogy lesz belőle egy 4k-s nem sztereó, meg egy nem 4k-s sztereó.
Az extrásított verzióval foglalkozom, haladgatok, F1-re lehet választani melyik képernyő módot szeretné az ember, még ezen is akarok kicsit módosítani, 3 féle háttér generálódik benne, és a lemez 4 fázisban mozog.

Az extrásított verzióval foglalkozom, haladgatok, F1-re lehet választani melyik képernyő módot szeretné az ember, még ezen is akarok kicsit módosítani, 3 féle háttér generálódik benne, és a lemez 4 fázisban mozog.

A lemez mozgatás kissé bugos akkor, ha egyszerre több mozdul el. Még egy lehetséges bug, hogy a széles képernyő módban a jobb alsó sarokban van egy fényes pixel. A ditherelt háttereket előre is lehetne renderelni és tömörített formátumban tárolni, vagy karakterkészletként (valószínűleg az egyszerű minta miatt nem sok karaktert igényelnének, elvileg 32 + 16 elég lenne mindkét dither mintához), így gyorsabb lenne a hátterek közötti váltás. Az előbbi esetben hasznos lehet, ha a kicsomagoló rutin a program indításakor nem íródik felül, így játék közben is újra használható. Esetleg még a nem ditherelt módokban a szöveg háttere maradhatna fekete, bár így kevesebb szín használható, talán jobban néz ki.

Ez csak teszt célra, a háttér mintát véletlenszerűen választja a menü megjelenítésekor:

Teljesen jó Beépítem a sűrűbb sávos verziót is

Ma eddig jutottam, választható karakterkészletek (f2,f3,f4), de csak keskeny képernyő módban, a szélesen nem igazán jól néznek ki az átalakítottak, lehet megpróbálok valamit, vagy minden készletre testreszabni az átalakítót, vagy tömörítve letárolni, még nem tudom.

A Commodore font elfogadhatóan konvertálható kis felbontásúra, a Plus/4-es verzió is ezt a megoldást használja, bár néhány karaktert külön esetként kezel. Erre egy példa:
[ Guests cannot view attachments ]

Hány darabnál?

Ha jól emlékszem, a 13-as pályán volt hiba, ott sok lemez van, könnyen lehet egyszerre többet is eltolni különböző irányokba.

jó ötlet, gondolom a teszt verzióban ez lett megvalósítva

A "karakteres" megoldást tartalmazza, illetve a fenti változatban a fontdata.bin teljes konvertált karakterkészlet.

Ez a tervem, bár még nem tudom hogy m6 lesz-e vagy m0,  a sebesség miatt gondolom mindenképp jó lenne az m6.nál maradni, még a méret miatt is, kb 200 byte-tal nagyobb az m6

Lehetne m4 is, a fenti csomagban is az van teszt céllal, bár ott még nagyobb méretű mint a 4K-s "kész" verzióban található m6-os megoldás. Viszont a rutin használható marad RST 18h hívással. A C64-esben azonban már kisebb. m0 elsősorban konvertált képeknél és hangmintáknál előnyös. Mindenesetre ezzel akkor érdemes igazán foglalkozni, amikor már többé-kevésbé kész a program, addig változhat, hogy mi ad jobb eredményt.

Ha fontos a méret és a nagy felbontású font már egyébként is a program része, akkor azonban külön rutinnal is jobb a konvertálás.

Egyelőre még nem, de később tuti az lesz, szeretném, ha a kód rész kicsomagolva, tömörített adatokkal elférne 16 KB-ban.
Megfontolandó a 3 különböző knovertáló is akár.

A Commodore font elfogadhatóan konvertálható kis felbontásúra, a Plus/4-es verzió is ezt a megoldást használja, bár néhány karaktert külön esetként kezel. Erre egy példa:

Jaja, láttam, hogy a Plus4-es karakterkészletet módosítja, az r-t, a 4-est, és még valamit patchelt, és jól működött , a Crillionétól tartottam, ezért is gondoltam a 3 külön kisfelbontású csomagra, ha másképp nem megy, de vágülis lehet vegyíteni is őket, ha a Crillion on the fly konvertálása nem ad eredményt, majd csekkolom a csatolmányt

Ha jól emlékszem, a 13-as pályán volt hiba, ott sok lemez van, könnyen lehet egyszerre többet is eltolni különböző irányokba.

6 bájton tárolom az egy négyzet paramétereit, kezdőpozíció, irány, fázis, és szín, ebből tárolok kettőt, vagy az lehet, hogy elszúrtam, és ez lesz a valószínűbb, mert mintha fixen csak az első pozícióba töltenék adatot, ha ezt javítom a fixen másodikra, akkor az meg is oldaná, mert a mozgató rész, bemásolja a 2. pozíció tartalmát, ha nem üres, az elsőbe ha az üres még a mozgatás(ok) végrehajtása előtt, vagy elszámoltam az egyszerre mozdítható diskek számát, és az lehet akár 3 is.

A "karakteres" megoldást tartalmazza, illetve a fenti változatban a fontdata.bin teljes konvertált karakterkészlet.

Szuper, holnap megnézem

Lehetne m4 is, a fenti csomagban is az van teszt céllal, bár ott még nagyobb méretű mint a 4K-s "kész" verzióban található m6-os megoldás. Viszont a rutin használható marad RST 18h hívással. A C64-esben azonban már kisebb. m0 elsősorban konvertált képeknél és hangmintáknál előnyös. Mindenesetre ezzel akkor érdemes igazán foglalkozni, amikor már többé-kevésbé kész a program, addig változhat, hogy mi ad jobb eredményt.

A fontok  miatt toltam egy csomagolási versenyt, az volt a tervem, hogy azokat már csomagolva teszem be, de letettem róla, még van hely   , és a végéig még változhat a helyzet. Nekem a legjobb eredményt az m5 adta, 8 bájttal követte az m0, az m6 az utsó előtti volt (igaz ezek különböző verzióit nem teszteltem)

Egyébként ha az a fontos, hogy a kicsomagolt méret 16K alatt maradjon, akkor érdemesebb lehetne az eredeti Plus/4-es RLE tömörített pálya formátumot használni. Én a 4K-s változatban egyszerű 1 tégla = 1 byte formátumban tároltam a pályákat, mivel a kész program méretén nem változtat jelentősen, és Szipucsu kezdetben érdeklődött a pálya szerkesztéssel kapcsolatban, tehát előnyösnek tűnt a könnyen szerkeszthető formátum.

A szövegeket is lehetne kisebb helyen tárolni, erre teszteltem is egy egyszerű megoldást (A0h feletti karakter 256 - N szóközt jelent és az alapértelmezett sárga szín visszaállítását), de nem lett kisebb a csomagolt méret, ezért elvetettem. Itt viszont hasznos lehetne. Egy másik ötlet az "include" funkció a szövegekben, egy speciális karakter és utána cím egy másik szöveg kiírását eredményezi, így nem lenne például a "G A M E  O V E R" több példányban tárolva.

-m6:fg1l,123456789abcde,23,23456789,456789ab

[ Guests cannot view attachments ]
[ Guests cannot view attachments ]
[ Guests cannot view attachments ]
[ Guests cannot view attachments ]

Futás közben is használható marad (CALL 0060h, a 0020h-00AFh területen találhatók kód részletek), nem fordított irányú. Ha ezek nem fontosak, akkor lehetne kisebb is.