SPACEHAWKS WORLDNEWS ISSUE 17
Storm dither

Hogyan jelenítsünk meg RGB piceket AGA-n?

(Köszi Kókusz a reakciót. Remélem lesz még pár hasonló. ;} )

Ez a cikk egy levél alapján készült, amit a Cobra nevű dudétól kaptam. Ő csinyálta pH03N1x MOV/AVI lejátszójának, a MooVID-nak a "STORM" nevezetű ditherjét. Ja, és valami RiVA nevezetű MPEG lejátszót is gyárt a srác...

Most a cél fényképszerű képek megjelenítése lesz, így képernyőmódnak legmegfelelőb a HAM8 lesz. Pixeles, vagy "ditherelt" képnél ez a mód siralmas eredményt tud produkálni, így ott ezt a HAM8-at módosítások nélkül nem ajánlanám.

A HAM üzemmódok (HAM6 és HAM8) működését minden öreg amigás ismeri, de a grafcardon (esetleg PC-n?!) felnőtt új nemzedék kedvéért kürölírnám, hogy működik. Egy HAM pixel áll kontroll bitekből és "adat" bitekből, ezek a bitek bitplane-eken helyezkednek el, ahogy azt szeretett Amigánkon már megszokhattuk. A kontroll bitek száma mindegyik HAM módnál 2 db, a maradék meg lesz adatbit (HAM6-nál 4, HAM8-nál 6).

HAM8-as példa: A palettában az első elem legyen mondjuk fekete, ekkor

stb. Persze palettás pixelek lehetnek akárhol a képben, a sorokat általában ilyennel illik kezdeni. Ja, a bitek helye és értékei nem biztos, hogy stimmelnek, még nem volt időm megírni a kódot... Két-három próbából úgyis rá lehet jönni...

A legegyszerűbb RGB-HAM8 konverzió az, amilyet a Photogenics használ:

Tehát minden pixelből egy komponenst feszünk csak figyelembe. (Ne felejtsétek, ez csak fényképszerű képeknél ad elfogadható eredményt.) A Photogenics egyébként pontosabban úgy csinálja, hogy csak minden 3. pixelt veszi az RGB képről, és ezek adat bitjeit állítgatja a képernyőn. Ha előre beállítottad a kontroll bitek mintáját, a renderelésnél már csak az adatbiteket kell módosítani, tehát a feladat tulajdonképpen egy 6 bites Chunky-to-Planar konverzió. Ha a forrás 24 bites kép, mindegy hogy az RGB vagy BGR, mert csak a kontroll biteket kell máshogy állítgatni.

Aztán van a közismert 18bit rutin, amit demókban használnak, pl. egy 160-széles buffert rajzolnak egy 640-széles bitmapre. Tehát minden truecolor pixelre 4 darab HAM8 pixel kell. És persze a harmadik és negyedik pixel az már truecolor, vagyis pontosan az, aminek lennie kell. Az első és második pixel viszont általában nem teljesen az, aminek lennie kéne, de ez alig látszik:

Vagy másképpen:

Ez azért jobb kissé, mert a zöld komponens adja a pixel fényességének több, mint 50%-át... A képeken a fehér pixelek azt jelentik, hogy oda nem rakunk semmit, hiszen a harmadik pixel már tökéletes. Illetve hát valamit csak oda kell rakni, pl. kirakhatjuk mégegyszer azt a kék komponenst "módosító" pixelt.

A STORM dither egy kicsit trükkösebb eljárással működik, ami eleinte nem tűnik úgy hogy működne, de egész jó eredményt ad.

Így vannak elrendezve a pixelek:

Persze lehet variálni, az a lényeg, hogy zöldet minden pixelből ki kell venni, mert annak van a legnagyobb "ereje". Aztán a zöld mellett a pirosat és a kéket felváltva kell kivenni, tehát a páros pixelekből a kék, a páratlanakból a piros (vagy fordítva is jó persze).

És mielőtt elkezded a rutint, be kell állítani a HAM8 control biteket a 7. és 8. planekre, ezek fixen úgy fognak maradni, szóval csak 6 planet kell írni.

Ezután egy eccerű 6-bit c2p az egész. Használhatsz 8-bit c2p-t is, és nem írod ki az utolsó 2 planet, de sokkal jobb ha igazi optimalizált 6-bit c2p-t használsz.

Azért van kivétel, amikor esetleg érdemes 8 bites c2p-t használni, mint pl. egy 16 vagy 24 bitesre tervezett game. Pl. egy űrhajós szimulátornál hasznos lehet ha a kisebb (néhány pixeles) objekteknél (pl. csillag) kontrasztosan tudjuk állítani a színeket. Nem próbáltam még, hogy ez a módszer ténylegesen használható-e ilyen célra, de ez terveim szerint hamarosan ki lesz derítve...

Isoráz: a cikk gerincét (az ötletadó e-mail-t) a Cobra gyártotta, én csak belepofáztam itt-ott.

Att1s^SH