Das erste Level - Kompatible Spieleprogrammierung (1)
Teil 1: Richtlinien und Blick auf andere Rechnersysteme
Für Programmierer von Anwendungen wie Textverarbeitungen, EBV, Datenbanken u.v.m. ist es selbstverständlich, Programme zu schreiben, welche auf allen ATARIs ihren Dienst verrichten. Auf diese Idee scheinen die meisten Programmierer von Spielen, wie bereits in einem Grundlagenartikel in der ST-Computer [1] erwähnt, noch nicht gekommen zu sein.
Auf einem TT030 läuft leider sehr selten ein neues (auch kaum ein altes) Spiel, und sei es nur aus dem Grund, daß der Programmierer testet, ob es sich um einen Falcon handelt. Auch auf ATARIs mit 68000->= 16MHz-Beschleunigern, die sich nicht auf 8 MHz zurückschalten lassen, hakt oft der Diskettenkopierschutz, oder das Spiel ist einfach zu schnell. Bei 68020/30-Karten sieht es oft noch schlechter aus. Grafikkarten werden von den meisten kommerziell vertriebenen Spielen bislang überhaupt nicht unterstützt.
Diese Probleme habe ich bereits in einem Buch [2] beschrieben, das ich jedem Neuling in Sachen Spieleprogrammierung empfehlen möchte. Allerdings werde ich in dieser Artikelserie noch etwas weiter gehen, und möchte sie als eine Art „Style Guide“ für die Programmierung von Spielen auf TOS-kompatiblen Rechnern verstanden wissen.
Wie stellt sich das ATARI vor?
Die Richtlinien, die in [3] veröffentlicht wurden, habe ich so genau wie möglich übersetzt. Folgende Punkte sollten befolgt werden:
[A] Installierbar auf Festplatte
[B] Sollte in jeder Grafikauflösung gestartet werden können
[C] Der Benutzer sollte mit einer einzelnen ausführbaren Datei konfrontiert werden; zusätzliche Daten, High-Score und andere Dateien sollten sich im zugehörigen Ordner befinden.
[D] Dem Benutzer sollte es möglich sein, das Programm zu beenden und dann das Desktop so wiederzufinden, wie er es verlassen hat.
[E] Verwendung der verbesserten Joysticks für Spiele, welche Joysticks benötigen; die vom Typ CX40 sollen nicht mehr unterstützt werden.
[F] Idealerweise, wenn möglich, sollte das Spiel in einem Fenster laufen, passend für Anwender die Spiele unter einer Multitasking-Oberfläche wie MultiTOS spielen wollen (z.B., um währenddessen eine Datei - via DFÜ - zu übertragen).
[G] Wir erwarten, daß die meisten Anwender in der 640x480x256-Farbauflösung arbeiten. Denken Sie daran.
[H] Wenn Sie den VDI-Aufruf vr_tm_fm() (transform form) benutzen, können Sie leicht Grafikdaten vom Standardformat in das Format der eingestellten Auflösung wandeln.
Die Buchstaben „A“ bis „E“ habe ich hinzugefügt, um im Verlauf des Texts nochmals auf Passagen der Guidelines hinweisen zu können.
Nun hat ATARI zwar damit Richtlinien veröffentlicht, von welchen wohl kaum ein Spieleprogrammierer gehört hat, aber leider keine Hinweise gegeben, wie man diese Richtlinien einhalten kann und wie doch ein gelungenes Spiel zustandekommt. Auch hier möchte ich Lösungen aufzeigen.
Andere Systeme
Nachdem ich mir Anfang 1991 (nach der ersten Preissenkung) einen TT leisten konnte, wurde mir schnell bewußt, wie unsauber die meisten ST-Spiele programmiert waren. Nur ca. 20% der von mir getesteten Spiele konnte man zum Laufen bewegen. Viele meiner Freunde starteten bei mir ihre Games und waren sehr enttäuscht, wenn auch meine diversen Patch-Programme ihren Liebling nicht zum Laufen brachten. Das machte mich stutzig. Da ich selber Spiele programmiere, versuchte ich herauszufinden, wie man diese so erstellt, daß sie auch mit der nächste Generation von Rechnern laufen. Daher beschäftigte ich mich mit der Spieleprogrammierung auf anderen Plattformen.
PC-Kompatible
Der Standard-IBM-kompatible PC mit großer Platte und ET-4000-Grafikkarte hat mit den meisten Spielen, die so unter DOS programmiert werden, keinerlei Probleme. Besitzt man eine Karte mit anderem Chipsatz, kann es bei bestimmten Spielen schon zu Falschfarben bei der Einstellung der Palette und zu Problemen beim Scrolling kommen. Zudem kann es passieren, daß ein Rechner einer bestimmten Konfiguration mit dem Diskettenkopierschutz einiger Spiele Probleme hat, oder daß beim Abspielen digitalisierter Sounds z.B. via Soundblaster-kompatibler Soundkarte der Rechner stark gebremst wird.
Der Hauptgrund hierfür liegt in der Architektur des DOS-Betriebssystems. Man muß bei der Grafikprogrammierung tatsächlich wie in ATARI 400/600XL/800-(XL)- (oder C64er)-Zeiten noch die Hardware per Hand initialisieren. Lösungen sind aber auch hier schon in Sicht: Sogenannte VESA-Treiber ermöglichen es, jetzt schon die Grafikkarten in die entsprechenden SUPER-VGA-Auflösungen zu schalten. Microsoft hat für Windows 4.0 Funktionen (WinG) angekündigt, welche das Programmieren von Spielen vereinfachen sollen. Als Beispiel soll ein „Doom“-ähnliches Spiel unter Windows mit Hilfe dieser Funktionen entwickelt werden (wer Doom kennt, weiß, was das bedeutet).
AMIGA
Die neuesten Versionen des AMIGA OS > 1.3 laufen relativ stabil, und Commodore hat sogar Richtlinien zur Programmierung von Applikationen und deren Oberflächen herausgegeben. Auch kann ein Programm mit Hilfe des Betriebssystems Bibliotheksfunktionen (z.B. einen IFF-Loader) aufrufen, welche zur Laufzeit eingeladen werden. Zudem kann es sich bestimmte Ressourcen des Computers vom Betriebssystem reservieren lassen (z.B. Soundkanäle).
Die Programmierer der meisten AMIGA-Spiele kennen allerdings nur eine OS-Funktion (siehe [4]) und zwar „DISABLE()“ Diese schaltet quasi das System aus, so daß Sie freie Bahn bei der Programmierung der Hardware haben.
Archimedes & Acorn RISC PC
Die Familie der Archimedes-Rechner wird in der Regel mit RISC OS ausgeliefert, einem vollständig in Assembler geschriebenen Betriebssystem. Dieses Betriebssystem ist extrem leistungsfähig, bietet z.B. die Möglichkeit, über sog. „Sprites“ Off-Screen-Bitmaps in jeder Größe und fast jeder Farbtiefe anzulegen und auf diese mit beliebigen Zeichenfunktionen zuzugreifen. Zudem können diese mit einem Multiplikator und Divisor skaliert, mit einer Maske versehen und auf den Bildschirm oder in ein anderes Sprite kopiert werden. Dabei gibt es auch Funktionen, welche es ermöglichen, beim Kopieren die Farbtiefe anzupassen. Man kommt zu dem Schluß, wenn man die Möglichkeiten des Betriebssystems überblickt (welches auch in anderen Bereichen wie Sound- und Interrupt-Verwaltung viele Funktionen bietet), systemkonform auf die Hardware zuzugreifen, dann müßte es ein Leichtes sein, sogar Action-Spiele auf diesem Rechner im Fenster laufen zu lassen. Nur leider scheint das auf diesem Rechner niemand auszunutzen oder ausnutzen zu wollen. Denn es gibt sogar eine deutsche Zeitung [6), welche in einem Assembler-Lehrgang gezeigt hat, wie man direkt auf den Bildschirmspeicher zugreift, obwohl dessen Lage undokumentiert ist und nicht garantiert wird, daß er bei kommenden Rechner-/Betriebssystemgenerationen an gleicher Stelle zu finden ist.
Macintosh
Dort scheint es ideal zu sein. Kaum ein Programmierer hat den Mut, sich den von Apple vorgegebenen Konventionen zu widersetzen. Dies hat nichts mit der mangelnden Kreativität der mit dem Mac arbeitenden Programmierer zu tun oder mit Apples fast zu strengen Vorgaben, sondern damit, daß Apple wirklich alles eindeutig geregelt und festgelegt hat: Die Anordnung der Bitplanes ist in den verschiedenen Farbtiefen eindeutig definiert, so daß sich auch Fremdanbieter von Grafikkarten daran halten und es dem Programmierer von Spielen sogar erlaubt ist, unter Umständen direkt auf den Bildschirmspeicher zuzugreifen. Alle Ressourcen (z.B. Grafik und Sound) des Computers lassen sich über das Betriebssystem ansprechen. Nur, echte „Freaks“, die die Möglichkeiten des Macs so richtig ausreizen können, sucht man bislang vergebens!
Es gibt eine Lösung
Nachdem ich mir die Möglichkeiten zur kompatiblen Programmierung von Spielen auf anderen Rechnersystemen angeschaut hatte, habe ich Diskussionen mit anderen ATARI-fanatischen Programmierern geführt, um Wege zu finden, diese auch unter TOS umzusetzen. Das Resultat meiner Mühen ist ein in der Entwicklung befindliches Spiel [7] und dieser Artikel, der zur Nachahmung und Diskussion anregen soll.
Teil 1: Richtlinien und Blick auf andere Rechnersysteme
Teil 2: Grundregeln zur hardwarenahen Programmierung
Teil 3: Kompatible Spiele unter MultiTOS
Teil 4: Spiele auf Grafikkarten; alternative Treiberkonzepte
Literatur:
[1] Thomas Binder, Game fix. Falcon030 wird ST(E)-kompatibel, ST-Computer 11/93
[2] Klaus-Dieter Pollack, Spiele selbst programmieren, erschienen zur CeBIT 1993 im Heim Verlag, ISBN 3-928480-13-8
[3] Falcon030 Developer Documentation, ATARI Oktober 1992
[4] Jorgo Schimanski, Spiele-Programmierung in Assembler auf dem Amiga. erschienen 1991 im Heim Verlag, ISBN 3-92X480-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 und Technik Verlag
[7] „Two Tribes“, ein schachähnliches Action-/Strategiespiel, welches voraussichtlich irgendwann 1995 erhältlich sein und auf allen TOS-kompatiblen Rechnern laufen wird
Klaus-Dieter Pollack