no i pojawil se nowy krol:

Shrinkler z Amigi.

Pakuje najefektywniej. przebija wszstko co pojawilo sie do tej pory - nawet na pc.

https://www.youtube.com/watch?v=uA0wZtktWv8

ten Shrinkler to dzis chyba pozamiatal... jak narazie nie ma mocniejszego kompresora 7z z LZMA mu ulegl ...

no wlasnie sprawdzam :-) roznego rodzaju dane, binarki, grafike, tekst, muzyke... wszystko pakuje !!! znacznie !!! lepiej od kokurencji. podejrzana sprawa. jest jeszcze wersja no parity - jeszcze lepiej pakuje...

dzieki, zaraz zaktualizuje na AAge

Shrinkler wersja no parity: 1412

dziwna sprawa... dlaczego PC kompresory nie daja rady jakiemus kranczerowi z Amigi?

kod udostepnie tylko troszke pooptmalizuje ;-) jak narazie ok. 350 bajtow ...

ok. z $22C ramek mam juz $1F7  - sekunde szybciej ale ciagle wstyd.

niestety tak wolno... czyta z pamieci. duzo mnozenia 16bit x 16bit.

zrodlo dzis pojdzie na maila.

To jakieś kodowanie arytmetyczne żę tam są potrzebne mnożenia?

juz jest $1EA ramek :-)

Bongo dodany.

kompresja jest bardzo podobna do... z mala roznica ;-) nie chce sie wyglupic bo delikatna roznica potrafi wszystko zmienic.

a ten cały Shrinkler to nie jest zwykłe LZ77 w którym długości sekwencji i offsety są kodowane za pomocą drzewa Huffmana (dynamicznie dobranego podczas kompresji) zamiast prostego kodu prefiksowego (shanon-fanno, elias-gamma, etc.)?

LZ77 "sobie", a to jak są kodowane sekwencje to już wymysł autora danego kompresora/formatu spakowanych danych ;-) Każdy może sobie w sumie nazywać to jak chce ;) równie dobrze można to nazwać LZMA czy jakkolwiek inaczej :) Tak z perspektywy czasu patrząc na to wszystko (w sensie wersji i odmian LZ77) i nad zastosowaniem Huffmana do kodowania len,offset zawsze mi wychodziło że miejsce potrzebne na przechowanie drzewa w przypadku Atari jest "zbyt dużym kosztem", i przy jakichś swoich eksperymentach wybierałem prostsze rozwiązania typu proste "kody prefiksowe", bo sądziłem że jest to lepszą drogą (do czego w owym czasie przekonał mnie PuCrunch czy exomizer).

No ale przyszedł Fox i postanowił zaimplementować "deflate" który to aktywnie korzysta z kodowania Huffmana :) (wcześniej Huffman-a zaimplementowanego na JIL widziałem tylko u Jiriego Bernasek-a w Super Packerze).

btw. jak patrzę na to jak Huffmana zaimplementowano w dekompresorze dla Shrinkler-a... muszę powiedzieć że patrząc na kod dla M68K jestem pod wrażeniem "kompaktowości" tegoż kodu :)

EDIT: ^^^ Przyjrzałem się trochę więcej/bardziej źródłom, to nie Huffman... ale wychodzi na to że użyty został Range Coding, czyli taka integer-based wersja kodowania arytmetycznego. Nie sądziłem że da się to dekompresować w sensownym czasie na 8-bit MCU (szczególnie że potrzebne jest mnożenie). Człowiek uczy się przez całe życie! :)

wtedy królował "Zagęszczacz" Dariusza Rogozińskiego (emitowany w Radiokomputerze) oraz Turbo Copy 3/4 (używany przez piratów "lokalne studia komputerowe" :D O ile Zagęszczacz pozbywał się tylko zer, to Turbo Copy 3/4 używał nawet RLE ;-)

Szybka akcja! Dzięki za realizację! Za badania i testy i za wnikanie w temat kompresji i za odnalezienie takich ciekawostek! :)

prawdę mówiąc to wolę taki kod (bez makr typu ADW, INW, etc.) Jest dla mnie bardziej czytelny... wiem że niektórzy się szybko do tego przyzwyczaili... ale ja nigdy nie potrafiłem jakoś z tego typu dobrodziejstw korzystać.

Jeżeli już pisze w ASM 6502 to preferuję tylko normalne mnemoniki bez tych pseudo-makr. Makra oczywiście tak, ale realizujące nieco bardziej złożone zadania, (np. open, close, bload).

Nie wiem skąd u mnie takie a nie inne preferencje, być może wzięły się one z tego, że w czasach gdy klepałem dużo kodu, nie było tego typu "udogodnień" :) ... a jeżeli chce już mieć bardziej zwięzły i kod i mniej "klepania" to wybiorę raczej inny język programowania :-)