Tak, szybkość jest dla mnie istotna, bo w locie rozpakowuję plansze w grze podczas przechodzenia z planszy do planszy i nie może być za długo czarny ekran, bo się gracze zniechęcą, żeby nie powiedzieć wq...ą:-)

Takie rozpakowanie u mnie za pomocą apl, to jest 6k danych graficznych, plus dwa fonty po 1k, więc 8k musi się rozpakować w czasie do sekundy. U mnie to trwa za pomocą unapl standardową biblioteką z Mad Pascala jakieś 40-50 ramek.

Teraz doczytałem we wcześniejszych postach, że testowałeś dane podobnej wielkości i już po optymalizacjach uzyskałeś 488 ramek, czyli około 10x wolniej niż apl. W takim razie odpuszczę, może mi się ta kompresja przyda kiedyś do innych zastosowań, widać do innych celów jest shrinkler.

to chodzi o Amigoskiego PP?

@Mq: juz rozwiazales swoj problem :-) Shrinkler jest najwydajniejszy i najwolniejszy :-)

tylko _DST musi byc na ZP reszte mozna przeniesc za kod albo do samomodyfikacji w kodzie :-)

inicjacje tablic mozna zmienic i np. jesli depakujesz 8kb dane to tylko dwie pierwsze strony bufora sa zajete a pozostale strony bufora po 32 bajty z poczatku strony reszte mozna uzywac ;-)

Fajnie, ale to komercyjny projekt...

Jeśli ktoś czuje się na siłach to można jedną małą zmianą przystosować Shrinklera do pakowania w taki sposób żeby na 6502 dało się to szybko dekompresować:

wystarczy zawęzić licznik kopiowanych bajtów do 8-bit (jest 16bit) - to algorytm rodziny LZ więc kopiowanie jest intensywnie wykorzystywane. Taka mała modyfikacja a zmienia wszystko :-)

sprawdziłem, co prawda tylko na 3 plikach ale daje to już jakiś obraz: najczęściej ilość to przedział 2-44 bajty sporadycznie przekracza wartość 7-bitową (8 bitową raz ale specjalnie przygotowałem dane) więc utrzymywanie 16-bitowego licznika za każdym razem...

gpl-3.0.txt: 35149
lzfse: 12545
zopfli --deflate: 11410
Shrinkler -d -p -9: 11584

Dlaczego masz inne wyniki od moich? Skąd wziąłeś Shrinklera i Deflater? Ja skompilowałem Shrinklera z GitHuba, a zopfli z MSYS2.

Tak sobie obserwuje i podziwiam wasze efekty pracy i też się pobawiłem (w ramach żartu), beat this:
zip - ultra - PPMd - 9602
7zip - ultra - PPMd - 9595
:)

sprawdzilem i teksty do ok. 22kb shrinkler pakuje lepiej od deflatera, powyzej tego sytuacja sie odwraca

ciekawe.

---
prawda jest jeszcze inna... sprawdzalem teksty ktore sa listingami progrgamow i tam shrinkler faktycznie wygrywa, jesli sprawdzac zwykly tekst jak ten gpl to deflater goruje :-)

Następne 19 bajtów. :)

moglibyście rozważyć wersję dla 65816 ?

plik znajduje się w pamięci dodatkowej (max 64KB) i dekompresowany jest pod 24bit adres

nikt jeszcze nie przystosował dekompresora pod 65816, albo nikt nie udostępnił

Może kogoś zainteresuje mój warsztat. Mam teraz monitor 4K i świetny edytor, ale przy bardziej zaawansowanych optymalizacjach kartka jest niezastąpiona.

To ma sens, bo kod jest mocno 16-bitowy i nawet kulawe przełączanie się między trybami 8/16 bitów nie powinno boleć. Plus MVN się przyda. Ale dopał nie będzie taki, jak przy szybkim mnożeniu na 6502.

Dobre pytanie.
Na PC zwykle kompresuje się tylko bardzo duże zbiory i przykłada wielką wagę do wydajności dekompresji, a mniejszą do stopnia kompresji. Shrinkler wykonuje jedno mnożenie i kilka operacji warunkowych na każdy bit skompresowanego strumienia. Nawet na wypasionym pececie dekompresja tak skompresowanych gigabajtów trochę potrwa i nie ma jak jej zrównoleglić. Na Amidze i Atari każdy poczeka te kilka sekund na rozkompresowanie pojedynczych kilobajtów. Na pececie przydałaby się akceleracja sprzętowa. Być może dałyby radę akceleratory AI, które są świetne w mnożeniach.

WTF? Ci amstradowcy to piszą doktoraty z cruncherów?