Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormarok
   • CommentTime21 Oct 2024 13:10

    
   … o kompresji danych,
   
   W pierwszym wpisie tu, nawiązanie do wątku z "siostrzanego" forum: ->link<-
   
   Bo brakowało wyników pakowania plików zasadniczo atarowskimi pakerami (poza FlashPakerem).
   
   Tylko z tych pakerów, które udało mi się obsłużyć.
   
   
   Wyniki dla plików w tej kolejności:
   

   conan.gfx
     riverraid.rom
     GPL30.txt
     
   "Kompresor Bitowy"
    2272
    7459
   19377
   
   "Packer Jaskiera v2" (uniwersalna)
    2493
    6900
   14815
   
   "SuperARC!" (crunching | packing)
    2014 |  2814 (crunching)
    7918 |   -   (packing)
   17128 | 34954 (crunching)
   
   "LZWarch"
    2154
     -   (8226)
   17141
   
   "Super Packer"
    2135
    7148
   15237 (wynik odp. pakowanemu plikowi okrojonemu do wielkości bufora programu $78E8)
   
2. • 2: CommentAuthormarok
   • CommentTime21 Oct 2024 14:10 zmieniony

    
   wyniki pakowania na odrobinę różnych wersjach pliku - wersje:
   (conan.gfx)
   conan.shr1.gfx
   conan.shr2.gfx
   conan.xorFF.gfx
   
   (rozwinięcia nazw powinny być czytelne - chodzi o przesunięcia o bit / 2 bity i xor#FF wszystkich danych traktowanych łącznie - chodzi mi w tym ost. dopow. o przesunięcia bitów)
   
   

   "7z"
   (1526)
    1550
    1548
    1523
   
   "ZX0"
   (1625)
    1637
    1635
    1625
   
   "Kompresor Bitowy":
   (2272)
    2316
    2294
    2375
   

   
   
   
   W moim (zbyt) prostym założeniu format ZX0 powinien pakować wszystkie wersje xor (np. xorFF) identycznie do oryginału (z różnicą tylko tych pozycji, gdzie zawsze tylko całe bajty są danymi "literals" w depakingu).
   
   Okazuje się, że przynajmniej wersja pakera do ZX0 "Salvador" podchodzi do tych plików alternatywnie, co ciężko przychodzi mi zrozumieć. Nawet pomimo pozornie identycznego wyniku pakowania pakuje mniej wydajnie sam plik "conan.gfx" do wesji "xorFF", o pół bajta (7z, jak można odczytać, też mi spakował tą wersję wydajniej - o 3 bajty).
   
   conan.gfx.zx0
   0000 0652: 20 57 21 80 5D 55 56
   conan.xorFF.gfx.zx0
   0000 0652: 20 72 80 15 D5 55 60
3. • 3: CommentAuthorsolo/ng
   • CommentTime21 Oct 2024 18:10 zmieniony

    
   troche offtop, ale moze przyda sie komus info. Na potrzeby Rewind 2 zrobilem dosc spory empiryczny research, szukajac zlotego srodka dla 6502+demo (pod gry mozna przesunac troche wajche) i ZX0 okazal sie najlepszym wyborem. Kompresja (dla wiekszosci danych) na poziomie deflate, depack 300% szybszy (na 6502).
   
   Znajde czas, postaram sie (ciagle chodzi po glowie) udostepnic taki plug&play stuff, pakujemy, w kodzie robimy lda #skad sta #gdzie jsr #zrob i nic nie interesuje. Jest tez wersja podkrecona (~30%) przez Swietego, ale wymaga 240 bajtow na zerowej.
   
   sorry za maly offtop, ale ZX0 itd
4. • 4: CommentAuthormarok
   • CommentTime21 Oct 2024 20:10

    
   bardzo pasuje, że takie info się tutaj pojawia
   
   nawet takie rzeczy praktyczne i pewne ciekawostki to coś, o co może powinno w tym wątku chodzić, w kontekście właśnie pakowania danych
   
   pewnie wiadomo, ale jest też ZX02 (lepiej pasujący pod 6502) i tutaj zadziałał już jakoś Fox
   
   też mi się wydawało (bardziej może intuicyjnie), że ZX0 może być celnym wyborem do zastosowań
   
   a istnieje pewne podobieństwo podejścia do "literals" (piszę w uproszczeniu, bo sam nawet nie wiem, jak to wyartykułować najlepiej) jak we FlashPacku w ZX0.
5. • 5: CommentAuthor0xF
   • CommentTime21 Oct 2024 20:10

    
   Ja też napisałem swoją procedurę ZX0. Kompresja jest wyraźnie słabsza od DEFLATE (szczególnie dla krótkich plików i długich tekstów), ale szybko się rozpakowuje. Niefortunny dla długości procedury 6502 jest domyślny pierwszy offset -1 - ja zmodyfikowałem paker, żeby z niego nie korzystał.
   
   Jest jeszcze ->link<- do którego wrzuciłem kilka PRów.
6. • 6: CommentAuthormarok
   • CommentTime21 Oct 2024 22:10

    
   Znaczy, pisząc o podobieństwie podejścia pakerów do "literals" miałem na myśli to, że zawsze 'udaje się' taki bajt danych zmieścić w 8 bitach tego samego bajta archiwum. Przez co odpada konieczność rolowania przy ich wyodrębnianiu z archiwum, co chyba stanowi różnicę do większości pakerów, więc tutaj zyskują przewagę w szybkości rozpakowywania danych (FP działa wyróżniająco się szybko, więc to nie jedyny zasadniczy powod, w jego akurat przypadku).
   
   
   Mnie nurtuje w tym momencie problem tej natury, że wydaje się, iż większość pakerów, jeśli nie praktycznie wszystkie, działa w oparciu o traktowanie danych nie jako niezależnego strumienia bitów, ale niejako jako dane (bitowe) przypisane do pozycji względem siatki podziału na bajty (tak jak je podane mamy w archiwum).
   Odniesieniem jest zawartość bajta, może gdzie indziej jakieś inne "porcje" (12 bitowe? - mętnie coś kojarzę z tym "upr"), ale do ściśle bitowego pakowania jakoś kojarzę tylko w zastosowaniu RLE (w grze TeBe).
   
   To trochę jak przy wysoko 2^n bitowych procesorach (takie moje "autorskie" skojarzenie), które nie tolerują / nie pozwalają (coś, gdziś zasłyszałem, myślę że nie przekręcam) na inny dostęp do pamięci niż w ściśle określonej podziałce liczonej od początku adresowania pamięci (tylko lokalizacja parzysta, czy jakoś tam inaczej).
   
   Więc zastanawiam się nad pakerem, który by był może w tym względzie taki bardziej odpowiedni do np. grafik gr8, albo po prostu zwyczajnie inny pod tym względem.
   
   Bo możemy przyjąć, że dla określonych wielkości danych (które by nas interesowały) podlegających pakowaniu takie sztywne poszatkowanie danych do wielkości bajta to optimum z punktu widzenia efektywności. A być może dla wyższych wielkości danych (liczonych w megabajtach) byłaby to już większa "porcja" bitów (ale zawsze jakaś tam już "porcja").
   W każdym razie nie jest to dla mnie jasne, czy mamy pewność, że traktowanie danych w podziałce na bajty (co jest akurat naturalne) jest z kolei najefektywniejsze w osiąganych rezultatach stopnia upakowania. Z pewnością powinno być najszybsze, bo niejako wkomponowuje się w architekturę (tą naturalność).
7. • 7: CommentAuthormarok
   • CommentTime22 Oct 2024 10:10

    
   Znalazłem teraz jeszcze, że pod nazwą pakowania bitowego opisane są różne warianty metody redukcji potrzebnych bitów do wyrażania liczb pierwotnie zapisanych 32-bitowo (o przeciętnie stosunkowo niedużych wartościach i generalnie "unsigned"). Chodzi w niej o to, że redukuje się pierwszy napotkany ciąg bitów %0, niekoniecznie w całości, (od najstarszego bitu patrząc) 32-bitowo wyrażonej liczby (i tą liczbę zredukowanych bitów różnie w zależności od wariantu, zapamiętuje).
   
   (Ma to praktyczne zastosowanie do procesorów co najmniej 32-bitowych.)
   
   ->link<-