Oczywiście, że nie jem (mięsa) w trakcie pisania postu
Dzisiaj kolejna świetna wymówka: szukam baterii do laptopa i nie mogę znaleźć

Poczekam tu jeszcze 5 minut, to od razu na jutro też jakąś wymówkę odpalę.

Uch, o nie, dzisiaj też żadnych postępów ++

Czyli wracamy dopiero w wakacje?

Jak miło widzieć kogoś innego niż ja w tym temacie :spiel:
Prawdopodobnie tak, bo dostałem jakiś przedmiot zabójczy ;-;

Dzisiaj
na razie nic, ale zainstalowałem VS 2019 w miejsce VS 2017, może to coś da xD

Ech, Ghidra też nie dziabie.
Zastanawiam się, czy przypadkiem coś nie jest nie tak z testami... Albo może próba kompilacji tego w C++ to słaby pomysł i to, co wypluwają dekompilatory powinienem wsadzać w C jak należy?

Pozostaje też jeszcze świetna metoda prób i błędów znana z rozkodowania CRLE i formatów plików... Na razie z historyczną przewagą błędów...

City of Secrets 2 obalone

CoS i CLZW zaczynają się na tę samą literę, więc może już wkrótce...
(Ale nie dziś, odhaczam.)

To może dzisiaj? Ptaszki śpiewają, kwiatuszki powoli przekwitają, jest maj, miesiąc gdzie wszystko się rozwija, gdzie już nie ma zimy, ale jeszcze nie ma lata. Idealny dzień na rozkodowywanie CLZW

W dni takie jak ten
forumowicze tacy jak ja
powinni być
k o m p r e s o w a n i C L Z W 2

Wakacje zapowiadają się wyjątkowo ciekawie

Rzeczywiście, LZO kończy się na 11 00 00

:piwo: świętujemy

Hej, znów maj!

Ogólnie to orbitujemy wokół tego pomysłu z bazowaniem CLZW2 na jakimś istniejącym algorytmie, no bo, bądźmy szczerzy, komu by się chciało tworzyć algorytm kompresji od zera do użycia w grze familijnej i jeszcze nazywać go jakąś sugestywnie znajomo brzmiącą nazwą?
Natknąłem się na ostatnio na tę stronę, która omawia algorytmy z rodziny LZRW - bazujące na LZ77 (bo IMO LZW bazujące na LZ78 nie jest podobne do tego, co implementuje piklib), wykorzystujące do kompresji hashmapy i nazywają się tak tylko dlatego, że LZW było już zajęte ( ).
Dzisiaj postanowiłem jakoś skonfrontować to potencjalne rozwiązanie z rzeczywistością, ale wygląda na to, że przynajmniej dla LZRW1 nie zgadza się rozmiar słownika oraz sama funkcja mieszająca. W ogóle w CLZW2 to jakoś dziwnie działa - tam są jakby dwie funkcje mieszające, pobieżnie patrząc (albo po prostu bredzę).
Może LZRW2 okaże się bardziej przydatny, ale to pieśń przyszłości na ten moment (szczególnie biorąc pod uwagę świeże kolosy i projekty na horyzoncie xD).

Ach, i pewnie niektórzy śmiałkowie już zorientowali się, że kod dekompresji jest łatwiejszy do zrewersowania ze względu na brak tych ciekawych optymalizacji typu wykorzystywanie hashmapy, ale ja dopiero dziś zderzyłem się z tą myślą, więc zamieszczam ją tutaj.

P.S. LZO nie przetestowałem w końcu xD

Na drodze systematycznych badań i analiz, dosłownie piętrząc na sobie kolejne podejścia i korzystając ze skumulowanej na przestrzeni lat wiedzy...

Tam da da dam, linkuję oto poniżej spis symboli kodowych występujących w algorytmie kompresji CLZW2:
https://gist.github.com/Dove6/0d21e7639 ... 0b6bdacfaa

Na cele testowe sko-konstruowałem prosty dekoder w Pythonie i przeszedłem nim po wszystkich plikach .img, jakie miałem, doprowadzając stopniowo do stanu, w którym się nie wywala. Nie jest to może gwarancja poprawnego działania, ale wygląda obiecująco. Na dniach postaram się sprawdzić, czy te grafiki po rozkodowaniu rzeczywiście dobrze wyglądają xD Ale na ten moment jestem po prostu zadowolony, że udało się obalić kolejny kamień milowy reksiowego dekodowania.