Autor Wątek: On-the-fly Screen Compressor  (Przeczytany 22966 razy)

Phonex

  • *****
  • Wiadomości: 1278
  • Miejsce pobytu:
    Warszawa
Odp: On-the-fly Screen Compressor
« Odpowiedź #15 dnia: 2024.09.05, 17:48:19 »
Challenge accepted!


Żartuję.
Kompresowanie "po skosie" nie poprawia efektywności. Kompresowanie kolumnami tak, bo często z boków centralnej części obrazka są pustki, więc i 192+ bajty "0" kolejno. Po skosie to się nie zdarzy. Więc nie ma sensu. Kompresory napisałem, żeby skracać obrazki, bo drażniło mnie że na dyskietkę wchodzą często tylko 3 gry i zostaje dużo miejsca. I wydawało mi się, że zrobię lepsze niż istniejący (był wtedy kompresor z zestawu Artist II). I to mi się (za drugim razem) udało.
A co to jest "taniec wężyka"? Używana często przez Billa Gilberta "spiralka" ze wskazywaniem położenia bajtów?
To całkiem odpada, bo wydłuża, ale można by się zastanowić nad prawdziwą spiralą - od zewnątrz do środka. Kolumny na zmianę z wierszami - możliwe że wyjdzie wynik lepszy od pierwszej wersji on-the-fly. Ale gorszy od drugiej, bo ich długość się zmiejsza, więc zmniejsza się ilość potencjalnie powtarzających się bajtów. Czyli też nie będzie lepsze - więc nie ma motywacji. Tym bardziej że tylko kilka osób będzie używać (siedmiu ściągnęło pierwszą wersję), czy też użyje raz-czy-dwa, bo przecież nikt nie będzie przerabiał wszystkich posiadanych gier (jak ja robiłem kiedyś, żeby oszczędzić miejsce na dyskietkach, najpierw pierwszym potem drugim kompresorem). 


No dobrze, może jak nie będę miał co robić, to spirala kiedyś, ewentualnie...
I bajer będzie jeszcze lepszy ;) Ale dekompresor będzie dłuższy o kolejne 60(?) bajtów.

Ach! I może też zamiast każdą kolumnę z góry na dół, to na zmianę: w dół - w górę - w dół...
Byłby więc plan pracy na kolejne 10 lat ;)
Tylko motywacja jednak jest słaba, bo to nie jest już tak rewolucyjna zmiana jak poprzednie...

I jest jeszcze ten pomysł, który wynikł w trakcie - żeby wczytywać jeden rekord: x bajtów skompresowanych pixeli, po czym x/8 skompresowanych atrybutów. To by umożliwiło rozpoczęcie wyświetlania znów od początku, ale będzie strasznie trudne - bo przecież atrybuty niekoniecznie będą się tak samo kompresować jak piksele, a poza tym jak to zrobić, kiedy x będzie niepodzielne przez 8 np. równe 11?
Prowokatorze! Jest jeszcze jedna rzecz do zrobienia, żeby skrócić: zachowując sposób wyświetlania tak jak jest - atrybuty też kompresować kolumnami.
To już 15 lat :P

A właściwie dlaczego po 5 lat na etap? Czy znowu będzie jakaś epidemia?

Thompson

  • *
  • Wiadomości: 34
Odp: On-the-fly Screen Compressor
« Odpowiedź #16 dnia: 2024.09.18, 21:41:19 »
W przypadku kompresji atrybutów można wykorzystać fakt, że bit 7, czyli flash jest wykorzystywany stosunkowo rzadko, więc zwykle ma wartość 0. Dałoby to max 12% oszczędności na 768 bajtach, czyli maks 92 bajty - z pewnością kosztem długości i komplikacji dekompresora.
Być może idąc tym tropem, ale to wymagałoby terenowych badań organoleptycznych, podobny zabieg możliwy byłby dla 6 bitu (bright), choć raczej już nie w tej skali. Intuicyjnie wydaje się, że raczej nie, bo pozwala on zwiększyć nieco paletę kolorów, więc artyści powinni z niego korzystać. Ale jak to z intuicją bywa, może być złudna i wszystko zależy od statystyk pojawiania się tego bitu na jakieś reprezentatywnej próbie screenów.

Phonex

  • *****
  • Wiadomości: 1278
  • Miejsce pobytu:
    Warszawa
Odp: On-the-fly Screen Compressor
« Odpowiedź #17 dnia: 2024.09.21, 14:19:28 »
Kuszące :)
Byłaby szansa na lepszy wynik. To mi przypomniało, że w roku 20xx przeglądając CD z programami na ZX, które dostałem, znalazłem "Screen Compressor plus". Okazało się, że ktoś (chyba Mikropol OIDP) napisał lepszy kompresor  >:(. Teraz miałbym szanse go przebić. I nieważne że już się nie przyda...
Myślałem o tym 7 bicie przez 5 minut, kiedy kombinowałem co zrobić z atrybutami w wersji 2, ale porzuciłem.
96 bajtów zysku, to niestety tylko w przypadku braku kompresji. Jeżeli kompresji podlega sumarycznie 50% atrybutów (prawdopodobne) - to zysk spada do 48 bajtów + to co wynika z kompresji. Uwzględniając konieczność wydłużenia dekompresora - może wyjść na zero. Bajty nieskompresowane są przeplatane skompresowanymi, więc wszystkie musiały by być "siedmiobitowe", żeby skrócić. Trzeba by nie tylko zmienić znacznik - jest szukany od końca, więc najczęściej ma 7 bit "1", ale też licznik, więc np. liczyłby nie do 63, a do 31. Przy kompresowaniu atrybutów kolumnami może się to sprawdzić, ale robienie odrębnych zasad znów wydłuży program...
Oczywiście można zrobić wielowariantowy kompresor - próbować z takim i innym licznikiem, ze skróconym kodowaniem 1 lub 2 najpopularniejszych bajtów, skanowaniem atrybutów kolumnami lub liniowo - skoro dekompresor jest dołączany to może być za każdym razem inny, ale to chyba "too much".
Można by też uwzględnić bit 6 - sprawdzić czy występuje i wtedy zastosować odpowiednią metodę, ale chyba nie warto. Chyba masz rację, że wystąpi w 99% przypadków.

Więc plan jest taki: atrybuty kolumnami i zobaczyć czy wyszło lepiej  ;)

A przy okazji bitu 6: załączam obrazek Stawickiego z Vulcan, z ujawnionym BRIGHT na całym obszarze (w pixele wpisane 255 tam gdzie było 0 i 0 w pozostałe).
Kratka z edytora została!
Co oczywiście nie ma znaczenia, bo normalnie nie widać, ale psuje kompresję (no bo 0100 0111 nie równa się 0000 0111). Ciekawe, czy w innych obrazkach też?
« Ostatnia zmiana: 2024.09.21, 14:31:07 wysłana przez Phonex »

galaxian

  • ***
  • Wiadomości: 213
Odp: On-the-fly Screen Compressor
« Odpowiedź #18 dnia: 2024.09.28, 13:02:02 »
A co to jest "taniec wężyka"? Używana często przez Billa Gilberta "spiralka" ze wskazywaniem położenia bajtów?

Właśnie słowa "spiralka" mi zabrakło :)

A właściwie dlaczego po 5 lat na etap? Czy znowu będzie jakaś epidemia?

Poprzedni "update" tyle trwał, ale jeśli kolejny będzie krótszy, to tylko lepiej dla wszystkich :)

"Screen Compressor plus". Okazało się, że ktoś (chyba Mikropol OIDP) napisał lepszy kompresor  >:(. Teraz miałbym szanse go przebić. I nieważne że już się nie przyda...

Ostatnio używałem, więc na pewno się przyda :)
Ten Mikropola kompresuje czterema algorytmami i wybierany jest najlepszy.
« Ostatnia zmiana: 2024.09.28, 13:10:00 wysłana przez galaxian »
ZX Spectrum 48kB / ZX Spectrum+ / ZX Spectrum 128 +2 / Timex 2048 / Atari 800XL / Atari 65XE / Atari 130XE / Atari 800XE / Atari 1040 STF / Commodore 64C / Commodore 64G / Amiga 500 / Amiga 500+ / Amiga 600 / Amiga 1200 / Amiga 1200 Magic

Phonex

  • *****
  • Wiadomości: 1278
  • Miejsce pobytu:
    Warszawa
Odp: On-the-fly Screen Compressor
« Odpowiedź #19 dnia: 2024.10.12, 15:03:25 »
Odnalazłem kompresor Mikropola i hmmm... nie całkiem jest tak jak zapamiętałem. Sprawdziłem na 43 obrazkach - jest lepszy tylko w 4 przypadkach. To mniej niż 10%. Lepszy o małe ilości: 10, 31, 34, 44 bajtów. Więc to zapamiętane "lepszy" dotyczy: szybszy dekompresor i więcej opcji ładowania, a kompresja słaba. A cztery metody? Na te 43 gry zawsze wybierał metodę 1. W końcu sprawdziłem go na obrazku, który chyba jako jedyny kompresuje się lepiej FAST compressorem (liniowo): Legend of Kage. I rzeczywiście - tu wybrał metodę 4, ale również wyszło gorzej od mojego. Więc niepotrzebnie uniosłem się ambicją - mój w 90% jest lepszy, a jak zrobię kompresję atrybutów kolumnami to pewnie  w 100%  8)
Przy okazji znalazłem w moich grach "zdyskowanych" obrazki skompresowane niby TOP compressorem, ale z inną długością  :o Okazało się że poprzednią wersją TOP compressora - już nawet zapomniałem, że była. Historia kompresorów jest, jak się okazuje, dłuższa niż myślałem ;) Skoro ta co mam oznaczona jest "V0.8", to tamta była pewnie "V0.5". Różni się trochę sposobem obliczania następnego adresu, ale głównie brakiem drugiego najczęstszego bajtu, który jest zapisywany na dwóch bajtach kodu wynikowego. I np. dla "Bomb Jack" różnica wynosi 111 bajtów. To tylko 2%, ale pozwoliło pokonać Mikropola ;) Top_v0.5: 4859, Mikropol:4756, Top_v0.8:4748.
Dlaczego zostały stare wersje na dyskietce, chociaż są dłuższe? Bo zajmowały tyle samo jednostek alokacji co nowe (TOP compressor podaje tą informację, i również odczytuje z dysku "starą" wartość), więc zastępowanie można sobie darować.

A w obrazku z Vulcan, po optymalizacji (usunięciu kratki BRIGHT), atrybuty skróciły się o o 1/3, czyli o 215 bajtów - z 649 do 434! Czyli współczynnik kompresji atrybutów wzrósł z 15% do 43%, a całości (z uzględnieniem kompresora TOP) z 49% do 53%.
Najwyższy współczynnik kompresji atrybutów występuje oczywiście w obrazku z Yabba-dabba-dooo! To 95% - tam jest jeden kolor ;)

Thompson

  • *
  • Wiadomości: 34
Odp: On-the-fly Screen Compressor
« Odpowiedź #20 dnia: 2024.10.26, 22:33:22 »
Phonex, możesz mi proszę podesłać (PM) owe kilkadziesiąt screen'ów do testów alternatywnych metod kompresji. Wydaje mi się, że dane bitowe ZX Spectrum + atrybuty są na tyle specyficzne, że proste metody mogą przewyższyć te "wery sofistikejted".

Phonex

  • *****
  • Wiadomości: 1278
  • Miejsce pobytu:
    Warszawa
Odp: On-the-fly Screen Compressor
« Odpowiedź #21 dnia: 2024.11.11, 17:15:26 »
Testowałem na screenach z gier, które mam na dyskach. Nie mogę wysłać (problem techniczny). Jeśli koniecznie chcesz moje, to fani Billa mają kilka https://spectrum4ever.org/fulltape.php?go=releases&id=191&by=cracker.
Nawet pokazują, czy jest obrazek czy nie (pomijając: jest obrazek=brak tytułu/ramki z podpisem).

Thompson

  • *
  • Wiadomości: 34
Odp: On-the-fly Screen Compressor
« Odpowiedź #22 dnia: 2024.11.20, 19:24:35 »
Dziękuję. Co prawda dopracowałem się własnego wydłubywacza screenów z TAPów, co jest przecież banalne, i buduję sobie własną bibliotekę obrazków, ale nigdy dość...

galaxian

  • ***
  • Wiadomości: 213
Odp: On-the-fly Screen Compressor
« Odpowiedź #23 dnia: 2024.11.23, 10:01:37 »
Plugin do Total Commandera i możesz wydłubywać do woli.
TC traktuje wtedy pliki TAP jako archiwum.
ZX Spectrum 48kB / ZX Spectrum+ / ZX Spectrum 128 +2 / Timex 2048 / Atari 800XL / Atari 65XE / Atari 130XE / Atari 800XE / Atari 1040 STF / Commodore 64C / Commodore 64G / Amiga 500 / Amiga 500+ / Amiga 600 / Amiga 1200 / Amiga 1200 Magic