Nie jestem pewien do jakiego działu to pasuje, bo to trochę interdyscyplinarne, ale lecim...
Kiełkowała mi od kilku lat idea zrobienia alternatywnego rdzenia do VBXE, który byłby bardziej dostosowany do typowych wyzwań stawianych przez gry i wygląda na to, że projekt ma szansę na materializację przy wielkiej i nieocenionej pomocy MatGuru.
Pod pojęciem "bardziej dostosowany do typowych wyzwań stawianych przez gry" rozumiem "coś mniej więcej jak zrobili w Atari Lynx". A w szczególności chcę wzorować się na lynksowym blitterze, którego principia działania nie polegają na przepuszczaniu pamięci przez operacje logiczne (tak jak działa to w klasycznym blitterze rodem z Amigi, Atari ST i w rezultacie też takim jaki został zaimplementowany w VBXE), lecz raczej... na rysowaniu sprajtów na ekranie. Nie jest to teraz miejsce na zgłębianie ogólnych mechanizmów działania tego blittera, zainteresowanych mogę odesłać do dokumentacji. Mnie teraz w szczególności interesuje jeden jego aspekt, a jest nim schemat kompresji grafiki zastosowany w ustrukturyzowanych danych lynksowego sprajta.
Przygotowałem uproszczony (wyrzuciłem rzeczy, które nie są teraz istotne) schemat struktury danych sprajta:
Nigdzie w strukturze sprajta nie jest zadeklarowana jego szerokość, ani wysokość, lecz jest on strukturalnie podzielony na wiersze, nagłówek wiersza jest offsetem do następnego wiersza, offset = 0 oznacza koniec sprajta. Pomiędzy offsetami są dane wiersza, które są podzielone na pakiety. Pakiet składa się z 5-bitowego nagłówka - 1 bit na wyznacznik, czy dane są literalne (1), czy powtórzone (0) oraz 4 bitów długości pakietu (N). W przypadku danych literalnych zawartość pakietu to dane N pikseli, w przypadku danych spakowanych jest to jeden piksel, który ma być powtórzony N razy. Czyli dość klasyczne RLE.
Dekompresor tego jest zrealizowany sprzętowo i też tak samo "sprzętowo" (w FPGA) będzie musiało to być zrealizowane w VBXE. Zagadnienie z jakim się zwracam na forum to:
Czy można wymyślić coś o lepszym stopniu kompresji, co nie byłoby trudne do implementacji w FPGA?
Nie muszę robić wiernej kopii rozwiązania z Lynksa, bo nie zależy mi na kompatybilności 1:1, np już uprościłem sobie strukturę ustalając na sztywno liczbę bitów na piksel do 4. Nie chciałbym wychodzić poza RLE - rozwiązania słownikowe wydają się zbyt skomplikowane. No chyba że ktoś uzasadni, że jakieś "LZ" byłoby do zrobienia i miałoby sens.
Na takie pomysły zmian wpadałem do tej pory:
* Można w strukturze opisu sprajta zawrzeć liczbę bitów do kodowania długości pakietu (w Lynksie jest to zawsze 4).
* Można liczbę bitów długości pakietu kodować per wiersz (np na trzech bitach od 0 do 7)
* A może w strukturze opisu sprajta zawrzeć liczbę pakietów, co ile ustalane byłoby ile bitów ma długość pakietu? Może pozbyć się wyznacznika literal/repeated?
Ogólnie ja nie wiem, czy można wymyślić coś lepszego, co dalej byłoby RLE. Pomysły i tak trzeba byłoby jakoś empiryczne zbadać na jakichś danych testowych. Zaznaczę tylko, że przeznaczeniem tej kompresji byłoby pakowanie 16-kolorowych sprajtów, które kodują przezroczystość na kolorze 0 i zwykle nie są jakoś bardzo duże. Maksymalny sensowny rozmiar, to 336 pikseli szerokości ekranu i każdy wiersz sprajta rozpatrujemy osobno jako niezależnie kompresowany ciąg.
Jest na sali jakiś spec od kompresji (wiem, że są ;p), który miałby jakieś pomysły w ramach burzy mózgów?
