Hirdetés
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- Geri Bátyó: Agglegénykonyha 1 – rizseshús másképp
- Luck Dragon: Asszociációs játék. :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- EmPoWeR: Költözés uTorrent-ből qBittorrent-be
- sziku69: Fűzzük össze a szavakat :)
- Magga: PLEX: multimédia az egész lakásban
- Meggyi001: Chrome - Kérjük vissza a Chrome alsó letöltési sávját
- Geri Bátyó: Agglegénykonyha 3 – Paradicsomos káposzta (amit amúgy utálok)
Aktív témák
-
-
-
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!!!) -
Jester01
veterán
Jó móka volt, én is írtam.
Mindenféle karaktereket pörgettek a képernyőn kitömörítés közben
Ez pedig azért volt (legalábbis az én kódom esetén), mert biztos lehetett az ember, hogy a képernyő memóriát nem kell felülírni a kitömörített adattal, tehát nyugodtan oda lehetett pakolni a kódot magát. A pörgés egész egyszerűen a lokális változók aktuális értékét mutatta, amik közül jó eséllyel volt két pointer is amik szépen növekedtek ahogy a kicsomagolás haladt előre. -
Sianis
addikt
válasz
Dilikutya
#36
üzenetére
Lehetséges, hogy igazad van!
Ezen lehet vitázni...de persze felesleges. Persze nem lebeszélni akarom a kedves ''kollégát'' erről só sem lehet.
FreePascal? Tudnék róla mesélni...mikor suli beadandót megírtuk TP7-en, tökéletesen ment, suliban meg? FPC hozzá sem akart nyúlni... Persze azóta lehet javítottak rajta, bár nekem akkor az elég kemény behatás volt, mert 12 órát ültünk a gyaksziteremben, hogy legalább elfogadható legyen...
[Szerkesztve] -
Dilikutya
félisten
Ahhoz, hogy bármelyik, már meglévő módszerhez hozzá tudj szagolni, előbb értened kell. És ha már érted, akkor valamit magad is tudsz alkotni, amellett, hogy a már meglévőt is megpróbálhatod pofozni. Arról nem is beszélve, hogy fiatal, kezdő programozónak nem az az élmény, ha egy már meglévővel csinál valamit, hanem az, ha ő maga alkot egyet. Kicsi is, srága is, de az övé
. -
Sianis
addikt
Hát szerintem elég felesleges valakinek magában elkezdeni ilyet! Hogy miért? Mert ott van pl a 7zip, ami ha jól tudom nyílt forrású. Felesleges elpazarolni a tudást a kerék újrafeltalálására, inkább tökéletesíteni kell. Nem pazarold az elméd ilyesmire. Inább tanuld meg azt amit már elértek, gondolom tele vannak doksikkal, és csatlakozz...
-
plömplöm
őstag
hátja, több kisebb részletben, csak marha nehéz a magnót pont ott újra elindítani ahol az előbb megállt
merthogy ezek egy szép nagy fájl voltak ám, kopiprotekt, pld egy zotyocopy simán elhasalt memory full-lal...
azért is mondtam amit mondtam, mert egy z80-ra készült program még az én egyszerű agyamnak is feldolgozható és megérthető és átlátható (volt valamikor) -
sky77
aktív tag
Pl. több kisebb részletben... Ettől függetlenül C/64-re is voltak tömörítők, kódokat lehetett velük ki- és betömöríteni. Mindenféle karaktereket pörgettek a képernyőn kitömörítés közben. Szerintem ezeknek az eljárásoknak a gyökere persze ezeknél az időknél is mélyebbre nyúlik vissza.
-
Goose-T
veterán
Szerintem ez volt a legelső, legkézenfekvőbb adattömörítési eljárás, amit még a hőskorban kitaláltak, mellesleg minden második kezdő programozó újrafelfedezte magának. Nem igazán lehet már új veszteségmentes tömörítési algoritmusokat kitalálni. Az alapok megvannak évtizedek óta, többé-kevésbé ezeket optimalizálják.
-
Andie
őstag
-
Igen, ez az RLE (runtime-length encoding) tomorites, pl a PCX kepformatumban hasznaltak, ami szinte teljesen ugy mukodik, mint amit itt leirtal
Az egyetlen problema az vele, hogy a valos eletben nem mukodik tul jol, nagyjabol a nagy, egyszinu feluleteket tartalmazo kepeknel produkal vmi ertelemes tomoritest. -
Miracle
senior tag
ahogy tovabb olvasod, teljesen nyilvanvalova valik, hogy halalosan komolyan gondolja a dolgot :> de nekem sok oranyi szorakozast jelentett, ahogy egyesek megprobaltak neki tenyleg jol elmagyarazni hogy ez nem igy mukodik, mert 2^16on, meg entropia, meg ilyesmi, es a sracrol ugy pergett le, mint a falra hanyt fagyott borso. szerintem akik magyaraztak mar a hajukat teptek ;)
-
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] -
Dilikutya
félisten
Amúgy volt már korábban egy topik, egy prohardver réme nyitotta, akinek a kismilliónyi nickjével csinált sok topikjából talán ez az egyetlen, a tömörítős volt az értelmes, csak a kereső sehogy se akarja kiadni. Abban úgy emlékszem, voltak linkek, hasznos ötletek, meg kéne találni.
[Szerkesztve] -
-
Dilikutya
félisten
Mit szólnátok ahhoz ha azt mondanám, hogy elméletben kitaláltam egy olyan tömöritési eljárást, amivel bármekkora fájlt betömöritek 2 bájtba? Akár 52 GB méretű fájlt is... A programot már elkezdtem fejleszteni, lassan kész az alap felhasználói interfész. Pár napon belül elkezdem fejleszteni a tömöritési eljárást. Mi történne ha ez a program kikerülne a piacra? Képzeljétek el hogy akár több ezer filmet el tudnátok tárolni egy 1.44 -es lemezen... Várom a véleményeteket!
Nem találok szavakat... de a projekt jól halad, a felhasználói interfész készülget, már csak az algoritmus van hátra. Azt hiszem ezt a témát át fogom olvasni![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Miracle
senior tag
,,(Ha új algoritmust kívánsz létrehozni, akkor kösd fel a nacit! ''
hat a temaindito hozzaszolas eppen nem erre utalt
)
de ha mar itt tartunk ajanlanam figyelmetekbe a kovetkezo topicot, 3 oraig sirtam a rohogestol amikor olvastam, azt hiszem siman megerdemli az orokzold jelzot
[link] -
Szalma
őstag
(Ha ''entrópia'' és ''elméleti legjobb kódolás'' irányában tapogatózol, akkor a ''legjobb'' tömörítés az aritmetikai kódolás lenne. De jöttek a programozók és alávágtak az egyszeri matematikusoknak... Akik jól megmagyarázták utólag a Huffnam kódolást...
(Ami egy változó bithosszú blokktömörítő tulajdonképpen...))
Szeretettel:
Szalma -
Szalma
őstag
(Ha új algoritmust kívánsz létrehozni, akkor kösd fel a nacit!
Elsőnek javaslom, mondjuk a létező algoritmusok implementálását, ezek megfelelő kombinálása elég jó eredményt ad... Itt van mondjuk egy kedves transzformáció LZW optimálásához -> [link], és itt kapirgálhatsz az LZW irányában is -> [link]... Ezeket megérteni sem kis feladat...
Nem egyszerű a korrekt megvalósítás sem...
Hajrá!)
Szeretettel:
Szalma -
Miracle
senior tag
igazabol a pascal tokeletesen eleg egy tomorito algoritmus lekodolasara, esetleg ajanlanam az atallast freepascalra, az egy joval modernebb, 32bites forditot tartalmaz.
es ha tomoritot akarsz irni, akkor az entropia foglamaval kell tisztaba gyere (nem irom le, mert orakra lenne szuksegem hozza, es fele olyan jol sem tudnam elmagyarazni mint a google segitsegevel megtalalt elso 5 oldal)
a kovetkezo elterjedt algoritmusokat ajanlom figyelmedbe, eleg egyszeruek, siman lekodolhatoak par ora alatt:
Huffman kod (arj, rar, ace, ez az elmeleti legjobb kodolas, csak kicsit lassu)
zip (zip, gzip, bz2 ez is majdnem ugyan olyan jo, de joval gyorsabb, es a bz2 piszkosul jo)
lz77, lzw (adatfolyamok tomoritesere hasznaljak)
sok sikert -
jimmy399
senior tag
Szevasztok!!
Elhatároztam, hogy írni szeretnék egy egyszerű tömörítő programot. Ehhez szeretnék egy kis segítséges kérni tőletek. Az a legnagyobb baj, hogy nem tudom, hogy egyáltalán hogyan is kezdjek hozzá. Kezdetben Tp7ben szeretném megírni az algoritmust, amely a tömörítést végzi, majd később áttérnék egy ''modernebb'' programozási nyelvre. A cél, hogy létrehozzak a segítségetekre támaszkodva egy egyszerű algoritmust a tömörítésre.
A válaszotokat előre is köszi!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(valahol $D000 körül volt a sprite is, az is VIC)
Aktív témák
- Majdnem száz játékhoz engedélyezi az FSR 4-et az új AMD Software
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Milyen billentyűzetet vegyek?
- Jófogás tapasztalatok
- Ingatlanos topic!
- gban: Ingyen kellene, de tegnapra
- LEGO klub
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- Samsung Galaxy Watch Ultra 47mm LTE (Titanium Silver) - Újszerű, 2 év garanciával!
- VivoBook 15 X540UBR 15.6" FHD i3-8130U GeForce MX110 12GB 480GB magyar bill gar
- IPhone 16 Pro max 512GB gyári független 2025.10.22. Apple jótállás
- Electrolux 240-4S hűtő
- ASUS ROG Ryujin III 360 ARGB (Micro hibás) INGYEN FOXPOST
- BESZÁMÍTÁS! ASUS B450 R7 5700X 32GB DDR4 512GB SSD RTX 4060Ti 16GB Zalman Z1 Plus Cooler Master 650W
- Új Dell 13 Inspiron 5310 FHD+ IPS i5-11300H 4.4Ghz 8GB 256GB Intel Iris XE Graphics Win11 Garancia
- LG 77G4 - 77" OLED evo - 4K 144Hz 0.1ms - MLA - 3000 Nits - NVIDIA G-Sync - AMD FreeSync - HDMI 2.1
- HIBÁTLAN iPhone 14 Pro 256GB Space Black -1 ÉV GARANCIA -Kártyafüggetlen, MS3234
- HIBÁTLAN iPhone 14 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3242
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest