legközelebb ne 2x írjátok át ugyanazt a játékot, hanem inkább két játékot írjatok át

Ez így alakult ,sztem ez sem baj, és még lesz ez továbbvariálva is

akkor egyik verzió legyen telerakva ep-s dolgokkal, mindenféle effektekkel, ötletek:
-golyó "trail"-t húz maga után vagy ilyesmi effektet
-forgó labda
-az egész pálya mintha egy csőre lenne ráfeszítve és forog alattunk (lpt trükk)
-erőteljes raszter színezés
-függőleges hullámzás lpt effekt (ez mondjuk nehezítene a játékon)
-az egész lores módban legyen és scrollos
-digi hangok
-háttér fotók

Sikerült még faragni a program méretén (-26 byte), a fallal való ütközést a következő verzióban nem külön kezeli, hanem a fal bonthatatlan téglaként az aktuális pálya része. Így egyszerűsödött a kód. A felszabadult hely elég lesz a megmaradt pontszám hibák javítására, és talán még "game over" hangokat is lehet beépíteni.

-golyó "trail"-t húz maga után vagy ilyesmi effektet
-forgó labda
-az egész pálya mintha egy csőre lenne ráfeszítve és forog alattunk (lpt trükk)
-erőteljes raszter színezés
-függőleges hullámzás lpt effekt (ez mondjuk nehezítene a játékon)
-az egész lores módban legyen és scrollos

Nem tudom, a sok effektus és szín valóban jó ötlet-e. Zavaró lehet, ha a sok "vizuális zaj" miatt már nehéz követni a labda mozgását, nálam például javítja az Enterball játszhatóságát az egyszerű (nem mozgó, raszterezett, stb.) piros háttér és fehér labda.

m6-ból nekem a legjobb a 8 verzióból 4020 byte volt , m5-tel 3901 byte, mi alapján határozod meg a hosszakat, és a távolságot?

Az m5 az Zlib formátum, azaz gyakorlatilag Zip, ami itt nem lenne hasznos. m6-ból a legegyszerűbb mindent kipróbálni, amihez már van kicsomagoló rutin, vagy könnyen lehetne készíteni. Az optimális kódolás kereséséhez használható a "-raw -m2 -1" formátum (azért -1, hogy ne darabolja az adatot több kisebb blokkra), itt kiolvasható a fejlécből:

epcompress -raw -m2 -1 quad.com quad.m2

hexdump -C < quad.m2 | head -n 2

00000000  c6 0c b3 e0 01 12 24 71  23 32 34 56 67 81 22 22  |......$q#24Vg.""|
00000010  34 43 55 78 9a c0 00 05  16 18 97 f0 04 31 50 01  |4CUx.........1P.|

Ehhez az -m6:fg0l,00112247,1233,23456678,12222344355789ac vagy -m6:f90l,00112247,1233,23456678,12222344355789ac lenne hasonló, a két formátum eltérő módon kezeli a tömöríthetetlen byte-okat. Az utolsó táblázat nem csak 16 méretű lehet, a negyedik byte (itt E0h) jelzi a méretét: b4,b5 = 00b: 4, 01b: 8, 10b: 16, 11b: 32.

Használható az Exomizer nevű program is, ami egyébként is hasznos lehet, van hozzá kb. 170 byte méretű Z80 rutin, ami még kisebb is lehet -c módban. Példa:

exomizer.exe raw -b -c -o quad.exo quad.com

...
 Encoding: 0001022351620100,1233,2223334565667789,12222233555888AC
 Length of crunched data: 3983 bytes.
 Literal sequences are not used and the safety offset is 2.

Ennek az -m6:b90l,0001022351620100,1233,2223334565667789,12222233555888AC felel meg. De ilyen kódolást már nem lehet egyszerű néhány soros Z80 rutinnal olvasni, annak a kereséséhez viszont hasznos lehet, hogy a gyakran használt m6 változatok közül melyik a leghasonlóbb. Ilyen hosszúságokat egyszerűen lehet dekódolni:

0123456789abcdef (ugyanaz, mint az alapértelmezett "g")
0011223344556677
123456789abcdef
0000000000000000
111111111111111111111
stb.

A távolság táblázatoknál érdemes tesztelni, hogy tömörítettek legyenek-e az 1 byte-os "sorozatok", ezek tilthatók a kódolásukat (a fenti példában 1233) üresen hagya. Tilthatók a 2 byte-osak is, ez azonban általában rosszabb. Néhány példa, de ennél több lehetőség van:

,12345678,0123456789abcdef (alapértelmezett m3-hoz hasonló formátum)
,0123456789abcdef,0123456789abcdef
,01234567,01234567
0123,01234567,0123456789abcdef
0123,01234567,0123456788888888 (én most ezt használom a Quadrillion-ban)
,12345678,12345678
,23456789,23456789
23,23456789,23456789
,3456789a,3456789a
34,3456789a,3456789a

geco-nan írtam az extrásítást. ha jól értem neki isvan egy verizója. egyik lehetne extrás

Az m5 az Zlib formátum, azaz gyakorlatilag Zip, ami itt nem lenne hasznos. m6-ból a legegyszerűbb mindent kipróbálni, amihez már van kicsomagoló rutin, vagy könnyen lehetne készíteni. Az optimális kódolás kereséséhez használható a "-raw -m2 -1" formátum (azért -1, hogy ne darabolja az adatot több kisebb blokkra), itt kiolvasható a fejlécből:

epcompress -raw -m2 -1 quad.com quad.m2

hexdump -C < quad.m2 | head -n 2

00000000  c6 0c b3 e0 01 12 24 71  23 32 34 56 67 81 22 22  |......$q#24Vg.""|
00000010  34 43 55 78 9a c0 00 05  16 18 97 f0 04 31 50 01  |4CUx.........1P.|

Ehhez az -m6:fg0l,00112247,1233,23456678,12222344355789ac vagy -m6:f90l,00112247,1233,23456678,12222344355789ac lenne hasonló, a két formátum eltérő módon kezeli a tömöríthetetlen byte-okat. Az utolsó táblázat nem csak 16 méretű lehet, a negyedik byte (itt E0h) jelzi a méretét: b4,b5 = 00b: 4, 01b: 8, 10b: 16, 11b: 32.

Az első négy paraméterrel játszottam én is, a tömörítetlen bájtok eltárolsánál eddig mindig az egyik jött ki kisebbre, már nem emlékszem ,hogy a 9 biten tárolt, vagy a csomagban tárolt. úgy érzem talán értem a hosszúság, és távolság leírását, de mi alapján adod meg a számkombinációkat? Hogy döntöd el, hogy milyen hossz és távolság értékeket hagysz ki, és miket duplázol?

de mi alapján adod meg a számkombinációkat? Hogy döntöd el, hogy milyen hossz és távolság értékeket hagysz ki, és miket duplázol?

Az nem érthető, hogy mit jelentenek, vagy hogy hogyan lehet egy adott definíciót dekódolni Z80 rutinnal, vagy hogy hogyan lehet jó paramétereket találni? Elvileg a gyakrabban előforduló értékeket kell kevesebb biten ábrázolni, a gyakorlatban egyszerűen próbálgatással keresem, melyik jobb, figyelembe véve azt is, hogy ne legyen túl bonyolult dekódolni (ezért lesznek általában egyszerű növekvő számsorok, például 23456789). Az m2 és Exomizer példáknál a programok generálták, és ezeknél tartalmazza a kimeneti file is.

első menetre a 13. pályáig jutottam, azt meg gyorsan elnyomtam, mert idegbe kerültem

Igen, ott a 13. környékén van egy brutális pálya, idegrendszerre ártalmas. Érdekes lehet, amikor sörrel ellensúlyozza ezt valaki egy ilyen játéknál, nem tudom, milyen a hatása, így is ideges lesz-e az ember, vagy nem annyira, vagy még esetleg az esélye is nagyobb, hogy kárt tesz a gépben. István elhamarkodottan ideadta nekünk a próbaverziókat, és nem is írta, hogy nem vállal felelősséget az idegesítő pályák miatti esetleges különféle dolgokért.
Még szerencse, hogy nem autóversenyt írtok át, mert vezetés közben nem lehet sört inni.

>07B1  C7 07

Ez lesz a kedvenc hexadecimális számsorom!