Witam
Jestem osoba która lubi wyzwania, a ponieważ moja pasja jest processing obrazu i video naturalna koleją rzeczy było zainteresowanie się ograniczeniami graficznymi pierwszej Amigi. Najpierw przyczyniłem się do rozwoju konwersji na HAM - program ham_convert. Natomiast obecnie pomagam w stworzeniu porządnego konwertera do trybu Dynamic Hires ale zupełnie innego niż znacie.
Problem konwersji do tego trybu można podzielić na podproblemy:
1. Konwersje kolorów RGB24 do RGB12
2. Zmniejszenie liczby kolorów w linii do 16,8 lub 4 tak by zachować w miarę stabilny nie poszatkowany obraz.
3. Uzyskanie w miarę wysokiego stopnia kompresji danego obrazka.
4. Zużycie jak najmniejszej ilości zasobów komputera, tak by oprócz wyświetlania obrazka można było cos jeszcze zrobić.
Konwersja do tego trybu wiąże się z pokonaniem problemu artefaktów, tutaj konkretnie mamy do czynienia z poszatkowaniem w pionie kolorów. W przypadku obrazków fotograficznych gdzie kompleksowość obrazu jest bardzo wysoka ten problem jest mniej odczuwalny niż w przypadku pixelartu. Dodatkowo problem ten doskwiera tym bardziej im mniej kolorow w linii mamy do dyspozycji.
Poniżej znajdziecie państwo parę przykładowych grafik Slayera którego talent cenie i który świetnie się nadaje do testów. Nad każdym z obrazków musiałem spędzić trochę czasu, ponieważ to nie sprowadza się tylko do klikania, a do dobierania parametrów konwersji do konkretnego obrazka i to na razie jest główny powód dlaczego konwerter nie jest dostępny publicznie.
Otóż docelowo idea tworzenia pixelartu w tym trybie powinna sprowadzić się do czegoś takiego:
1. Robimy nasze arcydzieło w zwykłym jakimkolwiek PCtowym programie graficznym przy użyciu pełnego RGB24.
2. Konwertujemy obrazek do dynamic Hires
3. Ręcznie poprawiamy artefakty które niestety są nieuniknione.
To co uzyskamy to wpolczesna grafikę na komputerze z 1985roku...
Oryginalny Dynamic Hires był oparty o 4 bitplanowy Hires, który bardzo obciążał DMA. W każdej linii obrazu na dostępnych 226 slotów pamięci, obraz zajmował 160!!. W efekcie CPU mógł mieć jedynie jakieś 25% mocy
To co zobaczycie poniżej to konwersja na 3 bitplanowy (8kolorow w linii) zużywający jedynie 120cykli na 226 (odpowiednik zasobozernosci lowresowego EHB, czyli CPU ma jakieś 70% mocy) oraz 2 bitplanowy 4 kolorowy w praktyce pozwalający CPU pracować na 100% swojej szybkości.
Jednym słowem matematyczny hardcore bardzo mało obciazajacy cpu :D
Na koniec pare slow o kompresowalnosci takich obrazkow. IFF PCHG po optymalizacji i kompresji powinien mniej więcej odpowiadać wielkości PNG tych obrazkow co oznacza rozpietosc od 25 do 65kB czyli stosunkowo niewiele...
Ostatnia aktualizacja: 19.01.2018 12:42:32 przez Trachu