Talált valaki valami javítani valót a programban? Lehet ez a végleges verzió?

Azon gondolkozom, be lehetne-e mégis valahogy gyömöszölni a pályákat a játékba, hogy ne legyen utántöltős. A 8 pálya összesen 28061 bájt. Maga a basic játék 21929 bájt. A pályák méretét mindenképpen megdobná még, hogy programsorokat kell nekik létrehozni (sorszám és DATA utasítás). A basic programba valószínű beleférne még minden, de a Zzzip nem enné meg azt a sok sort.
Aki ért hozzá: a rendelkezésre álló tömörítési módszerekkel kb. mekkorára lehetne a pályákat betömöríteni? Ahogy emlékszem, a pályákon csak kisbetűk (átdefiniált karakterek), szóközök és % jel fordul elő jelenleg, más karakter nem (kisbetűkből sem az összes). A pályák elején pályainformációk vannak (pálya mérete, színek, pálya neve, stb.). Esetleg CODE és HEX utasításokkal be lehetne írni a programba a kitömörítő eljárást, ami a DATA sorokból kitömöríti a pályákat. Ehhez persze a DATA sorok mögé be is kéne tömöríteni őket valahogy. Például a pályaszerkesztőbe kerülhetne egy opció, hogy tömörítve mentse a pályát basic programként data sorokkal együtt.
A Zzzip max. kb. 30-33 KB-os programot eszik meg, ez alatt kellene maradnunk. Megoldható lehet? PC-s .zip fájlba tömörítve a pályák elég jól összemennek, kb. 80%-kal, de nyilván az EP-s tömörítés kicsit más.

Ugye jól gondolom, hogy most is DATA sorokban van a programban a pálya és azt PRINT-eled ki a videólapokra, amiket aztán ide-oda görgetsz? Akkor az a feladat, hogy tömörebben kell az adatokat a DATA sorokban leírni. Ezt korábban már pedzegettük neked, azt hiszem Povival. Kellene tényleges adat arról, hogy mennyiféle karakterből állítod össze a pályákat. Azután lehetne ötletelni meg számolgatni, hogy mit lehet kezdeni vele hogy beleférjünk a memória keretbe.

Most még nem. Fájlból tölti.

A progi mikor beolvassa a pályát rögtön ki is írja.
Én is azon gondolkoztam, hogy több DATA sort össze vonnánk.
És a STRING-eket össze fűznénk.
1. A BASIC sor paramétere nem lehet több 255 bájtnál.
2. nem tudom, hogy viselkedne a
.. DATA "asferferfer"&CHR$(10)&CHR$(13)&"aaaaaadhghjgad"&CHR$(10)&CHR$(13)&"aaaaaadhghjgad" .......
Így még kevesebb lenn a tárolás.

igen, pl megnezni, hogy pl ha egy szamhoz 2x2-es blokkokat rendelnel, befer-e 0-255 variacioba, ha igen, akkor ezzel majdnem a negyedere lehetne csokkenteni a meretet, de lehetne maskepp is nezni, pl, ha van sok ismetlodes, akkor az ismetlodeseknek egy speci, eddig nem szereplo szamot adni, majd letarolni az ismetlodesek szamat, majd annak az erteket, lehet bonyolultabban is, megnezni milyen patternekbol van sok, azokat kigyujteni, mindegyikhez egy eddig nem hasznalt szamot rendelni, es ezek alapjan beilleszteni a palyaba, es meg jopar modot meg lehet nezni.

Igen és a dekódoló rész mennyit emésztene fel ?

Kellene tényleges adat arról, hogy mennyiféle karakterből állítod össze a pályákat.

A szóköz, "%" és a kisbetűk szerepelnek a pályákon, kivéve az "m", "n", "o" és "y" kisbetűket. Pár karakter egyes pályákon nem fordul elő, ami más pályákon igen (pl. a "g" és "l" pöttyöket, csillagokat akar ábrázolni, azok csak kb. a pályák felén vannak. Ezen kívül "%" és "p" betűből kifejezetten kevés van a pályákon, "w" és "e" van a legtöbb általában, ha ez számít valamit).
Viszont ez csak a jelenlegi pályákra vonatkozik. Lehetne tervezni olyan pályákat is, ahol ezeknél több karakter is van, ennek a lehetőségét is meg kéne hagyni, így valószínűleg külön kellene majd tömörítő az esetleges későbbi pályákhoz.

Data sorokból most nem olvas, fájlból tölti a pályát. Így néz ki az egyik pálya eleje a fájlban, ilyet ment a pályaszerkesztő:

1 ! szint száma
 44 ! pálya színe, a köv. 3 is
 29
 135
 59
"UTTORO ARUHAZ FULL"
 131 !pálya magassága karakterekben - ennyi sort olvasson be FOR ciklussal
 47 ! kincsek száma a pályán ("x" karakterek)
 1954 ! szörnyek startpozíciói, a köv. 3 is
 393
 1332
 1083
"aeeeeeeeeeeeeeeeeeer"
"f       x          f"
"f aeeeeeeh ieeeeec u"
"f f              f f"
"f f ah ieeeeh ic f u"
"f f k          k f f"
"f f   arc arrc   f u"
"f f j udf ffbt j f f"
"f f f k f btxf f f u"
"f k f   fp f k f k f"
"f   f j uc f   f  %u"
"f j f fxff f j f j f"
"f f k urvt fat k f u"
"f f   bssd bsd   f f"
"f f j          j f u"
"f f bh ieeeeh id f f"
"f f              f u"
"f beeeeeh ieeeeeed u"
"f                  f       x   % f"
"f aeeeeeeeeeeeeeec ueeeeeeeeeeeeed"
....
A legelején a számokhoz írtam most kommenteket.
Csak azért van idézőjelben minden sor, hogy ha esetleg egy az egyben data sorok mögé akarnánk tenni, akkor így mehetne, és még volt valami kisebb gond beolvasásnál, ha nem volt idézőjel, azt hiszem. Szóval az idézőjelek elhagyhatók, és a sortörések is. A sortörések is csak az áttekinthetőség miatt vannak ott, valójában folyamatosan mennek az adatok, nem is kellene sortörés, ha folyamatosan csak mindig növelnénk 1-gyel a cím értékét, ahova a következő karakter kerül.
Az első 20 sor rövidebb, mint a következők, mert mellettük a kijelző van.

Jut eszembe, mégsem mehetnének sortörés nélkül folyamatosan a pályaadatok, mert ahol nem ér a pálya a jobb széléig a videolapnak, ott a szóközöket levágja a szerkesztő mentésnél. Így ha folyamatosan menne a pálya kirajzolása, elcsúszna. Tömörítés előtt, gondolom, mindegyik sort fel kell hozni egyforma hosszúra úgy, hogy a végét feltöltjük szóközökkel, amíg 34 karakter hosszú nem lesz egy sor. (Legegyszerűbb a szerkesztővel betölteni újra a pályát és elmenteni úgy, hogy nem vágja le a szóközöket, ezt majd megcsinálom, ha kell.)

De ha megoldható, az is jó lenne, ha a program induláskor az összes pályát betölti valahova a memóriába, és játék közben onnan rajzolja ki, és tömöríteni sem kell. Ehhez ramdisk lenne a legjobb, amit folyamatosan olvasgat a program, de e Zzzip nem engedi, hogy ilyen már legyen előre létrehozva. Magnós rendszerhez is van ramdisk bővítés, de az sem jó, mert előtte be kell tölteni, és a Zzzip nem szereti a rezidens programokat. Esetleg még maga a játék hozna létre gépi kód segítségével saját ramdisket, és azt használhatná, ha az megoldható. A kérdés, hogy a program le tudhat-e foglalni kb. 30KB területet a memóriából a pályáknak. Zozónak volt ilyen CALL USR-es, SPOKE-olós memórialefoglalós módszere, de nem tudom, ennyit is le tudna-e foglalni. Ha kell, előkeresem, az a Dot collector pályaszerkesztőjében foglalt le magának kb. 8KB memóriát. Nem tudom már, zzzippelt programban is működik-e, remélem, igen.

Érdemes lenne olyat is megfontolni, hogy nem magát a pályát tárolnád karakterenként, hanem az "objektumokat". Nekem a Banana 2-ben így vannak megoldva a pályák. Az alább mellékelt pályát valami hasonló módon írnám le: alapből üres az egész képernyő, szóközökből áll, amit aztán feltöltenék pályaelemekkel. Lenne egy objektum azonosító (ami akár az irányt is megjelöli, hogy kevesebb adatot kelljen tárolni, pl. a nagybetű függőleges irányt jelent), egy pozíció (ekkora képernyő két bájtot igényel, vagy X,Y koordinátát) és egy darabszám. Mondjuk a felső sort valami hasonló módon írnám le: "a",1,1,1, "e",2,1,18, "r",20,1,1. Lehetne tömörebben is tárolni, pl. a numerikus értékeket is karakteresen, de mivel 10 számjegynél többre van szükség, ezért inkább betűkkel. Ha "a"=0, "b"=1, stb., akkor így nézne ki az első sor: "abbbecbsrubb". A bal oldali függőleges, fontjelekből álló sort is le lehetne így írni. Mivel először "f"-nek néztem, a nagy "F" jelentene függőleges "f"-et: "Fbct". (Azért "f", mert nincs kis és nagy fontjel. ) A jobb oldali, függőleges, ismétlődő "fu"-t is lehetne rövidíteni. "FU"-ként írnám le, így: "FUuci". Ebből az "FU" az, ami ismétlődik (amíg nagybetű, addig nem pozíció, hanem kiírandó adat), utána az "u" jelenti a 20. oszlopot, a "c" a 2. sort, az "i" pedig azt, hogy 8x ismétlődik. Tehát az eddigi objektumok így néznének ki egy data sorban:

100 DATA "abbbecbsrubbFbctFUuci"

Marha nehéz később átlátni, de ezzel az egy sorral kb. a képernyő keretének három oldala le van írva 21 karakterből.

Ami még szempont, hogy viszonylag gyorsan rajzolja ki a pályát a játék. Most tömörítés nélkül is kicsit lassú a kirajzolás.
Előfordulnak négyszög alakú tömör objektumok is a pályán. Ezeket jól lehetne tömöríteni, ha csak két átellenes sarkukat adjuk meg, és valahogy jelezzük, hogy abból képezzen négyszöget és rakja tele karakterekkel.
A kifejezetten ritkán, elszórtan előforduló objektumok koordinátáit külön is lehetne tárolni. Ez még elmenne, hogy végignézi a pályát, és letörli, miután letárolta őket, így már nem zavarnak. Tényleg, ez a letárolás után letörlés elég jó módszer arra, amin az előbb problémáztam, hiszen a pálya maga amúgy is el lenne mentve már előtte. Csak kérdés, meddig pásztázza a képernyőt letárolható objektumok után, amíg teljesen üres nem lesz. Na, jól elgondolkozom itt "hangosan" a módszerekről.

Ezt nem teljesen értem, hiszen eleve "tömörítve", vagyis inkább kódolva lennének a DATA sorokban a pályaelemek. Betömöríteni nem kéne, csak kiolvasni a sorokat és kitenni a képernyőre. Az "abbbecbsrubbFbctFUuci" sorban már van vízszintes és függőleges elem is, és lehetne még folytatni, férne bele.

Nem kéne betömöríteni? Akkor hogyan állítanánk elő a betömörített adatokat? Manuálisan? Az nagyon nagy meló lenne.
Eleve a tömörítő eljárás, tegyük fel, a bal felső sarokból indul, és vízszintesen nézi a pályát, mi van ott, és aszerint állítja elő a tömörített adatot. Ha a sor végére ér, a következő sor elején folytatja. Kb. ez lenne e RLE tömörítés. Ha jól értem, ezt azzal toldanád meg, hogy ne csak vízszintesen, hanem lefele is nézze, mi van az aktuális pozíció alatt, és ha ugyanaz a karakter jön sokáig, akkor arról is előállítson adatot.
Namármost, ha függőlegesen is nézed közben, és ha mondjuk ott egy függőleges fal, akkor vízszintesen tovább haladva, majd a következő sorban újra ahhoz a függőleges falhoz érve még egyszer megvizsgálná azt a falat is. Hogyan lehetne megoldani, hogy még egyszer ne vizsgálja meg és tárolja le? Erre írtam, hogy amit már megvizsgált, azt írja felül szóközzel, így többször nem botlik bele.