Exomizer - z czym to się je?!

[BagoZonde]

Witam ponownie , zwracam się z prośbą do koderów w sprawie wyjaśnienia jak szcholera działa ten Exomizer?! Co robię źle? Choćby wskazówka będzie dla mnie wybawieniem. Po trzech dniach walki dałem sobie z tym spokój, dokumentacja jest bardzo skromna - dla mnie, beginnera z krwi i kości jest to Enigma.

Chciałbym spakować bitmapę multicolor. Pobrałem więc w tym celu Exomizer 2.0.2 i przystąpiłem do działania:

1. Spakowałem bitmapę z poziomu DOSu: exomizer mem -l$2000 bb.koa -obb2000.exo - myślę, że podając -l$2000 deklaruję, że chcę umieścić ten spakowany plik pod $2000+. Koniec pliku wypada na $23ea.
2. Utworzyłem PRG, gdzie zinkludowałem plik wrap.s, w którym z kolei jest include pliku exodecrunch.s - oba przekompilowałem 64TASSem więc była potrzebna lekka modyfa z DASMa. Początek decrunchera czyli labelkę exod_decrunch ustawiłem na $1000.

3. Następnie ustawiłem przed wywołaniem procedury rozpakowującej: LDA #$ea; LDX #$23 ;STA $1010; STX $1011; po tym właśnie następuje JSR exod_decrunch.

Te informacje wyciągnąłem z przeróżnych forum więc nie wiem czy jest to sensowne. Próbowałem przeanalizować kod i rzeczywiście ten kod się modyfikuje, ale nie jestem w stanie stwierdzić czy to dobrze działa bo wcześniej czy później następuje jakaś zwiecha. A co najlepsze: nadal nie wiem gdzie podać miejsce do zdecrunchowania?!

Dane pod $2000 rzeczywiście zmieniają się po uruchomieniu, ale sam program zwiesza mi się, np: pod $e5cf. Wygląda to tak jakby decruncher nie wiedział kiedy przestać.

W wrap.s znalazłem też zmienną opbase, do której ładowane jest $ffff, w/g komentarza należy tam podać ostatni bajt spakowanego pliku no więc $23ea - próbowałem wielu kombinacji ale bez powodzenia.

Nie rozumiem tego Exomizera, nie dorastam skillem do najmłodszego bajtu w tym kodzie , pomóżcie!

[Raf]

najprosciej to chyba tak ... sciagnij exomizer 1.x i to:

http://noname.c64.org/csdb/release/?id=52536

[V-12/Tropyx]

A po co Ci Exomizer? Mało to cruncherów na C64?

Dla mnie robienie rzeczy na pc to totalna strata czasu. Jeżeli potrzebujesz czegoś, co Ci spakuje plik i potem będziesz mógł sobie to rozpakować w swoim programie, to mogę Ci polecić jeden program na C64, którego używam do dziś, głównie do kolekcji muzycznych/graficznych.

[BagoZonde]

V-12/Tropyx
Po co Exomizer? Chciałem sięgnąć po najnowszy cruncher, zresztą jest mocniacki.
Objąłem strategię tworzenia projektu na pececie właśnie dlatego, że zaoszczędzam na typ bardzo dużo czasu. Kompiluję w 64TASS, grafikę robię w GangEd, muzykę w GoatTrackerze itd. W szybki sposób mam dostęp do poszczególnych elementów, zmiana choćby jednego denerwującego piksela w grafice zajmuje chwilkę, wszystko jest linkowane z zewnątrz i właśnie także bitmapę spakowaną Exomizerem chciałem zlinkować.

rafvte
Nie mam problemu z komendami DOSu więc GUI nie jest konieczne. Tak jak pisałem, chodzi mi o wdrożenie decrunchera do kodu.

Utworzyłem PRG tym Exomizerem 1.15 i przepisałem kod z monitora, wygląda na to, że dane zawarte są w środku - zarówno na początku jak i na końcu jest kod. Decrunch chyba się udał ale podając adres $6000 wypakowywał mi od $5000 więc nie wiem czy może dzieje się tak dlatego, że jest wsteczny decrunch, dziś spróbuję dalej powalczyć z tym kodem. Dążę do tego by użyć tego kodu a w środek wciskać surowy zcrunchowany plik (jako .binary) - gdyby to zadziałało, sprawa byłaby załatwiona. Spakuję sobie jakieś charakterystyczne dane, np: ciąg od 0 do 255 i spróbuję po tym dojść jak to jest zbudowane dokładnie .

[Raf]

zapodalem exo 1.x bo jest neico latwiejszy w uzyciu a gui "rozpieszcza"

pakowanie exomizerem jest szybsze niz gdyby robic to na c64, ponadto exomizer ma bardzo dobra kompresje - przewyzsza rara 3.

http://noname.c64.org/csdb/release/?id=45564 - tutaj znajdziesz kod zrodlowy 69 positions - jest to kompletne i pelne rozwiazanie uzywajace fastloadera dreamload i dekompresji exomizera 1.x (nie depakuje w locie - laduje plik do bufora i potem dokonuje dekompresji)

[BagoZonde]

Dzięki, próbowałem walczyć już z tym 69 positions ale bez powodzenia. Przekopałem z tym exomizerem całego wujka google. Rozkminiam to wszystko jeszcze raz.

[V-12/Tropyx]

BagoZonde:

Objąłem strategię tworzenia projektu na pececie właśnie dlatego, że zaoszczędzam na typ bardzo dużo czasu.

Straciłeś właśnie dzień na szukanie możliwości uruchomienia Exomizera. Nie widzę tutaj oszczędności czasu. Resztę przemilczę.

[Kisiel]

stary sprawdzony http://noname.c64.org/csdb/release/?id=69129 do leveli gier, caly system z loaderem i depakiem http://noname.c64.org/csdb/release/?id=97608
Gdzieś jeszcze był tool do pakowania na PC, tylko po co.

Wujek dobra rada: zajmij się czymś poważnym

[BagoZonde]

V-12/Tropyx
Widzę, że kolega chyba mnie nie rozumie . Właśnie po stronie C64 mam problem z rozpakowaniem tego. Po stronie peceta crunchowanie wykonuje się po prostu z DOSu.

Zrobiłem kroczek do przodu, decruncher już nie zwiesza się - jest po prostu "ładne" wyjście z procedury. A co więcej - włączyłem sobie przed decrunchowaniem bitmapę w banku #3 i widzę jak rozpakowuje mi dane pod $e000! Idzie od końca (od $ff3f jak mnie pamięć nie myli) i kończy na $e000.

Problem tylko w tym, że po rozpakowaniu nie przypomina to tego, czym było przed przepuszczeniem przez exomizer. W get_crunched_byte siedzi sobie starszy i młodszy bajt. Po zakończeniu crunchowania zostaje tam $7802 (spakowaną bitmapę wrzuciłem od $7800 tak jak w demie 69 positions) więc wszystko wygląda na to, że działa dobrze. A jednak coś nie gra. Przynajmniej zacząłem bardziej to wszystko ogarniać.

Kisiel
Rzeczywiście, exo sobie na razie podaruję, wujek prawdę ci powie . Będę musiał kiedyś nad tym przysiąść żeby móc wykorzystać w projektach na dyskietkę. Teraz czas na jakieś animacje może .

[V-12/Tropyx]

BagoZonde:

Widzę, że kolega chyba mnie nie rozumie .

Kolega też mnie nie rozumie. Gdybyś skranczował jakimś softem na C64, byłbyś już dawno do przodu ze swoim tworem

Kisiel:

stary sprawdzony http://noname.c64.org/csdb/release/?id=69129 do leveli gier, caly system z loaderem i depakiem http://noname.c64.org/csdb/release/?id=97608

Dokładnie. Ten zestaw używałem do tworzenia pierwszych moich dyskowych produkcji jakieś ponad 10 lat temu. Loader Madroma spisywał się bardzo dobrze.

[zyga]

BagoZonde
Rozumiem, że PuCrunch nie spełnia twoich oczekiwań ? http://noname.c64.org/csdb/release/?id=6089

Prawdę mówiąc nie wczytywałem się w opis jego możliwości

[Skull]

uch, dopiero teraz ten temat zobaczyłem.

Korzystasz ze źródłówki dołączonej do exomizera?
Nie jestem pewien, sprawdź jak jest ustawiona stała dla trybu wartości literalnych (pakowanie tekstu) cośtam_literal = true (lub false)

jak jest ustawiona na false, to pakuj dane z opcją -C, inaczej właśnie źle się rozpakowuje.

W spakowanym pliku exomizerem, dwa ostatnie bajty to adres ostatniej komórki przed spakowaniem, a więc dla bitmapy $2000-$3f3f to właśnie te $3f $3f.
Exomizer depakuje od końca, a więc teoretycznie jak umieścisz spakowny plik od $1f00 to nawet się powinien rozpakować  (nie powinien najechać się początek spakowanego z niespakowanym)

[Kisiel]

ok, to juz tak łopatologicznie.
1. chcesz pakowac pliki po to aby mieć więcej miejsca na engine gry,
2. wczytujesz plik do pamięci i rozpakowujesz go do pamięci,
3. zajmujesz tym plikiem pamięć więc wracasz do punktu 1.

Tak to możesz całe życie robić tą gre.
Zasada jest prosta jeżeli depakujesz level do czegoś,  nigdy nie robisz tego w buforze dlatego, że odczyt i depak trwa tyle samo co depak z odczytem.
Proste jak je*anie ,używasz do tego level pakierów z loaderem jako system, jest tego od groma. Najprościej potem zmieniać loader na procedure ciągnącą bajty z rozszerzenia czy z jakieś egzotyki.
PS. straciłeś kolejne dni z reszty swojego życia.
PPS. Jeżeli wybierasz młotek do wiercenia otworów to nie pytaj dlaczego nie wychodzi otwór, zapytaj czy młotek się nada

[BagoZonde]

Skull
Korzystam ze źródłówki demka 69 Positions. Jest tam użyte literal z tego co widzę i używając opcji -l ten literal jest włączony. Dołączony jest też do tej źródłówki demka sam execute exomizera (wersja 1.1.5).
Przypomnę, że zexomizerowałem to tak: exomizer -l$e000 bitmap.bb -obitmap.exo
Samą bitmapę utworzyłem w ten sposób, że załadowałem do GangEd rysunek w koali i zapisałem jedynie bitmapę z tego (wczytuję ją do banku pod $c000).
Spakowaną bitmapę wczytuję sobie pod 7800 dołączając binarkę po prostu:

*=$7800
bitmap .binary "bitmap.exo"

więc nie powinno być możliwości nachodzenia na siebie czegokolwiek (decruncher jest pod $9300).

Co do wartości docelowej: to zarówno w Exo v.1 jak i w v.2 wartość tą podaną mam na samym początku spakowanego pliku a nie na końcu - w kolejności 00, $e0. Na pewno musi tak być, bo w demku 69 Positions też jest tak samo.

Sam program wydaje się działać poprawnie, bo po wyjściu z decrunchera te modyfikowane komórki są ustawione na $7802 ale rzeczywiście coś z tym plikiem jest nie tak. Spróbowałem sobie z inną bitmapą i te "szumy" na ekranie są inne więc coś tam czyta tylko albo tak jak mówisz - coś może z tą kolejnością jednak jest nie tak albo jeszcze czymś innym.

Tam jeszcze trzeba ustawić tę modyfikowaną w trakcie pracy decrunchera wartość bajtów byte_lo i byte_hi (get_crunched_byte+$0f i get_crunched_byte+$10 gdzie get_crunched_byte jest pod $9300 właśnie), z których właśnie pobierane są bajty (LDA xx) ale nie wiem jak to ustawić, wpisując koniec bitmapy (albo coś na około tego +/- 1) efekt jest ten sam, tzn. dane pod $e000 są identyczne we wszystkich przypadkach, mogę tam nawet wpisać $ffff.

Kisiel
Człowiek się uczy całe życie. Spróbowałem z Exomizerem całkiem eksperymentalnie, po nieudanych próbach postanowiłem poradzić się ekspertów. Moje boje z okiełznaniem Exomizera co prawda nie zakończyły się powodzeniem, ale dzięki temu, że zacząłem analizować ten kod nauczyłem się świetnej metody automodyfikacji kodu, o której słyszałem wcześniej ale nie miałem okazji tego w żaden sposób wykorzystać. Od razu zastosowałem to do kopiera bloków z określonego miejsca na bitmapę. Nie jest to pewnie demon prędkości, ale zmieściłem to schludnie w takim miejscu, że nie nachodzi mi na następne przerwanie więc do animacji określonych miejsc na bitmapie się nadaje.

Odnośnie proponowanych level packerów wielkie dzięki, przepatrzę to w wolnym czasie i na tym się skupię rzeczywiście. Nie mam żadnego doświadczenia co do rozpakowywania, czasów, oszczędności miejsca etc. bo i skąd - dlatego też posłuchałem starszego kolegi i się zastosuję. Z Exomizerem nie chcę sobie odpuszczać dla nieuzasadnionej satysfakcji gdyby się w końcu udało, ale naturalne, że odłożę ten temat z braku czasu.

[Skull]

BagoZonde:

Korzystam ze źródłówki demka 69 Positions. Jest tam użyte literal z tego co widzę i używając opcji -l ten literal jest włączony. Dołączony jest też do tej źródłówki demka sam execute exomizera (wersja 1.1.5).Przypomnę, że zexomizerowałem to tak: exomizer -l$e000 bitmap.bb -obitmap.exo

Po pierwsze po jaką chol.. używasz cząstki kodu ze "środka" jakiejś produkcji, skoro wczystko jest dostępne po sciagnięciu exomizera.
Tu masz najnowszą wersję:
http://noname.c64.org/csdb/release/?id=101673

po pierwsze takie "kawałki" od innych są często specjalnie okrojone pod potrzeby tylko tej jednej produkcji,
po drugie nawet gdybym miał to teraz dla Ciebie sprawdzić to muszę niewiadomo czego teraz szukać.

w tym co podałem w linku plik spakownym w zipie - w środku w katalaogu exodecrs\dasm jest źródłówka do wykorzystania we własnym kodzie - i nie 69 positions - tylko od "producenta", a więc uniwersalna i musi działać.

w niej znajdujemy:
; if literal sequences is not used (the data was crunched with the -c
; flag) then the following line can be uncommented for shorter code.
;EXOD_LITERAL_SEQUENCES_NOT_USED = 1

i teraz tak:
opcja -l to nie "literal sequences" a adres LOADING dla spakowanego pliku exomizerem
dlatego dwa pierwsze Twoje bajty to własnie $e0 00 (a jakie mają być ? przecież sam wpisałeś -l$e000)

Ja pisałem o dwóch KOŃCOWYCH bajtach i one NIE pokazują exomizerowi POCZĄTKU BITMAPY tylko właśnie KONIEC bitmapy czyli prawdopodobnie $ff 3f - pisałem też, że exom depakowuje od końca to dziwne byłoby gdyby brał sie za pierwsze bajty ($e000).

Wracając do literal... tu, dobra wiadomość - skoro jest to exom w wersji 1.x to jeszcze z nich nie korzysta, a więc ten problem wogóle odpada (ale dowiedziałem się dopiero o tym z Twego ostatniego postu),

błędy w depaku moga wynikać z np. nakładania się tych samych zmiennych ze STRONY ZEROWEJ z innymi Twoimi procedurami (np. MUZYCZKA może korzystać z tych samych - a jak działa w tle to sam rozumiesz co się może dziać), ale nadal nie widzę tego Twego sourca więc można tak strzelać do usr. śmierci.


Przyjedz na party,  myslę że szybciej się dogadamy.


ps. sorry ale nie mam czasu aż na takie opracowania w postach....