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

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).

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.

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.

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

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.

@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.

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.

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.

640x480 to tylko w RGB sie da.

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.

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.

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.