@xxl: A czym tego PackFire można kompresować na PC? Najfajniej gdyby było na unixoidy.
niewiedza buduje, wiedza rujnuje
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Programowanie - 8 bit » Najlepszy Packer dla Atari
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
@xxl: A czym tego PackFire można kompresować na PC? Najfajniej gdyby było na unixoidy.
pod koniec strony masz linki do binarek - windows na pewno
ZX02
$ zx02 infile outfile
7680 conan.gfx
1629 conan.gfx.zx02
30653 Landscape.xex
13546 Landscape.xex.zx02
8192 RiverRaid.rom
6312 RiverRaid.rom.zx02
@xxl, fajnie byłoby, gdybyś do każdego kompresora np. robił taką binarkę, co dekompresuje Conan.img. Wtedy widać, ile zajmuje i jak szybko działa. I np. wypisać wynik w ilości scanlines po naciśnięciu przycisku.
Jak już się ma 20 dekompresorów - to kluczowe jest jak wybrać ten idealny do potrzeb.
Dodałbym do takiego zestawienia jeszcze ile zajmuje kod dekompresora i BUFORY potrzebne do działania algorytmu. Bo czasem się okazuje, że dekompresor jest krótki i ładny, ale za to wymaga 13 stron na bufory... I cały zysk z dobrej kompresji idzie w maliny.
I czy da się wyjmować bajt po bajcie, czy trzeba mieć miejsce na cały zdekompresowany blok. I czy dekompresowany blok się może nadpisywać, i czy wprzód czy nazad :)
to do dzieła... macie tyle dobrych pomysłów
@tebe - to głównie xxl robi te dekompresory - więc najlepiej by było, gdyby on to zrobił, wtedy będzie w jednym miejscu i spójnie. Co z tego, że ktoś inny to zrobi, jak zniknie to w bezmiarach internetu.
przeciez wszystko jest na stronie np: https://xxl.atari.pl/zx0-decompressor/
najmocniejszy jest shrinkler ktory miazdzy konkurencje, wymagania ma ale rozsadne, bufor mozna umiescic np. w pamieci ekranu... poza tym pare dni temu wyszla nowa wersja kompresora :D
pozostale tez maja podane wymagania i przyklady uzycia... obecnie proponuje zerknac na ZX0 i ZX5 - krotkie i bez bufora poza tym bardzo dobra kompresja i szybki dekompresor.
jesli ktos faktycznie walczy o bajty to i tak musi wykonac probe ktory kompresor jest najlepszy dla jego danych...
wszystkie te dekompresory moga dekompresowac z pamieci ale lepszym rozwiazaniem jest dekompresja z pliku albo z ramdysku... przestaje miec znaczenie dekompresja w przod czy w tyl... mozna tez rozwazyc dekompresje ze wspolnym slownikiem dla kilku plikow... sa rozne pomysly... zwracalbym tez uwage na dekompresowy ktore nie musza miec podanych ilosci danych do dekompresji - te wydaja mi sie kompletne.
to do dzieła... macie tyle dobrych pomysłów
Ja to mogę się podzielić swoim Makefilem który zrobiłem do automatycznego generowania skompresowanych pliczków, co ułatwiło mi dobór kompresora do moich potrzeb.
Żeby dodać nowy kompresor trzeba:
1. Zdefiniować kompresor i rozszerzenie (jak poniżej zx02 i .zx02)
ZX02 = zx02
ZX02S = $(SOURCES:=.zx02)
2. Zdefiniować reguły dla nowego kompresora (zx02) i skompresowanych plików (%.zx02)
zx02: $(ZX02S)
%.zx02: %
$(ZX02) $< $@
3. Dodać nowy kompresor (zx02) do .PHONY, all i clean:
all: exomizer2 exomizer3 chrust shrinkler bitbusterx deflater zx02 aplib packfiretinyw packfirelargew
clean:
$(RM) $(EXO2S) $(EXO3S) $(CHRS) $(SHRS) $(BBXS) $(DFLS) $(ZX02S) $(APLS) $(PFTS) $(PFLS)
.PHONY: all clean exomizer2 exomizer3 chrust shrinkler bitbusterx deflater zx02 aplib packfiretinyw packfirelargew
Trzeba do tego mieć pliczki do skompresowania:
SOURCES = conan.gfx Landscape.xex RiverRaid.rom
no i poinstalowane kompresory:
- exomizer
- exomizer3
- chrust
- shrinkler
- bitbuster_extreme
- PackFire
- deflater
- zx0
- zx02
- zx5
- zx7mini
- appack
- arj
- lz4
Edit: Uzupełniłem plik o wszystkie packery które są na stronie xxla. A poniżej wyniki:
7680 conan.gfx
1739 conan.gfx.apl
2107 conan.gfx.arj
1770 conan.gfx.bbx
1893 conan.gfx.chr
1671 conan.gfx.dfl
1566 conan.gfx.ex2
1561 conan.gfx.ex3
2232 conan.gfx.lz4
1452 conan.gfx.pfl
1581 conan.gfx.pft
1440 conan.gfx.shr
1625 conan.gfx.zx0
1629 conan.gfx.zx02
1532 conan.gfx.zx5
1864 conan.gfx.zx7
30653 Landscape.xex
14028 Landscape.xex.apl
15949 Landscape.xex.arj
14587 Landscape.xex.bbx
14529 Landscape.xex.chr
14491 Landscape.xex.dfl
13771 Landscape.xex.ex2
13604 Landscape.xex.ex3
16983 Landscape.xex.lz4
12761 Landscape.xex.pfl
13823 Landscape.xex.pft
12921 Landscape.xex.shr
13530 Landscape.xex.zx0
13546 Landscape.xex.zx02
13459 Landscape.xex.zx5
15769 Landscape.xex.zx7
8192 RiverRaid.rom
6440 RiverRaid.rom.apl
7293 RiverRaid.rom.arj
6614 RiverRaid.rom.bbx
6525 RiverRaid.rom.chr
6292 RiverRaid.rom.dfl
6284 RiverRaid.rom.ex2
6199 RiverRaid.rom.ex3
7419 RiverRaid.rom.lz4
6006 RiverRaid.rom.pfl
6284 RiverRaid.rom.pft
6068 RiverRaid.rom.shr
6313 RiverRaid.rom.zx0
6312 RiverRaid.rom.zx02
6334 RiverRaid.rom.zx5
7156 RiverRaid.rom.zx7
conan spakowany exomizerem 2.0.6. Rozpakowuje się domyślnie od końca, czyli można ładować niemal w miejsce docelowe, kilka bajtów niżej i lecieć z dekompresją. Natomiast nie jest tak szybki jak zx5, a to jeden z najszybszych dekompresorów.
Za to kompresuje z 5 minut te 8K. Szkoda że nie potrafi milionem rdzeni.
Exo do kilobajtów jest git. A jaki masz komputer???? :P U mnie kompresuje sekundę conana. Fakt, że w przeliczeniu na bajt jest to wolno, ale do przełknięcia.
Asus ROG STRIX SCAR 2. Ale widzę że wszystko jedzie na jednym rdzeniu. Mówię o zx5. Exomizer śmiga.
Zawsze miałem problem z linią wywołań exomizera, więc nie wiem.
A co myślisz o tym:
ZX1 is a simpler but faster version of ZX0 that sacrifices about 1.5% compression to run about 15% faster.
https://github.com/einar-saukas/ZX1
W sumie jak jest zx0 to zx1 będzie łatwo. W sumie w grze niemal zawsze chodzi o szybkość, więc może warto.
jak to jest z tym exo? trzeba podawac podczas kompresji adresy pamieci gdzie maja byc dane dekompresowane?
On tam ma kilka trybów pracy - z grubsza:
- sfx - selft-extract generuje xexa który rozpakowuje się na siebie
- mem - do rozpakowania w konkretnej lokacji pamięci - wtedy adres docelowy zaszyty jest w wyniku
- raw - do dekopresji gdziekolwiek - również dekompresji strumieniowej
$ exomizer raw -c -o file.exo file
Parametrem -m można określić jeszcze wielkość bufora jakiego dekompresor będzie używał - ma to wpływ na wielkość wyniku
w tabelce jest wynik wersji raw? a jak to wyglada dla bufora 1 bajtowego? czy ten dekompresor musi miec podana ilosc danych do dekompresji albo adres koncowy?
tak dopytuje bo juz nie pamietam ale kilka razy probowalem sie przekonac do exo i za kazdym razem cos mi nie gralo i za kazdym razem inne ograniczenie. zreszta jego wniki sa takie ze raczej do devloperki to bym go nie uzyl ;-)
exomizer jest już w wersji 3.1.1, używacie starych programów
https://bitbucket.org/magli143/exomizer/wiki/Home
exomizer jest już w wersji 3.1.1, używacie starych programów
Poniekąd, ponieważ do nowej wersji nie ma jeszcze dekompresora strumieniowego. Do innych celów używamy nowego, dlatego w mojej liście masz dwa exomizery.
w tabelce jest wynik wersji raw?
%.ex2: %
$(EXO2) mem -f -l none -o $@ $<@0x4000
%.ex3: %
$(EXO3) mem -f -l none -o $@ $<@0x4000
Zachęcam do eksperymentowania.
a jak to wyglada dla bufora 1 bajtowego?
Nie sprawdzałem, ale rozmiar bufora dla exostreamdecr1.s podaje się w pełnych stronach i dla moich celów dobrze działa $300 - mniejsze generowały już nieakceptowalny wynik.
czy ten dekompresor musi miec podana ilosc danych do dekompresji albo adres koncowy?
Nic mi o tym nie wiadomo.
Exomizer3 ma za to ciekawą opcję - umożliwa wygenerowanie jednego ciągu enkodującego dla całej grupy plików (parametry -E i e) co pozwala usunąć tenże ciąg z danych skompresowanych. To jest kilkadziesiąt bajtów, ale jeśli mamy kilkadziesiąt skompresowanych pliczków to już robi się z tego kilka czy kilkanaście stron. Wtedy przed dekompresją każdorazowo inicjalizuje się bufor dekompresji tymże ciągiem kodującym, po czym odpala się już docelową dekompresję.
Nie zawsze się to oczywiście opłaca, ale to kwestia sprawdzenia co będzie mniejsze.
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » Najlepszy Packer dla Atari
Wygenerowano w 0.027 sekund, wykonano 70 zapytań