cross-platformowe crunchery

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
joodas
Posty: 321
Rejestracja: 05 wrz 2009, 11:42
Grupa: Albion Crew

cross-platformowe crunchery

#1 Post autor: joodas »

Witam

Z cross-platformowych cruncherow znam exomizera, pucrunch. Istnieja moze jeszcze jakies inne cross-platformowe crunchery, ktore sa dobre w pakowaniu i warto sie z nimi zapoznac? Uzywal ktos moze Byte boozera?

Pozdro
Joodas

Awatar użytkownika
Nitro
Posty: 1544
Rejestracja: 03 wrz 2008, 20:23
Grupa: Black Sun

#2 Post autor: Nitro »

Spróbuj crunchera wegiego/b]: Bongo, jeszcze ostatnio ludzie zaczęli się interesować Doynaxem.

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#3 Post autor: wegi »

Pucrunch, Exo, Byte Boozer, LZWVL, DOYNAX, Level Cruscher, Bongo w linking enginie - poprzednia wersja zawiera kilka bugów przy tworzeniu RAWdata o ile pamiętam, także są 2 wersje bongo w enginie jedna z GUI druga bez... Bitbreaker robi Mongo - oprócz mojego tricku "how_many_bits-1" implementuje "bitbucket" z DOYNAXA - jest zabawek. WVL zamieścił ładne testy cruncherów przy releasie LZWVL. Boozer buguje nie toleruje plików z encored bytes, tym samym nie podaje bezpiecznego adresu ładowania i ma dość długi depak. Tabelki odpowiedzialne za rozszerzanie zakresu adresowego offsetu nie zawsze są optymalne dobór dynamiczny dawał lepsze wyniki (wiem bo testowałem to samemu:)). A tak naprawdę to musisz sobie wszystko samemu potestować i wyciągnąć własne wnioski.

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#4 Post autor: wegi »

Nie jako autoreklamę, ale gdyby było trudne do zrozumienia lista parametrów z bongo:

-NOLDAD - to wackowa zmora - określa czy kompresowany plik jest z load adresem a tak zazwyczaj bywa. Domyślnie jeżeli ten parametr nie zostanie użyty program zakłada, że load adres jest i pierwsze dwa bajty zostaną zignorowane. Jeżeli jest loadadres to zostaje on domyślnie uznany za depack adres - ponieważ z reguły chcemy rozpakować dane tam skąd pochodzą.

-NODEPACKADR - zapisany skompresowany plik jest bez informacji o adresie depakowania wówczas przed wywołaniem decrunchera user musi sam ustawić "PUT" wektor.
-RAWDATA - to samo co poprzednio po prostu inna nazwa - domyślnie dane są zapisywane z depack adresem (jeżeli ten parametr nie zostanie użyty)

-DEPACKADR - tu możemy zmienić domyślną wartość depack adresu lub podać jaką chcemy, jeżeli pakujemy dane bez load adresu

-NOGOLDENSEQ - domyślnie używa złotych sekwencji owocuje to nieraz lepszym ubiciem (wszystko zależy od danych - dobre efekty dla speedcodu) i około 100 bajtów dłuższą procedurą dekompresji - 48 bajtów na tablicę złotych sekwencji i drugie tyle na ich obsługę.

-ITERATE - możliwość skompresowania dwukrotnie lub więcej kompresowanego pliku jak widać przy spidkodzie się sprawdza - decruncher musi być używany w wersji "recursive" - polecam do SFXa.

-BINFILE - plik zapisany będzie bez dołączonego SFX decrunchera
-PRGFILE - spakowany plik zapisany będzie z dołączonym decruncherem, który jest w 4ch wersjach dobierany dla rodzaju pliku - wersja SFX - najniższy możliwy depack adres $0400 - oczywiście można kombinować i samemu dołączać decrunchery do plików BIN z podanych przykłądów w razie potrzeby. Są cztery wersje sfxdecrunchera zaszyte w cruncherze i dobierane do danych głównie dlatego, żeby rozróżnić recursive/norecursive i np Turboassembler z pod $9000 po spakowaniu nie trzeba targać na koniec ramu przed depackiem.
-NOSAFELDADR - domyślnie zapisany plik jest z bezpiecznym adresem ładowania - oznacza to - najniższy możliwy adres w polu dekompresowanych danych przy którym nie nastąpi kolizja decrunchera (decruncher nie nadpisze depakowanych danych danymi zdepakowanymi)
-MYLDADR - własny bezpieczny load adres - można ładować w przypadku krótszych plików dane do zdepakowania w różne obszary - po to to jest.

-VALUE01 - chyba nie trzeba tłumaczyć
-JMP $ - dla sfx wiadomo co
(UWAGA) O STAN FLAGI INTERRUPT USER MUSI ZADBAĆ SAM - NIE JEST ZMIENIANA W SFX JEST USTAWIONA JAKO "SEI" - A W IRQ DEPAK WIADOMO JEST "CLI"

-PACKFROM
-PACKTO
te dwa parametry określają od którego bajtu do którego ma być wykonany crunch danych jeżeli ktoś potrzebuje skompresować tylko jakąś wybraną część pliku. Tak naprawdę z tym samym skutkiem załatwiałoby "wycinanie" danych za pomocą kompilatora z dowolnego pliku za pomocą dyrektywy ".binary"... Program stara się robić to inteligentnie, jeżeli plik był z load adresem to oblicza jego offset dla depack adresu. Oczywiście jeżeli nie zostaną one użyte pakowany będzie cały plik - z uwzględnieniem parametru NOLDAD oczywiście.

Linia komend działa i dla wersji z GUI i dla wersji bez GUI. W wersji z GUI zostawiłem kilka zabawek takich jak statystyki znalezionych sekwencji, wyrzucenie do excela rezultatów scanningu i ewentualną możliwość ograniczania ilości używanych złotych sekwencji w zakresie 0 do 16.
(PACKFROM I PACKTO DOSTĘPNE TYLKO Z CMD)

Załączone (w GUI) decrunchery są w wersji optymalnej do szybkeigo depakowania jak i w wersji short - jak najkrótszej. No i należy użyć przełączników recursive i golden_seq_used do swoich potrzeb. Dodatkowo są 3 przykłady SFX dekpmpresora, oprócz tego oryginalne użyte źródła SFXdecruncherów są także zamieszczone w sourcach crunchera w zipie i jeden decruncher z pomiarem czasu.

aaa - bardzo ważne info - encored bytes - w zależności od "podłości" danych end adres spakowanego pliku może być od jednego do kilkuset bajtów dalszy od oryginalnego - czyli de facto dane za oryginalnym end adresem zostają zamazane i koder piszący demo MUSI o tym wiedzieć o ile bajtów "zachodzi" dalej taki plik. W małych plikach nie ma to wielkiego znaczenia jeżeli mamy dużo wolnego ramu możemu to umieścić gdziekolwiek. No i jest jeszcze możliwość w przypadku pliku który pakujemy i dochodzi on pod $FFFF, że encore przejdzie za $FFFF - taki plik się nie rozpakuje - najpewniej powiesi kompa. Jeżeli jest to krótki plik mamy szansę umieścić go gdzieś poza obszarem dekompresji. Ewentualnie można ciut zmienić dekompresor, dołożyć mu 256 bajtowy bufor, z którego będzie się dekompresowało dogrywane streamowo dane. Przypadek ten jest bardzo rzadki aczkolwiek możliwy dlatego wspominam o nim.

Pozdrawiam

ODPOWIEDZ