Programmierecke: Nun mach mal halblang

Bei der Einbindung von Grafiken in Resourcedateien ist einiges zu bedenken. Wir verraten, wie Sie Ihre Icons auch für die verschiedenen Auflösungen der ST-Konfigurationen tauglich machen.

Zum einen müssen Icons und Images vor der Verwendung der Resource vom GEM-Standardformat ins geräteabhängige Rasterformat gebracht werden, damit die Programme auch auf neuen Grafikkarten laufen und vor allem bei der Umsetzung aufs PC-GEM keine Zicken machen. Deshalb stellten wir bereits im Oktober 1989 einige Routinen aus Tim Orens »Professional GEM«-Reihe vor, welche die dafür notwendigen Konvertierungen vornehmen. Leider hat man damit bei weitem noch nicht alle Klippen umschifft.

GEM zieht nämlich für alle Berechnungen mit den gespeicherten Objektdaten der Resource die Größe eines Standardzeichens als Einheit heran. Ausgegeben werden alle Objekte auf dem Bildschirm in Pixelgrößen, die Resourcedaten liegen jedoch im Zeichenformat vor. Daraus folgt, daß sämtliche Resourcedaten vor der Bildschirmausgabe umgerechnet werden müssen. Die dazu nötigen Umrechnungen führt rsrc_load() automatisch aus. Dabei multipliziert es sämtliche Koordinaten sowie Angaben von Höhe und Breite mit den Ausmaßen eines Standardzeichens, über welche die Funktion graf_handle() Auskunft gibt. Damit sind alle Objekte problemlos an die verschiedensten Bildschirme anzupassen. Allerdings gilt das nicht für zwei Objekttypen, die ihrer Natur entsprechend schon im Pixelformat vorliegen müssen: »G_ICON« und »G_IMAGE«, also Icons und Images. Das stört auf Monochrombildschirmen nicht, fällt aber sofort auf, wenn der Bildschirm verzerrt ausgibt, beispielsweise in den beiden Farbauflösungen des STSystems. Hier liefert graf_handle() für Breite und Höhe eines Standardzeichens gleiche Werte, stellt ein Zeichen beispielsweise in der mittleren ST-Farbauflösung aber nicht quadratisch, sondern länglich verzerrt dar. Piktogramme, die für andere Auflösungen wie etwa für die verzerrungsfreie 8 x 16-Auflösung gezeichnet wurden, passen nicht in dieses Schema und erscheinen deshalb etwas hoch aufgeschossen. Sehr schön läßt sich dies beispielsweise an der Info-Box des Programmes »Scigraph« sehen: In der mittleren ST-Auflösung ragt das Logo der Entwickler aus der Dialogbox heraus. Als Abhilfe wurde bisher geraten, in den Farbauflösungen spezielle Resourcefiles zu verwenden und eigene Farb-Icons zu entwerfen. Nicht gerade elegant! Wir schlagen ein anderes Verfahren vor: Das Programm streicht bei festgestellter Verzerrung einfach jede zweite Zeile des Icons. Dadurch wird es in der Höhe schlichtweg halbiert. Dies erledigt unser beiliegendes C-Listing, das die bestehenden Funktionen von Tim Oren [1] erweitern.

Damit kann jedes Icon ohne spezielle Anpassungen in jeder Farbauflösung benutzt werden. Das Ergebnis fällt je nach Icon unterschiedlich aus. Größere Images sind meist ohne Probleme verwendbar. Images, die nicht viel höher als lediglich einige Zeichen sind, erkennt man nach der Konvertierung logischerweiser oft schwieriger. Als Ergänzung unserer Routine wäre folgendes denkbar:

Im Notfall sollte es helfen, jede Zeile mit der nächsten mit der logischen Verknüpfung »oder« zu verschlüsseln, dies ist jedoch nur in wenigen Einzelfällen nötig. Mit einem einfachen Flag könnte man entscheiden, welche Icons oder Images »verodert« und welche einfach nur gekürzt werden sollen. Dieses Flag kann schon im Resource-Construction-Set gesetzt werden. Schraffuren und Muster mögen nämlich die »Veroderung« überhaupt nicht, sie erscheinen meist als schmierige dunkle Flächen oder vollkommen schwarz. Deshalb sollte man einige Versuche anstellen, bevor man sich für die eine oder andere Verfahrensweise entscheidet.

Seit der Vorstellung des M68010-Prozessors im Jahr 1983 ist bekannt, daß das Stackformat bei Exceptions um einen zwei Bytes langen Wert, das »Format Word«, erweitert wurde. Die unteren 12 Bits des Format-Words enthalten den »Exception Vector Offset«. Dieser Wert enthält den Offset der ausgeführten Exception relativ zum Anfang der Tabelle der Exception-Vektoren. Diese beginnt bei der MC68000-CPU an Adresse 0. Alle anderen Prozessoren der 68000er Familie können die Exception-Vektor-Tabelle jedoch an eine beliebige gerade Adresse des Speichers transportieren, die in einem Zusatzregister der CPU, dem »Vector Base Register (VBR)« festgelegt ist. Aus Gründen der Kompatibilität zu bestehenden vektorverbiegenden Programmen wird dieses Register auf dem »Atari TT« unter TOS nicht verwendet und enthält demzufolge immer den Wert null. Andere Betriebssysteme können das VBR jedoch sehr wohl nutzen.

Die obersten 4 Bit (das oberste »Nibble«) des Format-Words enthalten den »Format Code« der Exception (daher der Name). Der Wert sagt aus, wie viele Werte die CPU bei der aufgetretenen Exception insgesamt auf dem Stack gelegt hat. Die meisten Exceptions und alle Interrupts sowie sämtliche Traps unter ihnen benutzen den Format-Code 0, der besagt, daß keine weiteren Werte auf dem Stack gesichert wurden. Einige Exceptions verursachen jedoch weitere Werte auf dem Stack, auf die das Format-Code-Nibble hinweist. Genauere Informationen enthält ein empfehlenswertes Buch aus dem Hause Addison-Wesley [2].

Unermüdlich haben wir auch in diesem Monat an »GEM's last secret« der wind_update()-Funktion gearbeitet. Und es gibt tatsächlich Neues. Mehrere Programmierer richteten sich mit der Frage an uns, weshalb verschiedene AES-Funktionen in Accessories Fehler produzieren, in Hauptprogrammen aber ordnungsgemäß funktionieren. Beispielsweise neigen viele »graf_...«-Funktionen zu Abstürzen in Accessories. Die AES-Funktionen wurden als fehlerhaft abgestempelt. Doch weit gefehlt! Der Grund für die bis dato unerklärlichen Abstürze war ein fehlerhaftes »wind_update()«-Handling der Accessories. Wie sich nämlich herausstellte, kollidieren Funktionen wie »graf_dragbox()« oder »graf_watchbox()« mit dem Maushandling des GEM-Screen-Managers. Dieser übernimmt normalerweise die Maussteuerung eines Programms. Wenn ihm ein Accessory dazwischenpfuscht und beginnt, ebenfalls Mausfunktionen zu kontrollieren, gerät das System erschwert durcheinander: zwei Prozesse, die eine Maus kontrollieren, bereiten ähnliche Probleme wie zwei, die unkoordiniert auf den Bildschirm schreiben.

Glücklicherweise hilft auch bei diesem Problem der GEM-Schupo wind_update() [3]. Mit einem wind_update (BEGMCTRL); beansprucht ein Accessory oder Programm alleiniges Nutzungsrecht für die Maus und sperrt damit die Mauskontrolle durch den Screen-Manager. Nun können Funktionen wie »graf_dragbox()« auch in Accessories fehlerfrei ausgeführt werden. Nach Beendigung des Vorgangs geben Sie die Mauskontrolle mit wind_update( ENDMCTRL); wieder an den Screen-Manager zurück.

Frohe Kunde

In der Januar-Ausgabe des ST-Magazins berichteten wir über einen Fehler im wind_update()-Handling des TT-Desktops [4]. Entgegen allen bisherigen Erfahrungen ist unsere Fehlermeldung diesmal bei Atari in die richtigen Hände geraten: Der Desktop des brandneuen TOS 3.05 geht mit wind_update() wieder korrekt um.

(uw)

Literaturverweise:

[1] J. Reschke, »Ans EinGEMachte«, ST-Magazin 10/89, Seiten 60f, Markt & Technik Verlag
[2] S. Williams, »68030 Assembly Language Reference«, Addison-Wesley Publishing Company, ISBN 0-201-08876-2
[3] L. Prüßner, »GEM-Verkehrsplanung: Aktion sauberer Bildschirm«, ST-Magazin 11/89, Seiten 68 ff., Markt & Technik Verlag
[4] L. Prüßner, »Nachschlag mit Trick«, ST-Magazin 1/91, Seiten 118f., Markt& Technik Verlag

Dieses Listing zeigt, wie Icons auch in verschiedenen Auflösungen unverzerrt auf dem Monitor erscheinen