Aktív témák
-
Andie
őstag
Beszólok ide egy okosat, remélem nem fogok nagyon kilógni a sorból.
Anno, TP-s koromban (jó 10 éve) énis szórakoztam ilyennel, konkrétan az adta az ihletet, hogy irtam egy kártyás programot. Ebben a kártyalapokat grafikusan jelenitettem meg ofkoz, de mint ilyen, elég helyet foglaltak (magyar kártya különbözö lapjai). Természetesen bmp-ben voltak, hisz akkoriban még a jpg-t pascalban programozni max a professzorok tudták.
No micsinájjunk. Alapesetben a programom 5 mega volt a képekkel együtt, ami akkoriban, a dukenukemes kislemezes idöszakban horror volt. Nosza, tömöritsünk. Node hogyan?
Napokig törtem a fejem, akkoriban még nem volt net, könyv se nagyon erröl, rar is DOSban futott, sztem zipröl csak a zár kapcsán hallottunk.
Én a következö algoritmust dolgoztam ki, szerintem kezdésnek neked is jó lesz:
Vegyünk egy elég nagy hosszúságú adatfolyamot. Pl egy bmp, vagy egy szöveg, doc, xls, akármi. Még exe is akár.
Ezek óhatatlanul is tartalmaznak redundás adatokat, azaz pl egymásután 150 db space, vagy #0, vagy ilyesmi. Különösen igaz volt ez a BMP-imre, lásd fent. Egy kártyalap fehér - alapvetöen. Namost a sok fehér sok fehér pontból áll, ami helypocsékolás.
Miért nem csinálunk olyat, (szerk, mert nem voltam elég egyértelmü) hogy ahol 3-nál több azonos adat van egymásután, azt soksok byte helyett 3 bytetal helyettesitem : egy speciális jelzö karakter, (hogy itt tömör adat jön) + darabszám + az eredeti adat byte. Értelemszerüen csak 3-nál nagyobb hosszon éri meg, hisz akkor lesz rövidebb az eredeti szekvenciánál.
Nézzünk egy példát. Van egy olyan képem, ami a magyar zászlót reprezentálja. 100 pont piros, 100 fehér, 100 zöld. Ez ugye összesen 300 byte. (binárisan pl : 50,50,50,50 .......50, 34,34,34,34 ..... 34, 88,88,88, ........... 88)
Nézzük ezt tömöritve : !,100,50, !,100,34, !, 100, 88 (amennyiben pl a ! -jel a spec karakter.) Ez igy, ha jól számolom 9byte. 33x-os tömörités!
No persze ez még igy nem teljes, figyelembe kell venni, hogy elöfordulhat 255-nél több azonos adat egymásután, akkor vagy széválasztod öket ( !, 255, x, !, 255,x, ...), vagy 16 bitessel dolgozol, vállalva ezzel azt, hogy viszont amennyiben csak 255nél kevesebb adatot tömöritesz az adott szekvencián, 1 byte fölösleges lesz ( !, 0, 230, x )
Felveti azt a problémát, hogy ha magában a tömöriendö fileban is szerepel a spec karakter (és miért ne szerepelhetne egy bináris fileban), akkor micsinálsz? Hogy azt az értelmezö ne tömöritett adatnak vegye? (megoldás : pl megduplázod).
Ezen apró finomságokkal már nem untatnám a T. közönséget, akit érdekel, privátban részletezhetjük, pl delphi kóddal is akár - vagy közkivánatra akár ittis.
[Szerkesztve]Samsung Galaxy A50 - Samsung UE46D6100 - BNet Tag: Andie#2999
-
Andie
őstag
Igen, pár évre rá aztán olvastam róla, mint szabványositott tömöritési eljárás. Mivel nem jegyeztettem be, nem reklamálhatok
Persze, ahogy irod, nagy, homogén adatstruktúránál hatékony. Egy exénél már nem ennyire. De nekem megfelelt. És pl doksiknál is hatékony lehet.Samsung Galaxy A50 - Samsung UE46D6100 - BNet Tag: Andie#2999
-
Andie
őstag
Ha meg $0800-tól irtál, és elötte beváltottál grafikus képernyöre, akkor szép szines krixkraxokat lehetett kirajzolni
Demoscenére már csak poénból is igy csináltuk. Volt, hogy a krixkarxok végén, mikor megvolt a kitömörités, a pontokból kezdtük felépiteni az elsö képet
Ha meg a maszkolt $A000tól irkáltál, és elfelejtetted utánna visszabillenteni a romot, akkor megnézhetted a szép fagyást
Ejh, szép idök is voltak. Ciklusok helyett 150x kimásoltuk ugyanazt az LDA... CMP .. .STA... BNE sorozatot $8000-töl, és ráfuttattuk a kódot, realtime!
Ki emléxik még a sprite 1 engedélyezésére szolgáló cimre? (könyv nélkül!!!)Samsung Galaxy A50 - Samsung UE46D6100 - BNet Tag: Andie#2999
