1 bites grafika tomoritesi kiserletek vizualizalva...
HoH projekt kereteben, sajat tomorito algoritmusok keszultek. Kicsit bovebben arrol van szo, hogy rogeszmemme valt, hogy a leheto legkisebb file-meretre torekedjek. Mar-mar annyira, hogy komolyan gondolkodom C helyett inkabb 68k assembly-ben csinalom az egeszet. Mindenesetre a kicsomagolo kodot biztosan!
Szoval a tomorites otlete szinte magatol ertetodott, ugyanis a CW (CodeWarrior) a C forrasba agyazott bitmap adatokat enyhen tomoritve tarolja resource-kent a resource fork-ban. Mivel ez a tomorites eleg gyenge, gondoltam kezbe veszem a dolgot, es megnezem mit tudok kihozni belole. Megjegyeznem, hogy nem vagyok sem matematikus, sem tomorites-szakerto, szoval igencsak az elejen kezdtem. Eloszoris probaltam vadaszni meglevo tomorito algoritmus forraskodokat (sikertelenul - talaltam de...), majd olvastam kicsit a temaban, amiben a legfontosabb amit sikerult leszurnom, hogy hogyan tudok szamokat kevesebb biten tarolni. Most mielott ossze-vissza belekezdenek mindenfelebe, par szot arrol, mi is van a jobb oldalon.
A jobb oldalon 14 csoportban kis 1 bites "bitmap"-eket, a keszulo jatek keszulo grafikai elemeit lathatjuk (Az elso csoportban a c64 karatkerkeszlete a kivetel). Minden egyes csoport az eredetivel indul, majd mellette sorban lathatoak az ujabb es ujabb tomorito algoritmusok tomoritesei ($AA padding), es az utolso helyen osszehasonlitaskeppen a zip tomoritese. Mindezt ugye kepekben latjuk: az 1 bites grafika lenyege, hogy 1 byte-on 8 keppontot tarolunk, minden egyes bit 1 keppont. 1 byte 8 keppontja egymas mellett helyezkedik el. A memoriaban levo kep soronkent van tarolva, ezert a szelesseguk pixelben mindig 8 szorzata. Szoval a byte-okon pixeleket tarolunk, es ez tokeletesen latszik az eredeti grafikan, viszont a tomorites folyaman, a pixeleket szamkent kezeljuk, es matematikailag probaljuk meg ezeket a szamokat kevesebb byte-on tarolni ugy, hogy visszafejtheto legyen. Ennek az eredmenye, hogy a tomoritett adatban egyre kevesbe ertelmezheto az eredeti grafika, es annal inkabb dominalnak a szamok, ami random pixelhalmaznak tunik ranezesre. Es most arrol, hogyan is keszulnek.
Packer1
Ez az a tomorites, amit a CodeWarrior is csinal(t), es amit mar 13 evesen c64-en is sikerult megcsinalnom, igazan nem nagy kaland, viszont azert nem is rossz. A lenyege, hogy a memoriaban levo byte-ok sorozataban kiszuri az egymast koveto azonos byte-okat, es helyettesiti 3-byte-tal a jo esetben sokkal hosszabb sorozatot.
Tomorites: megkeresi a legritkabban elofordulo ertekeket a byte-ok sorozataban, optimalis esetben van 1 vagy tobb olyan ertek ami nem szerepel. Ez lesz a Control-byte. Kitomoritesnel amikor olvassa a tomoritett byte-sorozatot, ha a Control-byte tal talalkozik, az jelzi, hogy ismetles lesz.
Elonye, hogy mind a tomorites, mind a kitomorites nagyon gyors, a leheto leggyorsabb, gyorsabb mintha a memoriaban a kitomoritett kepet masolnank egyik helyrol a masikra. Hatranya, hogy reszletgazdag grafikaknal nem tul hatekony.
Packer3
Mint korabban irtam a kepek a memoriaban byte sorokbol alnak, igy egy 32x32 pixeles grafika 1. sora az elso negy byte-bol all ( 0 1 2 3 ), es ezt 31-szer koveti ujabb 4 byteüos sor ( 4 5 6 7 ... ). Ez a kismeretu grafikak eseteben, ha a byte-sorozatban egymast koveto ismetleseket akarok kiszurni, nem tul optimalis, ezert tomorites elott atrendezem a byte-okat (nem orulok ennek*) ugy, hogy az egymast koveto byte-ok, a kepen egymas ala essenek. Igy az elozo grafika elso soraban a kovetkezo byte-ok lesznek: 0 32 64 96, a kovetkezoben meg 1 33 65 97, es igy a 32. sorig.
* Nem orulok neki, mert a sorrend visszaallitasa kitomorites utan ujabb nyug, de szerencsere viszonylag gyorsan es keves extra memoria felhasznalasaval megoldhato.
A tomorito algoritmus ugyan az mint az elozo valtozatnal, megis ijesztoen javult a hatekonysag, mindezt az adatok optimalis sorrendjenek koszonhetoen.
Packer7o
Ez most kicsit mas. Annyira mas, hogy itt nem a byte-ok ismetledeset szurom ki, hanem a biteket.
Packer8o
Ujra byte-okkal dolgozik a kod, de most kezd vegre javulni igazan a hatekonysag, mert most mar nem csak az egymast koveto ismetleseket keresi, sot, azt konkretan nem is, hanem a grafika teljes byte sorozatat (a modositottat) atnezve megkeres minden ismetlodo sorozatot (repeats), ezekbol kiszuri az atfedeseket, es ugy hasznalja fel, hogy a leheto legkisebb kozok (streams) maradjanak. Ezzel a modszerrel, control-byte-okkal, es 8 es 16 bites szamlalokkal es mutatokkal is, nagyon sokat javult a hatekonysaga.
Packer9o
Tovabbra is stream-ek ismetledeset szuri ki a kod, de a control byte-ok, szamlalok, mutatok bitekre vannak szedve, optimalizalva...
Packer9bo
Lookup table...
Zip
Nagyon jo erzes volt sokszor megverni a zip-et, de most nagyon kihangsulyoznam, hogy a zip osszehasonlithatatlanul jobb, altalanos felhasznalasu tomorito, amiert az enyem nyerhetett, az a manipulalt byte-sorrend, valamint a kis meret (byte-ban), es a kifejezetten a bitmap grafika tomoritesere elezett algoritmus. A mintakon szereplo zip tomorites, a zip file-bol kinyert nyers tomoritett adat, levagva minden egyeb, min 170 byte meretu sallangot. Csak hogy korrektebb legyen az osszehasonlitas.