Höhere Auflösungen mehr Farben: Großbildschirme und hohe Auflösungen in Farbe

Wenn Sie sich auf der Atari-Messe umgesehen haben, entging Ihnen ein Trend sicher nicht: Nahezu jeder zweite Stand war mit einem 19-ZoIl-Monitor bestückt. Kein Wunder, denn die Vorteile, die sich durch die größere Bildschirmfläche ergeben, sind beachtlich — und das nicht nur beim Desktop Publishing. Es gibt fast keine Anwendung, die nicht davon profitieren würde. Und das Wörtchen »würde« wählten wir mit Bedacht, denn es gibt leider immer noch zuviel Software, die sich auf eine feste Bildschirmgröße und andere Dinge verläßt. Dabei ist es gar kein großer Aufwand, die Programme so zu schreiben, daß sie sich auf die Bildschirmauflösung einstellen.

Beginnen wir mit den reinen TOS-Anwendungen, denn bei dieser Art Software ist nicht viel zu beachten. Leider gab es lange Zeit keine Dokumentation darüber, wie man die Anzahl der Bildschirmzeilen und -spalten erfragt. Wie einfach wäre es doch gewesen, hätte Atari zu diesem Zweck eine XBIOS-Funk-tion eingerichtet. Glücklicherweise sind seit Anfang dieses Jahres zwei Systemvariablen offiziell dokumentiert. Wenn man die Line-A-Init-Funktion aufruft, bekommt man im Register AO einen Zeiger auf den Line-A-Variablenblock zurück. Während die Line-A-Variablen mit positivem Offset als reine Eingabeparameter für die Line-A-Funktionen gedacht sind, dienen die Variablen mit negativem Offset ausschließlich als Status-und Informationsvariablen.

Für uns sind hier vor allem zwei 16 Bit-Variablen interessant: V___CEL_MX findet man beim Offset - 44, V_CEL____MY bei - 42. Sie enthalten die größtmögliche Textspalten- beziehungsweise Zeilennummer, das heißt die Anzahl der Spalten und Zeilen - 1.

Wenn man in einer GEM Anwendung aus irgendeinem Grund diese Werte benötigt, weicht man auf die VDI Escape-Funktion »vq____chcells« aus. In TOS-Anwendungen ist dies weniger praktikabel, da man vorher in jedem Fall eine virtuelle Workstation öffnen müßte.

Ein weiteres kleines Problem ergibt sich, sobald man in TOS-Anwendungen Bildschirmmasken anzeigt. Manche Programme verlassen sich darauf, daß nach der Ausgabe von 80 aufeinanderfolgenden Zeichen der Cursor am Anfang der nächsten Zeile steht (wrap-around). Das ist auf einem Doppel-Ganzseitenbildschirm, der immerhin 160 Zeichen pro Zeile darstellt, nicht der Fall. In diesem Fall sollten Sie auch bedenken, daß das interne Wrap-Around-Flag keine definierte Voreinstellung besitzt. Wenn man sich auf den Wrap-Around-Effekt verläßt, sollte man erstens die Anzahl der Textspalten erfragen und zweitens den Wrap-Around-Modus explizit per Escape-Sequenz einschalten.

Kommen wir nun zu den GEM-Anwendungen. Beginnen wir zunächst mit den Dingen, die für beide Arten von GEM-Anwendungen gelten.

Eines dürfte inzwischen jedem klar sein: Konstante Werte, die die Bildschirmauflösung betreffen, haben in Atari-Programmen nichts zu suchen. Damit man erst gar nicht in Versuchung kommt, merkt man sich am besten direkt nach dem Aufruf von »Open Virtual Workstation« die X- und YAuflösung in zwei Variablen. Wenn man dann an anderer Stelle im Programm bestimmte Bereichsabfragen durchführt, greift man auf diese beiden Variablen zu. Wichtig: Beim Erzeugen von Fenstern (wind___create) muß man die Maximalgröße des Fensters angeben Ein äußerst verbreiteter Fehler — fast jedes zweite Programm verhält sich so — betrifft das Clipping bei Dialogboxen. Wenn man eine Dialogbox mittels »objc—draw« auf den Bildschirm bringt, muß man unter anderem ein Clipping-Rechteck angeben. Sehr viele Programmierer haben bisher einfach die Konstanten 0,0,640,400 angegeben — das geht nur so lange gut, wie die Auflösung des Bildschirms nicht größer als 640 x 400 Punkte ist. Die Abhilfe ist einfach: Man verwendet als Clipping-Rechteck die Werte, die man bei »form__center« zurückbekommt:

PROCEDURE Dialog;
	VAR x,y,w,h : INTEGER;
	BEGIN
		form_center(dialog,x,y,w,h); 
		form_dial(0,0,0,0,0, x,y,w,h);
		objc_draw(......,x,y,w,h);
		... := form_do(...) form_dial 
		(3,0,0,0,0,x,y,w,h);END Dialog;

So, bisher waren das ja alles ganz harmlose Sachen, die die meisten von Ihnen ohnehin beachtet haben. Aber es gibt auch einige wirklich gemeine Fußangeln. Stellen wir uns vor, wir haben ein Malprogramm geschrieben, das die Abbildung in einem Fenster darstellt. Gehen wir weiter davon aus, daß die Breite der erzeugten Bilder immer 640 Punkte beträgt. Daraus folgt, daß sich das Bild auf den bisher gängigen Monitoren niemals in voller Breite darstellen läßt. Was passiert nun, wenn man einen Großbildschirm hat, der es locker auf eine Auflösung von 1280 x 960 Punkten bringt? Jetzt müssen wir uns auch mit dem Fall auseinandersetzen, daß die Fensterbreite möglicherweise die Breite des Bildes überschreitet. Nun, man löst das Problem ganz einfach dadurch, indem man nicht zuläßt, daß das Fenster größer als das Bild wird.

Doch leider sind damit noch nicht alle Probleme gelöst. Demnächst wird es eine Grafikkarte geben, die 640 x 480 Punkte in 16 Farben (bei 70 Hz) bietet. Damit ist der Zeitpunkt gekommen, an dem man den SM124 getrost beiseitestellen kann.

Es ist allerdings zu befürchten, daß eine große Anzahl von Programmen auf diesem Bildschirm nicht lauffähig ist, geschweige denn ihn ausnutzt. Das Problem liegt vor allem am Ermitteln der Auflösung und der Anzahl der verfügbaren Farben mit der XBIOS-Funktion »Getrez«. Eine ganz dringende Bitte: Lassen Sie die Finger von Getrez. Alle benötigten Angaben erhält man bei »v__opnvwk« — einschließlich der Grö-

ße der Farbpalette. Gleiches gilt für die XBIOS-Funktionen zur Farbeinstellung, denn der RGB-Anteil läßt sich nur auf jeweils 4 Bit genau einstellen — besagte Grafikkarte bietet aber eine Genauigkeit von 6 Bit, und es gibt keinen Grund anzunehmen, daß es nicht demnächst eine Grafikkarte geben wird, die 8 Bit benötigt.

Das war leider immer noch nicht alles — es gibt noch einige Stolpersteine. Wenn Sie sich nicht alle Wege verbauen möchten, bessere Grafikkarten anzusprechen, verwenden Sie bitte tunlichst keine Line A-Aufrufe zur Bildschirmausgabe, denn diese benutzen zum Feststellen des Farbwerts vier Variablen: COLBIT0 bis COLBIT3. Jede dieser Variablen enthält ein Bit — zusammen ergeben sie den Farbwert. Da es nur vier dieser Variablen gibt, kann man mit Line-A-Aufrufen nur vier Planes, das heißt 16 Farben benutzen. Auch an diesem Beispiel zeigt sich ganz deutlich, daß die Line-A-Aufrufe nur für die interne Benutzung des VDI gedacht waren. Und vor allem: Wenn es schon Line-A sein muß, bitte mischen Sie keine Line-A- mit VDI-Aufrufen, es sei denn. Sie mögen lustige Effekte...

Wir hoffen, daß Ihnen dieser Artikel ein paar Tips und Hilfen zum Thema »Großbildschirme und hohe Auflösungen in Farbe« gegeben hat. (uh)

Literatur:

[1] Jankowski, Rabich, Reschke, Atari ST Profibuch, Sybex 1987/88 [2] Atari Corp., S.A.L.A.D, Still Another Line-A Document, Dez. 1987 [3] Digital Research, Dokumentation zu GEM Z2.