PRAM: Farbenspiele

Die CeBIT 92 liegt hinter uns. Geblieben ist die wohl wichtigste Neuerung der letzten Jahre: Das lang ersehnte »MultiTOS« ist Wirklichkeit geworden und liegt allen Entwicklern in einer Betaversion vor.

Während Atari also der Durchbruch auf der Softwareseite endlich gelungen ist, gab's an der Hardwarefront kaum Aufsehenerregendes. Ataris neue Maschine »Falcon 030« wurde der Presse, dem Handel und den Entwicklern vorgeführt. Bis zu seiner Publikumspräsentation und der Lieferbarkeit in größeren Stückzahlen dürfte noch einige Zeit vergehen. Soviel scheint jedoch schon heute sicher: Mit 16 aus 4096 Farben wird Atari niemanden mehr vom Hocker reißen. Dementsprechend gilt es als sicher, daß der Neue über erweiterte Grafikfähigkeiten verfügen dürfte. Womit wir dann auch beim Schwerpunkt dieser Programmiererecke angelangt wären: Farben.

Traditionell verfügt der Atari über eine Farbhardware, die es ihm gestattet, 512 verschiedene Farbtöne zu generieren. Diese reichlich schmale Palette erweiterten die STE- und TT-Computer auf immerhin 4096 Farben, eine recht ansehnliche Summe. Eingeschränkt wird diese Palette zudem durch die Tatsache, daß diese 4096 Farben nur mit erheblichem Programmieraufwand gleichzeitig darstellbar sind. Das Betriebssystem hingegen gestattet nur eine Auswahl von maximal 16 (ST, STE) beziehungsweise 256 Farben (TT) aus der darstellbaren Menge. Diese reichlich schmalbrüstige Konstruktion mag den Ansprüchen der vergangenen Jahre genügt haben, für professionelle Anwendungen, wie beispielsweise im DTP-Bereich, der Bildverarbeitung oder der Präsentation, ist sie vollkommen mangelhaft.

Es ist also Zeit nachzudenken, wie bunt die Zukunft denn aussehen dürfe. Und da scheint der Trend offenbar zur Farbe zu gehen: Leistungsfähige Grafikkarten sind seit kurzem auch für Atari-Rechner erschwinglich. Wer den Atari-Stand auf der CeBIT einer eingehenden Musterung unterzog, wird mindestens fünf verschiedene Anbieter in den unterschiedlichsten Preiskategorien entdeckt haben: von der preiswerten 64-Kilofarben-Karte bis zur 24-Bit-True-Color-Karte mit integrierter Screen-Maschine für Echtzeit-Videodigitalisierung und -interpolation. Woran es kränkelt, ist eine eindeutige Richtlinie seitens Atari, wie die neue Farbenpracht denn nun zu nutzen sein soll - im Hinblick auf neue Maschinen wird sie wohl auch bald kommen.

Bleiben wir also fürs erste beim Handfesten. Allein schon die Frage, welche Farben denn wie zu definieren sind, stellt viele Programmierer offenbar vor unlösbare Rätsel. Denn das VDI bietet leider keine entsprechende Funktion. Insbesondere für Farbselektoren, wie sie beispielsweise das Atari-Kontrollfeld bietet, führt das zu allerlei wunderlichen Effekten. So schließen manche Programmierer aus der Tatsache, daß es sich beim verwendeten Rechner um einen ST handelt, darauf, daß für jede Farbkanone genau acht verschiedene Farbstufen zur Verfügung stehen. Für STE und TT veranschlagen sie grundsätzlich 16 Farbabstufungen.

Andere wiederum stellen alle 1000 VDI-Farbwerte zur Verfügung und benutzen »vs_color()« zum Einstellen der gewählten Farbe. Dieses Verfahren ist zumindest sauber, zumal nicht von einer bestimmten Videohardware ausgegangen wird. Das Problem solcher Selektoren ist jedoch, daß nicht für jeden VDI-Farbton auch ein physikalisch einmaliger Farbton generiert wird. So unterscheiden sich VDI-Farbwerte wie z. B. 1, 1, 1 und 2, 2, 2 (Schreibweise: R, G, B) in der Regel überhaupt nicht, weil die Hardware nicht in der Lage ist, 1000 verschiedene Helligkeiten zu generieren.

Das wäre auch gar nicht wünschenswert, denn mit True-Color-Grafikkarten lassen sich bereits über 16 Millionen verschiedene Farben erzeugen, weit mehr, als das menschliche Auge überhaupt unterscheiden kann. True-Color-Karten arbeiten in der Regel mit 24 Bit Farbtiefe, es entfallen also auf jede Farbkanone 256 Stufen 1000 würde das VDI unterstützen.

Es sollte also festgestellt werden, wo sich entsprechende Farbübergänge physikalisch befinden. Dazu ist es nötig, jeden Farbwert einmal per »vs_color()« zu setzen und anschließend mit »vq_color()« zu erfragen, welcher physikalische Wert tatsächlich realisiert wurde. Die entsprechenden Stufen können dann weiterverwendet werden, beispielsweise für Farbskalierboxen oder für Farbrasterdarstellungen. Genau dies erledigt unser Listing.

Die Funktion »scale_col()« rettet zunächst die Farbwerte einer beliebigen VDI-Farbe und beginnt anschließend, alle Farbwerte zwischen 0 und 1000 zu setzen. Übergänge werden dabei notiert und die ursprüngliche Farbe mit der aktuellen verglichen, um die Lage der Ursprungsfarbe innerhalb der Skala zu bestimmen. In unserem Beispielprogramm verwenden wir dazu immer die letzte erreichbare VDI-Farbe, damit das Durchforsten aller Farbwerte nicht allzu sehr den Bildaufbau stört. Die letzte erreichbare VDI-Farbe wird in der Regel recht selten benutzt, weswegen das kurze Aufblitzen des Skalierers keinen allzu großen optischen Schaden anrichtet.

Die Funktion beschreibt die Arrays »rgb_scale[]« und »rgb_got[]« mit der Anzahl der festgestellten Farbübergänge sowie der aktuellen Position innerhalb dieser Farbskala. Dabei werden die Rot-, Grün- und Blauwerte getrennt betrachtet. Das ist deshalb wichtig, weil nirgends dokumentiert ist, daß R-, G- und B-Übergänge immer gleich gerastert sind. So sind zwar die in der ST-Hardware verwendeten Bits gleich gewichtet (R, G, B: 3, 3, 3) und ebenso die der STE- und TT-Hardware (R, G, B: 4, 4,4); in einem 16-Bit-Digital-Analog-Converter (»DAC«) wird's mit der Verteilung jedoch etwas kritischer. In der PC-Welt benutzt man entweder 15-Bit-DACs (Farbvergabe 5, 5, 5) oder aber 16er DACs, die der Grünkanone die doppelte Rasterung verschafft (5, 6, 5). Somit würden sich in einem 16er DAC-VDI nur 5 Bit (Zustände 0 bis 31) auf Rot und Blau verteilen, während Grün über 6 Bit verfügt (Zustände 0 bis 63). Dementsprechend muß jede Farbkanone unabhängig gescannt werden.

Damit das Scanning nicht allzu lange dauert, wird die Scanfarbe nicht ständig um 1 erhöht, sondern das Inkrement wächst exponentiell: 1, 2, 4, 8, 16, 32, 64 und so fort. Sobald ein Übergang festgestellt wurde, fällt das Inkrement wieder gegen 1 und der letzte Übergang wird rückgängig gemacht. Ein Übergang wird nur dann als solcher akzeptiert, wenn das Inkrement 1 betrug. Damit stellen wir sicher, daß bei wachsendem Inkrement nicht versehentlich zwei Stufen auf einmal überschritten wurden. Mit diesem Trick läßt sich die Scangeschwindigkeit um den Faktor 3 bis 10 beschleunigen, je nach verwendeter Videohardware. Damit benötigt das Scanning auch bei alten 8-MHz-STs keine halbe Sekunde.

Beim Einsatz dieser Routinen ließen sich einige überraschende Effekte feststellen. So wird beispielsweise die Auflösung »ST-Hoch« auf dem TT korrekterweise als in 16 Schritten für jede Kanone skalierbar« bezeichnet. In der Tat sind in der »ST-Hoch«-Auflösung des TTs beide Farben frei wählbar. Auf dem ST liefert dieselbe Routine in derselben Auflösung jedoch nur »in zwei Schritten skalierbar«, verständlicherweise, denn dort gibt's nur Schwarz und Weiß.

In der Auflösung "TTHoch« hingegen liefert »scale_col()« erstaunlicherweise »skalierbar nur in einem Schritt und der ist eingestellt«, was auf gut Deutsch bedeutet, daß die eingestellten Farben vollkommen statisch sind. Und in der Tat- nicht einmal Schwarz und Weiß sind umschaltbar! Eine Bildschirminvertierung ist also mit der TT-ECL-Hardware nicht möglich - und das VDI weiß davon!

Erwartungsgemäß unterscheidet die Routine auch ST- und STE-/TT-Videohardware, indem sie beim ST »8 Schritte« und beim STE/TT »16 Schritte« zurückliefert.

Eines sollte in Hinblick auf künftige True-Color-VDIs nicht unerwähnt bleiben: Zwar wäre es durchaus sinnvoll, das bestehende Konzept der VDI-Farbgebung über »vs_color()« beizubehalten, jedoch liegen zum Zeitpunkt der Drucklegung keine Angaben darüber vor, ob und wie ein True-Color-VDI das Mapping von Farben emulieren wird. True-Color-Karten arbeiten nämlich im Gegensatz zur bisherigen Atari-Videohardware nicht mehr über Color-Lookup-Tables (»CLUTs«), bei denen jeder VDI-Farbe ein entsprechendes Farbregister zugeordnet ist, anhand dessen die Hardware das Videosignal generiert. Vielmehr werden die Hardwarefarben direkt in den Bildschirmspeicher geschrieben - ein Verfahren, auf welches das bestehende VDI schlecht vorbereitet ist. Welche Wirkung das Verstellen einer VDI-Farbe mittels »vs_color()« demnach auf das momentan gezeigte Bild haben wird, ist ungeklärt.

Sobald genauere Dokumentationen zu diesem Thema zugänglich sind, werden wir Sie über den neusten Stand der Dinge unterrichten.

Laurenz Prüssner/uw

colscan.c


Links

Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]