Das vierte Level - Kompatible Spieleprogrammierung, Teil 4: Spiele auf Graflkkarten; alternative Treiberkonzepte

Teil 1: Richtlinien und Blick auf andere Rechnersysteme
Teil 2: Grundregeln zur hardwarenahen Programmierung
Teil 3: Kompatible Spiele unter MultiTOS
Teil 4: Spiele auf Graflkkarten; alternative Treiberkonzepte

Brot und Spiele

Kompatible Spieleprogrammierung

Teil 4: Spiele auf Grafikkarten; alternative Treiberkonzepte

Der letzte Teil dieser Artikelserie befaßt sich besonders mit grafikkartenkompatibler Spieleprogrammierung. Außer einigen Exoten, die meist im PD-Bereich angesiedelt sind und durch mäßige Grarik auffallen, gibt es wohl keine Spiele, die auch auf Grafikkarten laufen. Allerdings sind hier zur Abwechslung nicht die Programmierer der Spiele daran schuld, sondern die ziemlich widrigen Umstände.

So dürfen auf Mac-kompatiblen Rechnern die Programmierer sogar direkt auf den Grafikspeicher zugreifen, weil das Format (wie schon im Teil 1 erwähnt), in der die Planes im Bildspeicher angeordnet sind, von Apple festgelegt wurde und sich jeder Kartenhersteller an diese Konventionen hält. Daher ist es dann im Prinzip egal, ob es sich um ein On- Board- oder ein externes Videosubsystem handelt.
Allen ATARI-Anwendern, die keinen Falcon haben, werden bestimmte Spiele vorenthalten; selbst dann, wenn sie eine Grafikkarte haben, die ein Vielfaches vom Falcon-Videosubsystem leistet. Das ist allerdings kein Geschwindigkeitsproblem, denn der 68030 im Falcon hat, wie einige Mac-Rechner auch, "nur" einen 16-Bit-Datenbus zum RAM (obwohl der 68030 ein 32-Bit-Prozessor ist), so daß ein TT oder ein entsprechend beschleunigter MEGA ST mit guter Grafikkarte unter Umständen genauso schnell oder schneller als ein Falcon030 auf seinen Grafikspeicher zugreifen kann. Der fehlende DSP bei ST/STE/TT spielt vielfach nur eine untergeordnete Rolle, da dieser meist nur für edle Soundeffekte benötigt wird, auf die man im Notfall auch verzichten kann. Das Hauptproblem der Spieleprogrammierer liegt in der uneinheitlichen Hardware der Grafikkarten und, was noch schlimmer ist, der uneinheitlichen Schnittstelle zu Funktionen der Grafikkarte, die nicht via VDI angesprochen werden können. So unterstützen nur die wenigsten Treiber das ...

Umschalten auf andere Bildschirmseiten

Für wirklich flackerfreie Animationen ist eine Umschaltmöglichkeit auf andere Bildschirmseiten sehr wichtig. Ansonsten kann es vorkommen, daß man während Updates des Bildschirms mittels Rasterkopierbefehl sieht, wie z.B. die obere Hälfte des horizontal scrollenden Hintergrunds schon ein Pixel weitergescrollt ist. Das passiert, weil während des Aufbaus des Bildes auf dem Monitor nur die eine Hälfte des neuen Bildschirminhalts in den Speicher der Karte übertragen wird. Auch kleineren Objekten kann dieses Schicksal zuteil werden, wobei es hier schon genügen würde, wenn man Kopieroperation mit dem VBL synchronisieren könnte.

VBL-Sychronisation

Aber auch das Synchronisieren mit dem VBL ist auf keiner der mir bekannten Grafikkarten möglich. Sicherlich ist das mehr ein Hardware-Problem, da die häufig an die ATARI-Rechner angepaßten VGA-Karten keine Möglichkeiten bieten, das VBL-SIgnal hardwaremäßig abzufragen und es somit nicht möglich ist, einen VBL-Intenupt zu erzeugen. Das fällt bei diesen Karten z.B. durch seltsam verschwindende Mauszeiger auf, obwohl auf dem Bildschirm gar keine Zeichenoperationen stattfinden. Allerdings gibt es auch einige Graf n, bei denen ein Hardwaresprite als Mauszeiger eingesetzt wird, wobei dieser Effekt dann natür]ich nicht auftritt. Nun ist es in den meisten Fällen möglich, den VBL in irgendeinem Register der Karte zu pollen (ständig abfragen), so daß man wenigstens die XBIOSFunktion Vsync(), die auf den VBL wartet implementleren konnte. An sich kein Problem, wenn man bedenkt, daß alle (mir bekannten) Treiber für Grafikkarten sowieso die XBIOS-Aufrufe Setscreen(), Phys. base() und Logbase() abfangen. Die Vsync() Funktion würde zumindest ermöglichen, "kleine" Updates des Bildschirminhalts flackerfrei durchzufahren.

Auf Karten flackert's nicht so!

Andererseits arbeiten die meisten Karten - zumindest ab dem 256 Farbmodus – im Packed-Pixel-Format, in welchem die Planes für ein Pixel direkt hintereinander (gepackt) liegen, z.B. entspricht bei 256 Farben ein Byte einem Pixel. Bei Kopieroperationen werden daher alle Planes auf einmal übertragen, also kein Flackern, wie man das beim internen Videosubsystem (weil hier die Planes einzeln übertragen werden) gewöhnt ist. Das wiederum vereinfacht es, Spiele, die in Fenstern laufen, so wie im Teil 3 beschrieben zu programmieren.

Auch hier gilt es für den verzierten Programmierer, wirkungsvolle, auf bestimmte Oberflächen abgestimmte und kompatible Lösungen auszuarbeiten. Eine kompatible Lösung ist in diesem Fall, alle Ausgaben mit dem VDI vorzunehmen und unter Umständen sogar die Möglichkeit zu bieten, das Spiel im Fenster laufen zu lassen. Das funktioniert immer, die Bildausgabe ist möglicherweise nicht ganz so perfekt. Eine Alternative dazu wäre dann eben, falls die Grafik auf dem internen Videosubsystem dargestellt wird, auf die übliehe Weise (siehe [2]) zwischen mehreren Bildschirmspeicherseiten hin- und herzuschalten. Zusätzlich kann das Spiel noch die erweiterten Funktionen von Treibern für Grafikkarten unterstützen, um auch dort zwischen Speicherseiten hin- und hergehalten zu können. Solange die Entwickler von Treibern noch keine gemein- same Schnittstelle für Sonderfunktionen, wie z.B. Umschalten der dargestellten Bildschirmseite, geschaffen haben, bleibt den Programmierern von Spielen wohl keine andere Wahl, als selbst so viele Plattformen wie möglich zu unterstützen und eine weniger ideale Lösung anzubieten, die eben überall läuft.

Alternative Treiberkonzepte

Wie bisher gesehen, gibt es auf ATARI-Rechnern einige Probleme, Grafik und Sound mit der auf der Hardware möglichen Qualität systemkonform anzusprechen. Das Betriebssystem in ST/STE/TT bietet standardmäßig nur Funktionen an, um die drei Stimmen des YAMAHA-Soundchips anzusprechen. Die dabei zu erreichende Ausbeute an Klang ist recht mager, weil der Chip auf diesem Weg weder digitalisierte Klänge abspielt, noch Filter auf seine rechteckige Wellenform (übrigens die Einzige) legen kann. Auch kann man nur eine Hüllkurve festlegen, welche dann für die Stimmen jeweils an- oder ausgeschaltet werden kann. Der Falcon030 kann da via Betriebssystem schon wesentlich mehr, aber zum einen sind die Aufrufe Falcon-DMA-spezifisch, und zum anderen muß man schon den DSP programmieren, um dem System mehr als nur eine Stimme (wenn auch in Stereo) ohne direktes Programmieren der Hardware zu entlocken.
Das sogenannte "Page-switching" (Wechseln der auf dem Bildschirm darzustellenden Speicherseite) ist via Betriebssystem nurbeimintemen Videosubsystem möglich. Die Hersteller von Grafikkarten haben mehr oder weniger unterschiedliche Schnittstellen, um dem Programmierer solche Sonderfunktionen zugänglich zu machen. Nun, an dieser Stelle möchte ich Vorschläge machen, wie Treiber für solche erweiterten Grafik- und Soundfunktionen auszusehen hätten, so daß sie den Ansprüchen von Spieleprogrammierern genügten. Übrigens, diese Funktionen sind sicherlich auch für Multimediaanwendungen interessant.

Soundtreiber

Ein solcher Treiber ließe sich sicherlich recht gut als Device-Treiber für MINT bzw. MultiTOS programmieren, da es ähnliches schon unter UNIX oder Windows gibt.
Generell ist für den Benutzer solcher Treiber folgendes wichtig:

Voreinstellen sollte man können, falls möglich:

Der Programmierer eines solchen Treibers sollte versuchen, einen mehr oder weniger leistungsfähigen Sampler zu emulieren. Die Verarbeitung der Daten könnte im MIDI(Musical Instruments Digital Interface)-Format erfolgen, wobei Einstellen/Abfragen der möglichen Stimmen, Abspielfrequenz, Mono/Stereo, 8/16 Bit etc. als System- Exclusive-Daten erfolgen könnte. Noten werden wie üblich als 'Note on'- und 'Note Off'-Befehle an den Treiber übergeben. Allerdings sollten alle Treiber dieselben System-Exclusiv-Daten verstehen können. Die Samples müssen von dem Device (systembedingt) in einen eigenen Speicher geladen werden, die Übertragung der Samples könnte im MIDI-Sample-Dump-Standard (was relativ aufwendig zu implementieren ist) und/oder in einem eigenen Format erfolgen. Im eigenen Format könnten auch gleich solche Daten wie Name, Hüllkurve, Filter, Format etc. übertragen werden. Das Device hätte dann auch die Möglichkeit, beirn Laden der Samples dessen Format zu wandeln. Diese Lösung wäre hardwareunabhängig. Man könnte unter Umständen sogar ein externes MIDI-fähiges Gerät ansteuern. Nur die Übertragung der Samples an einen über MIDI verbundenen Sampler würde, wegen der extrem langen Wartezeiten (ca. 31 kbaud), die Geduld des Benutzers auf eine harte Probe stellen. Allerdings gibt es mittlerweile auch Sampler, mit denen man die Sample-Daten auch via SCSI übermitteln kann.

Grafiktreiber

Laut [G] sollte man darauf bedacht sein, Spiele für eine Auflösung von 6401480*256 Farben zu schreiben. Die üblieben Grafikkarten auf dem ATARI-Sektor haben ca. 1 MB Videospeicher zur Verfügung. Da ein Bildschirm der oben genannten Auflösung 300 KB Speicher benötigt, ist auf einer solchen Karte fdr mehr als 3,4 solcher Bildschirme Platz, was für die meisten Anwendungen, Animationen und Spiele vollkommen ausreichend ist. Es hat also durchaus Sinn, einen Treiber, der 'Page switching' ermöglicht für Grafikkarten zu fordern; aber nur dann, wenn ein Treiber mit gleicher Funktionalität auch fürs interne Videosubsystem implementiert würde. In diesem Fall wäre es für den Programmierer egal, auf welcher Grafik-Hardware sein Spiel läuft; er müßte sich allein auf den Treiber einstellen, der ja auf jeder Hardware die gleiche Schnittstelle zu den benötigten Funktionen bietet. Am günstigsten wäre wohl eine Betriebssystemerweiterung, die folgendes ermöglicht:

Eine Funktion wie Hardwarescrolling auf einem virtuellen Bildschirm wäre zwar nett und auf den meisten Karten ebenfalls zu emulieren, aber nicht unbedingt nötig. Das Allozieren von Video-RAM könnte durch einen erweiterten Mxalloc() erfolgen. Hier ein Vorschlag dafür:

void *Mxalloc(LONG amount, WORD Mode);

Werte für Mode
Bits 0-2

0: ST-RAM
1: alternatives RAM
2: ST-RAM bevorzugt
3: alternatives RAM bevorzugt (neu!)
4: Screen PAGE

Wenn Mode auf [4] gesetzt wird - dann wenn 'amount' auf [-1] gesetzt wird.

Mxalloc() gibt die Menge der möglichen Video-RAM-Seiten in amount zurück oder [0] im Fehlerfall, wenn amount auf [<0] gesetzt wird, bekommt man die Startadresse einer Seite geliefert oder [0] im Fehlerfall.

Wenn eine Video-RAM-Seite von einem Programm angefordert wird, kann bis zum Freigeben durch Mfree() diese Seite durch kein anderes Programm verwendet werden. Ein Treiber für das interne Videosubsystem würde den benötigten Speicher vom ST-RAM anfordern. Auch dieser Speicherbereich kann natürlich erst dann wieder genutzt werden, wenn er durch Mfree() freigegeben wurde.

Das Umschalten auf andere Bildschirmseiten ...

... könnte durch Setscreen() (Physbase) erfolgen, wobei auf Grafikkarten andere Werte als die von Mxalloc() erhaltenen nicht zur Umschaltung führen würden.

Die Synchronisation mit dem VBL ...

... würde, wie schon weiter oben erwähnt, via Vsync() erfolgen. Andererseits erfolgt die Umschaltung auf die neue VideoRAM-Seite auf den meisten Karten (z.B. denen mit Videochips vom Typ ET4000) sowieso erst beim nächsten VBL. Mit drei Bildschirmseiten wäre es dann leicht möglich, wirklich flackerfreie Animationen zu erzeugen, wobei eine Seite gerade bearbeitet, eine Seite beim nächsten VBL dargestellt und die letzte der drei Seiten gerade gezeigt wird.

Zu guter Letzt

Ich kann jetzt nur noch hoffen, daß meine Worte auf fruchtbaren Boden fallen und mehr Spiele in Zukunft so programmiert werden, daß es nicht mehr wichtig ist, was für einen ATARI-Rechner man besitzt, sondern, daß man Oberhaupt einen hat!
Konstruktive Kritik und Fragen bitte per E-Mail an: POLLACK@RZ.FH-FRANKFURT.D400.DE

_ [1] Thomas Binder, Gamefix,
Falcon030 wird ST(E)-kompatibel,
ST-Computer 11/93
[2] Klaus-Dieter Pollack,
Spiele selbst programmieren,
erschienen zu CeBit 1993 im Heim Verlag,
ISBN 3-928480-13-8
[3] Falcon030 Developer Documentation,
ATARI Oktober 1992
[41 Jorgo Schimanski,
Spieleprogrammierung in Assembler auf dem Amiga,
erschienen 1991 im Heim Verlag,
ISBN 3-928480-01-4
[5] RISC OS, Programmers Reference Manual
Acorn Computer Limited 1989,
ISBN 1-86250-060-3
[6] Archimedes (Sonderheft der 64er),
erschienen im Markt na Technik Verlag
[7] Two Tribes,
ein schachähnliches Action-/Strategiespiel,
welches voraussichtlich irgendwann 1995
erhältlich sein wird und auf allen TOS
kompatiblen Rechnern laufen wird.
[8] Jankowski, Rabich, Reschke,
ATARI ST-STE- TT Profibuch,
erschienen 1991 im Sybex Verlag,
ISBN 3-88745-888-5
[9] Martin Huber, Nova Treiber ab Vers. 2. 0
[10] Sven und Wilfried Behne, NVDI ab Vers. 2.5
[11] Sven und Wilfried Behne, Enhancer ver. 1.0
[12] Steve Williams,
68030 Assembly Language Reference,
erschienen 1989 im Adisson Wesley Verlag,
ISBN 0-201-08876-2
[13] MC 68040 User's Manual, Motorola 1989
[14] James F. Foley, van Dam, Feiner, Huges,
Computer grafics: principles und practice,
Adisson Wesley,
ISBN 0-201-12110-7
[15] Gerd Respondek, Farblose Darstellung, c't 11/91


Klaus-Dieter Pollack
Aus: ST-Computer 02 / 1995, Seite 72
Links
Copyright-Bestimmungen: siehe Über diese Seite