Bonyolultabb/bitenként olvasott formátum hatékonyabb lehetne.

Valamelyik ilyen módszernél meg lehetne oldani azt, hogy egy CALL legyen azon a ponton amikor elkészült egy bájt? Valami olyan fomában, hogy híváskor a cél cím helyett a rutin cím lenne átadva. (SD-nél két külön féle rutint kell hívni az első 48K és a lapozható 8x8K írásához.) Illetve, hogy egy szegmenslista alapján korlátlan memória méretből folytatólagosan dolgozzon? (Azaz amikor elfogy egy szegmensnyi tömörített adat, akkor lapozza magának a következőt. Itt gondolom jelentősen bonyolítja a dolgot, hogy bitenkénti feldolgozásnál szegmenshatáron átnyúlás is lehet )

Viszont ha nem ilyen kedvező az adatok struktúrája

Egyelőre olyanra gondoltam, mint az Entersnake, meg az ilyen pacman jellegű játékok, ahol leginkább csak fal van és szóköz a pályán. Erre Povi módszere jónak tűnik. Még a sorok végén gondolkozom, hogy ha sok fallal végződik egy sor, és a következő sor elején is fal van, akkor azt is egyben lenne jobb letárolni, de ezen már talán úgyse lehet jelentősen sokat spórolni.
A másik, hogy ha függőlegesen jóval nagyobb a pálya, mint vízszintesen (ilyen van/lesz majd az Entersnake 2-ben), akkor függőlegesen lenne érdemesebb a pályaadatokat tömöríteni, csak ennek a kirajzolása is elméletileg tovább tart, vagy nem, mert ez is print meg az is.
A tömörített pályájú játékokhoz kellene majd külön pályaszerkesztő, ami kimenti a pályát tömörítve data sorokba, amit össze lehet merge-lni a játékkal, illetve merge helyett ma már txt fájlban copypaste a király. Legutóbb a TVC-s Xorgame 2-t is végig txt fájlban szerkesztettem, semmit nem módosítottam TVC basicben.
Hogy egy jelben hány darab hány bites karakter van, az nekem kínai, de majd ha úgy alakul, ilyen tömörítást is megpróbálunk bedobni.

(mondjuk így már szerintem pont nem DATA soronként lenne érdemes tárolni, nem hiszem, hogy a DATA 65,66,67 sor az nyers "ABC"-ként fog eltárolódni a RAM-ban )

Csak hát szipucsunak pont az volt a szíve vágya, hogy BASIC-ben, DATA sorokban lásson megoldást adattömörítésre. Amire az első megoldásod szerintem kiváló volt, míg ez utóbbi azért küzdhet problémákkal. Ha teljesen bináris adatokat akarnánk használni, azt szerintem jobb lenne külön fájlból betölteni és direkt memória olvasásokkal kezelni a BASIC programban.

vagy a stringes megoldást érdemes használni

A stringes megoldás is jó. A pályaszerkesztő mindegy, mibe menti a pályát. De DATA után is lehet stringként tárolni a pályaelemeket, vessző nélkül. De még vesszőkkel is nagyságrendekkel kisebb helyet foglalna, mint tömörítés nélkül, szerintem.

ergoGnomik egy egyszerű tömörítési lehetőséget ajánlott, arra az esetre, ha a pályaadatok nem ismétlődnek kedvezően a Povi által ajánlotthoz. A lényege az, ha kétfajta pályaelem van, fal meg háttér, akkor egy bajton 8 elemet tudsz eltarolni, minden bit egy elem,  mondjuk a -fal az 1-es, a háttér a 0-as, ugyanez ha négyfajta pályaelemmel dolgozol, akkor 4 elemet nyomhatsz egy bajtba ügyi mert egy bájt az 8 bit (pl 11 01 00 11 egy 3-as, egy 2-es, egy 0-as, és egy 3-as pályaelemet takarna) , ha 8 -fajta palyaelemed  van, abból csak kettőt tudnál eltarolni ( pl xx 111 100 egy 7-es, és egy 4-es elem egy bájtban,  a két bit kiesik, mert annak a lehetősége csak 4), és ugyanígy ha 16 -fajta elemed van, akkor is kettőt ( pl 0110 0000 egy 6-os és egy 0-as elem) . annyi hogy ergoGnomik a felső két bitet lehagyta a játékból, gondolom a 33-96-ig karakterkészlet miatt, de azokat is be lehet vonni, mert elég szimplán hozzárendelni a karakterkódokat a lekódolt palyaelemszamhoz, legegyszerubb megoldás, ha a palyaelemek a karakter range-hez vannak igazítva ( pl a 0. elem a 33. karakter, az 1. A 34. és így tovább) akkor csak 33-at kell hozzáadni a kódolt pelyhesem számhoz, és ki is kitehető a képernyőre, annyi hogy elotte a palyaelemeket ki kell nyerni a bájából.
ha nem akar az ember baszakodni bináris műveletekkel Basicben, megoldható digitálissal is a palyaelem kinyerése. pl ha négyfajta palyaelemunk volt, akkor az elsőt a byte 64 -gyel való egész része adja meg, a másodikat a byte 16 -tal való osztásának egész részének 4-gyel való osztásának maradéka adja meg, a 3-dikat a byte 16-tal való osztásának maradékának 4-gyel való osztásának egész része adja meg, a 4-diket pedig a byte néggyel való osztásának maradéka adja meg

Tuti nem

Nade CODE paranccsal szépen be lehet rakni!

Példa Szipucsunak:

 100 ALLOCATE 100
  110 CODE ADAT=HEX$("50,29,1a,00")
  120 LET CIM=ADAT
  130 DO
  140   LET C=PEEK(CIM)
  150   LET CIM=CIM+1
  160   IF NOT C THEN EXIT DO
  170   FOR I=1 TO INT(C/8)
  180     PRINT CHR$((C BAND 7)+65);
  190   NEXT I
  200 LOOP

ez AAAAAAAAAABBBBBCCC -t fog kiírni (10 db A, 5 db B, 3 db C)

magyarázat:
0x50 = 80 = 10 * 8 + 0
0x29 = 41 =  5 * 8 + 1
0x1a = 26 =  3 * 8 + 2


Mivel a nem m3 formátumokat eddig is többnyire csak én használtam, nem tartottam érdemesnek ezeket kiadott verzióba beépíteni.

Én használtam őket
nade: most m2 formátumot használok, azt látom, hogy kb. 10%-kal nagyobb lesz a méret, viszont cserébe kisebb a kitömörítő, és gyorsabb is?