1

Temat: Konwersja do palety indeksowanej 8bit

Jak się robi konwersję z palety 24bit do indeksowanej 8bit w grach czy demach na Falcona aby to działało wydajnie w c/c++?
Bo mam sobie taki przypadek, blok 250x70 pikseli (czyli jakieś 18 tysięcy pikseli) i po przeliczeniu mega prostego efektu na tym bloku (które trwa jakieś kilka milisekund pod Hatari 68040@32MHz) dopasowanie składowych R, G, B do palety 8bit za pomocą SDL'owej funkcji SDL_MapRGB dla tych 18 tysięcy pikseli trwa około 3,5 sekundy!
Pod CT63 podkręconym na 95MHz jest oczywiście zauważalnie szybiej, ale i tak jest to dalekie od jakiejkolwiek sensownej prędkości.
Wymyśliłem, że sam sobie stworzę taką funkcję konwertującą, ale wyszło jeszcze z pół sekundy dłużej, a do tego ostateczne odwzorowanie koloru/indeksu palety jaki został wybrany jest zdecydowanie gorsze.
Jak się w takim razie ogarnia jakieś efekty na większej ilości pikseli, tak aby to działało znośnie? No chyba, że efekty robi się jakoś bezpośrednio na docelowej palecie aby uniknąć konwersji, ale to była by chyba jakaś masakra.

Ostatnio edytowany przez jury (2021-01-04 21:52:18)

2

Odp: Konwersja do palety indeksowanej 8bit

To się nazywa color quantization i może zająć całkiem sporo czasu.
Rzuć okiem na RECOIL Foxa, albo gości z Atari-Forum: DML, Cyg i Anima. Opublikowali oni swoje narzędzia do konwersjigrafik.
Wieczorem mogę podrzucić linki.

Grafikę lepiej robić w docelowej ilości kolorów bo konwersja 24bit na 8bit sporo trwa.


---EDIT---

SDL C2P Kalmsa dla Atari
https://robocup.wtb.tue.nl/svn/techunit … ataric2p.S

Ostatnio edytowany przez Cyprian (2021-01-08 15:20:40)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

3

Odp: Konwersja do palety indeksowanej 8bit

Tak, zgadza się, właśnie funkcja SDL_MapRGB tak działa, tyle, że nawet na CT6x tak wolno, że nie da się tego używać w tak zwanym czasie rzeczywistym. Dlatego też myślałem, że w demach czy grach używa się jakichś jeszcze bardziej stratnych algorytmów aby to działało wydajnie.
Jak będziesz miał chwilkę, to podrzuć te linki.

Odp: Konwersja do palety indeksowanej 8bit

W czasie rzeczywistym można, jak się ma dużo pamięci to ztablicować. Można to uprościć przez przeliczenie na jasność i mapowanie na konkretną paletę po tej jasności, i np. w przypadku konwersji do greyscale to może nawet fajnie wyglądać (tj. wygląda jak byś miał monitor mono i wyświetlał na nim TC).

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

5

Odp: Konwersja do palety indeksowanej 8bit

oprócz redukcji palety koloru, trzeba jeszcze przekształcić obraz z chukny na bitplany


jury napisał/a:

Jak się robi konwersję z palety 24bit do indeksowanej 8bit w grach czy demach na Falcona aby to działało wydajnie w c/c++?
Bo mam sobie taki przypadek, blok 250x70 pikseli (czyli jakieś 18 tysięcy pikseli) i po przeliczeniu mega prostego efektu na tym bloku (które trwa jakieś kilka milisekund pod Hatari 68040@32MHz) dopasowanie składowych R, G, B do palety 8bit za pomocą SDL'owej funkcji SDL_MapRGB dla tych 18 tysięcy pikseli trwa około 3,5 sekundy!


dema operują albo na 16 albo 8 bitowej grafice. W przypadku 8 bitowej grafiki ewentualnie robione jest C2P.
Nie słyszałem o stosowaniu redukcji kolorów w czasie rzeczywistym w demach.

Ostatnio edytowany przez Cyprian (2021-01-05 10:08:19)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

6

Odp: Konwersja do palety indeksowanej 8bit

W czasie rzeczywistym to musisz mieć paletę przygotowaną wcześniej i do niej konwertujesz.
a. 16-megabajtowa tablica umożliwi konwersję do dowolnej palety. Bez zauważalnej straty jakości możesz zignorować najmłodsze bity i mieć tablicę 2-megabajtową czy nawet 256 KB.
b. Bez tablicy to potrzebujesz palety RGB, np. R3G3B2, a żeby równo podzielić składowe i mieć ładne gradienty szarego to https://en.wikipedia.org/wiki/Web_color … afe_colors
Oczywiście, że szybciej będzie od razu operować na indeksach docelowej palety, niż 24-bit + konwersja. W przypadku palety RGB nie powinno to być takie trudne.

https://www.youtube.com/watch?v=jofNR_WkoCE

7

Odp: Konwersja do palety indeksowanej 8bit

Dzięki Panowie, wygląda na to że tablica będzię najlepszym rozwiązaniem. Szczególnie kusząca jest ta opcja 2MB'owa bez zauważalnej straty.

Odp: Konwersja do palety indeksowanej 8bit

Tu nasuwa się pytanie: czemu chcesz pracować na 24bitach? Jeśli chcesz nakładać na siebie pixele, robic przeźroczystość itp. efekty, to jest na to prostsza metoda. Np. chcesz nałożyć na siebie 2 pixle z wagą 50% w palecie 256 kolorów. To do tego generuje się wcześniej macierz 256x256 i szukasz tam wynikowego koloru. Oczywiście paleta ta musi być w miarę pod to przygotowana, ale tak się robi w większości noszych dem na Amigę 1200 czy Falcona, więc jak widać to działa.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

9

Odp: Konwersja do palety indeksowanej 8bit

Nie programuję na ST ale tak na zdrowy rozsądek stała tablica oznacza statyczną paletę. Kwantyzacja na bieżąco to natomiast dynamiczne dopasowanie palety do bieżących warunków, co powinno dawać lepsze efekty. Przy podejściu statycznym powinno się dać to statycznie zrobić w prostszy sposób bo i tak zgadzasz się na błąd związany z niedopasowaniem palety.

Ale ja tam się nie znam :)

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

10

Odp: Konwersja do palety indeksowanej 8bit

Ja robiąc dema na F060 robiłem kwantyzacje up-front (na PC) w pipeline'nie przygotowujacym/konwertujacym assety*. Z punktu widzenia kodu Falconowego wszystko było już gotowe i statyczne (8bit). Nie widzę jakiejś strasznej potrzeby robienia tego w runtime - jury dlaczego? Jak to mówią: najlepsza optymalizacje = nie liczyć;)

* np uzgodnienie wspolnej palety dla kilku tekstur bedacych w jednej scenie itp edit: używałem python'owego Pillow'a chyba do tego

Ostatnio edytowany przez mkm (2021-01-05 14:32:03)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

Odp: Konwersja do palety indeksowanej 8bit

@perinoid efekty będa lepsze ale duuuuużo wolniejsze :P

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

12

Odp: Konwersja do palety indeksowanej 8bit

mkm napisał/a:

JNie widzę jakiejś strasznej potrzeby robienia tego w runtime - jury dlaczego? Jak to mówią: najlepsza optymalizacje = nie liczyć;)

Nie, nic z tych rzeczy, jeśli z mojej wypowiedzi wynika, że uparcie chcę to robić realtime, to zupełnie niezamierzone. Zdecydowanie należę do tych dla których liczy się wynik końcowy, a jak jest osiągniety, to kompletnie nieistotne ;)
W weekend będę miał chwilkę, to zmontuję tablicę 7 czy nawet i 6 bit jak proponował Fox, i mam nadzieję, że będzie git.

13

Odp: Konwersja do palety indeksowanej 8bit

Adam Klobukowski napisał/a:

Tu nasuwa się pytanie: czemu chcesz pracować na 24bitach?

Bo tak jest zrobione i specjalnie nie chce mi się wprowadzać dużo zmian. Jest to bardzo prosta gra, tyle, że w pierwszym SDLu i rozdzielczości 640x480, więc bezpośrednio po skompilowaniu tego, chodzi to wszystko jedna klatka na 2-4 sekund. Chcę to doprowadzić do stanu używalności i powoli widać różnice. Na razie "siedzę" jeszcze w menu, i tam jest właśnie kilka efektów, jak np credits'y co kilka sekund zmieniające się, gdzie starye napisy znikają tak jak dym.

14

Odp: Konwersja do palety indeksowanej 8bit

@jury

w takim razie dużo szybszym wariantem będzie konwersja 24bit do 16bit i zastosowanie Falconowego trybu Hi-Color. Tutaj robisz tylko jeden krok - szybką redukcję bitów.
W wariancie 24bit do 8bit masz więcej czasochłonnych kroków: ustalenie palety 256 kolorów, redukcja 24bit do 8bit na podstawie ustalonej palety, no i na koniec C2P.

Ostatnio edytowany przez Cyprian (2021-01-07 21:59:42)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

15

Odp: Konwersja do palety indeksowanej 8bit

Z pierwszego posta wnioskuje, że target to 060. Generalnie odradzam przy 060 tryb TC: konwersja w C2P to zerowy koszt bo jest copy speed a przy 8 bit liczba danych do przepchniecia jest 2 razy mniejsza niz przy TC. Nie mówie nawet o renderingu w TC bezposrednio do ST-RAMu bo to najgorsze rozwiązanie które zabiję szynę. Ja nadal szedłbym w stronę tego by robić to podczas inicjalizacji (np ładowanie sceny czy levelu jesli nie chcesz konwertowac assetow up-front jak pisalem) a nie per frame.

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

16

Odp: Konwersja do palety indeksowanej 8bit

mkm napisał/a:

Z pierwszego posta wnioskuje, że target to 060. Generalnie odradzam przy 060 tryb TC: konwersja w C2P to zerowy koszt bo jest copy speed a przy 8 bit liczba danych do przepchniecia jest 2 razy mniejsza niz przy TC. Nie mówie nawet o renderingu w TC bezposrednio do ST-RAMu bo to najgorsze rozwiązanie które zabiję szynę.


Może być tak że wariant konwersji grafiki TrueColor do 256 kolorowej i potem C2P będzie szybszy.
Na razie jednak nie wiemy ile ta konwersja zajmuje czasu procesora.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

17

Odp: Konwersja do palety indeksowanej 8bit

Cyprian, ale ciągle zakładacie że jest to robione per frame a ja sugeruje by to zrobić raz per scena (czy level) w init'cie (choć ja bym to zrobił już przy build'dzie) i wtedy koszt kowersji TC do 8bit w ramce jest zerowy (bo już jej nie ma).

Ostatnio edytowany przez mkm (2021-01-08 13:09:47)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

18

Odp: Konwersja do palety indeksowanej 8bit

Dokładnie, tak zwany target to 060. I przyznam szczerze, że nawet nie rozważałem trybu TC, ba nawet o nim nie pamiętałem. Dla mnie jest to jakiś egzotyczny tryb, nie mówiąc, że kompletnie o nim nic nie wiem, oprócz tego, że raczej jest ciężki. A do tego tego potrzebuję rozdzielczości 640x480, więc czy tryb TC w takiej rozdzielczości nie zabił by ST-RAMu?. Choć kiedyś będę musiał się pobawić tym trybem,.
Ja generalnie mam jedną paletę 8bit, do której potrzebuję się konwertować, więc opcja ze zrobieniem tablicy w inicie to zdecydowanie najbardziej podobające mi się rozwiazanie. W sumie nawet jak bym miał tych palet więcej (a przecież była by to mocno skończona ilość) to i tak bym robił tablice, pewnie wtedy 6cio bitowe, zaufam Fox'owi, że nawet na 6 bitach straty będą niezauważalne.

19

Odp: Konwersja do palety indeksowanej 8bit

To jeszcze jedno. Chcesz zrobić init tablicy na starcie a pozniej dla kazego odswiezanego pixela ekranu robic w niej lookup a potem zapisywac znaleziony kolor do chunky buffora, tak? Nie wiem jak duzo odrysowywujesz co ramke, ale jesli wiekszosc ekranu to ten koszt też może się zrobić znaczący (w stosunku do przygotowania 8bit grafik wczesniej).

Swoja drogą używasz C2P w pełnym oknie 640x480? Ciekawe jestem jak to się spisuje, pewnie coś koło 3 ramek na to leci na CT60?

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

Odp: Konwersja do palety indeksowanej 8bit

640x480 to tylko w RGB sie da.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

21

Odp: Konwersja do palety indeksowanej 8bit

Adam Klobukowski napisał/a:

640x480 to tylko w RGB sie da.


RGB 768x480 TC w overscanie
VGA 320x480 TC (chyba 400x480 overscanie)

dla trybów 256 kolorowych rozdzielczość jest dwa razy większa niż dla TC

Ostatnio edytowany przez Cyprian (2021-01-08 17:59:15)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

22

Odp: Konwersja do palety indeksowanej 8bit

mkm napisał/a:

To jeszcze jedno. Chcesz zrobić init tablicy na starcie a pozniej dla kazego odswiezanego pixela ekranu robic w niej lookup a potem zapisywac znaleziony kolor do chunky buffora, tak?Nie wiem jak duzo odrysowywujesz co ramke, ale jesli wiekszosc ekranu to ten koszt też może się zrobić znaczący (w stosunku do przygotowania 8bit grafik wczesniej).

Na chwilę obecną jest to zrobione tak, że po przeliczeniu danego piksela od razu leci on do karty graficznej, co w naszym przypadku oznacza ST-RAM. Ale generalnie taki właśnie mam plan, że po przeliczeniu koloru najpierw będę go wrzucał do chunky buffora w TT-RAMie, a potem tylko jednym SDLowym blitem przerzucał to do ST-RAMu. To jest następny mój krok optymalizacji tego, ale już wstępnie w pół minuty byle jak na szybko skonstruowałem  sobie taki bufforek i tam przekierowałem przeliczone kolory a potem jeden blit do ST-RAMu i faktycznie różnica w czasie wykonania była ogromna.

mkm napisał/a:

Swoja drogą używasz C2P w pełnym oknie 640x480? Ciekawe jestem jak to się spisuje, pewnie coś koło 3 ramek na to leci na CT60?

No ja akurat jak to mierzyłem to nie w ramkach tylko w milisekundach i wychodzi mi, że w 640x480x256 SDL przerzuca bufor ramki do ST-RAMu w jakieś 60 milisekund, czyli faktycznie jakieś plus/minus 3 ramki.

Ostatnio edytowany przez jury (2021-01-10 14:39:35)

23

Odp: Konwersja do palety indeksowanej 8bit

60 milisekund to jakieś 16 ramek na sekundę

Ostatnio edytowany przez Cyprian (2021-01-13 20:43:44)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

24

Odp: Konwersja do palety indeksowanej 8bit

Dzięki uprzejmości @jury mam wyniki NemBench v2.1 dla Falcona z CT63 94MHz dla monitora VGA (dla TV/RGB 15Khz będą zupełnie inne!). Pełne wyniki wrzucę na Atari-Forum.

VGA 320x240 256c
Linear 32bit write (ST-Ram)  -> 8.181 MByte/sec (~126%)  

VGA 320x240 TC
Linear 32bit write (ST-Ram)  -> 6.206 MByte/sec (~96%)          

VGA 640x480 256c
Linear 32bit write (ST-Ram)  -> 6.206 MByte/sec (~96%)

Obraz:
- 320x240 256c (8bit) zajmuje 76 800 bajtów
- 320x240 TC (16bit) zajmuje  153 600 bajtów
- 640x480 256c (8bit) zajmuje  307 200 bajtów


W trybie VGA 320x240 256c dla grafiki 320x240 256c Falcon pozwala uzyskać:
-  107 FPS (zapis z TT-RAM do ST-RAM)

VGA 320x240 TC dla grafiki 320x240 TC):
-  40 FPS (zapis z TT-RAM do ST-RAM)

VGA 640x480 256c dla grafiki 640x480 256c:
-  20 FPS (zapis z TT-RAM do ST-RAM)


@jury, tak więc, dla Twojego trybu VGA 640x480 256c można teoretycznie uzyskać maksymalnie 20 FPSów.
Dla trybu TV/RGB powinno być dużo więcej FPSów.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

25

Odp: Konwersja do palety indeksowanej 8bit

Pod warunkiem, że wygenerowanie tych FPSów które kopiowanie będą do ST ramu zamuje dokładnie 0 FPSów :)

What can be asserted without proof can be dismissed without proof.