Welcome, Guest. Please login or register.


Author Topic: Fájltömörítés Enterprise-on (Read 205970 times)

Offline Povi

  • EP addict
  • *
  • Posts: 2287
  • Country: hu
    • http://povi.fw.hu
Re: Fájltömörítés Enterprise-on
« Reply #375 on: 2020.April.22. 18:29:12 »
Nem annyira ide tartozik, de a pályaadatokról jut eszembe, hogy a Squirm című Plus/4 játék pályáinak egy része ki van mentve txt formátumba, de már ez nagyobb, mint maga a program. Biztos tömörítik a pályákat benne valahogy. Gondolkoztam, basicben DATA sorokban tárolva nagyobb pályákat könnyen elfogy a hely. Nem tudom, basicben ilyenre lehet-e valami jobb, kisebb helyet igénylő megoldás.
mivel a pálya adatok esetében sok az ismétlődés, BASIC-ben is lehetne egy egyszerű RLE tömörítést használni:
pl.: nyers pálya adat: AAAABBBAAAACCAA (15 byte)
tömörítve: 4A3B4A2C2A (10 byte)
*** Speicherplatz zu klein

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14709
  • Country: hu
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #376 on: 2020.April.22. 21:36:40 »
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 :oops: )

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1286
  • Country: hu
  • Stray cat from Commodore alley
Re: Fájltömörítés Enterprise-on
« Reply #377 on: 2020.April.23. 09:03:08 »
mivel a pálya adatok esetében sok az ismétlődés, BASIC-ben is lehetne egy egyszerű RLE tömörítést használni:
pl.: nyers pálya adat: AAAABBBAAAACCAA (15 byte)
tömörítve: 4A3B4A2C2A (10 byte)
Viszont ha nem ilyen kedvező az adatok struktúrája, valamilyen bináris tömörítést ASCII kódolásban még mindig lehet csinálni. Ha például a 33-tól 96-ig kódú karaktereket vesszük, akkor egy jelben 6 db 1 bites (= kétféle elem), 3 db 2 bites (= négyféle elem) vagy 2 db 3 bites (= nyolcféle elem) adatot kódolhatunk egyszerűen.

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 9888
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: Fájltömörítés Enterprise-on
« Reply #378 on: 2020.April.23. 10:19:47 »
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.
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline Povi

  • EP addict
  • *
  • Posts: 2287
  • Country: hu
    • http://povi.fw.hu
Re: Fájltömörítés Enterprise-on
« Reply #379 on: 2020.April.23. 10:44:48 »
pl.: nyers pálya adat: AAAABBBAAAACCAA (15 byte)
tömörítve: 4A3B4A2C2A (10 byte)
ez csak egy nyers elméleti példa.
Ha pl. 8 különböző pályaelemed van, ami elfér 3 biten, akkor a byte-ban még kihasználatlanul maradt 5 bitet fölhasználhatod a darabszámra.
Példa:
A 8 pályaelem: 0..7 számokkal van reprezentálva.
A maradék felső 5 biten pedig a darabszámot ábrázolod, max 31 lehet így a darabszám.
Ha 5 darab 1-es pályaelem kell, akkor az ezt ábrázoló szám: 5 * 8 + 1
Ha 7 darab 2-es pályaelem: 7 * 8 + 2
satöbbi

a 0 elemszámmal meg jelezheted, hogy ez az utolsó byte, nem kell tovább olvasni a DATA sorokat

(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 :-) )
*** Speicherplatz zu klein

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1286
  • Country: hu
  • Stray cat from Commodore alley
Re: Fájltömörítés Enterprise-on
« Reply #380 on: 2020.April.23. 10:55:38 »
(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.

Offline geco

  • EP addict
  • *
  • Posts: 7069
  • Country: hu
    • Támogató Támogató
Re: Fájltömörítés Enterprise-on
« Reply #381 on: 2020.April.23. 11:26:50 »
(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 :-) )
Tuti nem :)
Viszont el lehet tárolni egy tömbben, aminek elemei stringek :D
Igen a DATA-val az a baj, ha jól emlékszem ,akkor szépen eltárolja a számokat, vesszőstől a memóriában, tehát vagy a stringes megoldást érdemes használni, vagy amit ergoGnomik javasolt, memóriába tölteni, és onnan olvasgatni, csak ugye ez is macerás basicből.

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 9888
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: Fájltömörítés Enterprise-on
« Reply #382 on: 2020.April.23. 17:17:56 »
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.
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1286
  • Country: hu
  • Stray cat from Commodore alley
Re: Fájltömörítés Enterprise-on
« Reply #383 on: 2020.April.24. 07:29:29 »

Törölve: A hozzászólás a téma megvitatását és előre vitelét nem szolgálta jelentős értékkel, viszont a megszólított a tartalmát sérelmezte. Bocsánatot kérek a rombolásért.
« Last Edit: 2020.April.27. 07:42:31 by ergoGnomik »

Offline geco

  • EP addict
  • *
  • Posts: 7069
  • Country: hu
    • Támogató Támogató
Re: Fájltömörítés Enterprise-on
« Reply #384 on: 2020.April.25. 10:14:14 »
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 :-D
« Last Edit: 2020.April.25. 10:18:14 by geco »

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14709
  • Country: hu
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #385 on: 2020.April.27. 09:57:12 »
Ilyen célra nem lenne használható a korábban készített ROM: eszközhöz (romfsdev.asm) hasonló megoldás?
Igen, jó lehetne annak egy módosulata is. Esetleg az is segíthet ez esetben, hogy nem ROM-ból futna a kicsomagoló kód, hanem a nullás lapon, így van lehetőség eltárolni változókat, vagy esetleg önmódosító kódot használni.

Offline Povi

  • EP addict
  • *
  • Posts: 2287
  • Country: hu
    • http://povi.fw.hu
Re: Fájltömörítés Enterprise-on
« Reply #386 on: 2020.April.27. 12:11:33 »
Tuti nem :)

Nade CODE paranccsal szépen be lehet rakni! :-)

Példa Szipucsunak:

Code: [Select]
 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:
Code: [Select]
0x50 = 80 = 10 * 8 + 0
0x29 = 41 =  5 * 8 + 1
0x1a = 26 =  3 * 8 + 2
*** Speicherplatz zu klein

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Fájltömörítés Enterprise-on
« Reply #387 on: 2020.April.29. 11:05:11 »
az m2 tömörítésre miért írja azt a wikis leírás, hogy "elavult és általában nem ajánlott a használata"?

A 2.0.11.2 emulátor csomagban található epcompress már nem tartalmazza a régi formátumok többségét, csak az m3-at és az m2 lebutított (gyorsan tömörítő, de kevésbé hatékony) változatát. Az utóbbira a snapshotok és az ep128emu_roms.bin file miatt van szükség kompatibilitási célból. Mivel a nem m3 formátumokat eddig is többnyire csak én használtam, nem tartottam érdemesnek ezeket kiadott verzióba beépíteni. Új programnál pedig előnyösebb is lehet, ha tetszőlegesen módosított vagy új formátumok használhatók, mivel nem számít a kompatibilitás. A Bad Apple demóba is egyedi m4 változat került, amivel gyorsabb lehetett a lejátszás.

Ha valaki mégis használná a törölt formátumokat, akkor "git checkout 080cccdf30730447b95388802f86783e521e564a" paranccsal letölthető az ep128emu forráskód utolsó verziója, amelyben ezek még megtalálhatók voltak.
« Last Edit: 2020.April.29. 11:12:38 by IstvanV »

Offline Povi

  • EP addict
  • *
  • Posts: 2287
  • Country: hu
    • http://povi.fw.hu
Re: Fájltömörítés Enterprise-on
« Reply #388 on: 2020.April.29. 13:24:01 »
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?
*** Speicherplatz zu klein

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14709
  • Country: hu
    • http://enterprise.iko.hu/
Re: Fájltömörítés Enterprise-on
« Reply #389 on: 2020.April.29. 13:48:46 »
A ROMFS is úgy működik(működött), hogy végig próbálta az összes variációt, nem?