----------------------------------------------------

Kapitel 4

Player-Missile-Graphiken

----------------------------------------------------

Animation ist eine wichtige Fähigkeit eines jeden Personal Computer Systems. Sie erhöht die Begeisterungsfähigkeit und den Realismus eines Programms. Noch wichtiger aber ist, daß ein bewegtes Bild mehr Information mit größerer Klarheit übertragen kann, als ein stehendes Bild. Durch Bewegung eines Objektes wird die Aufmerksamkeit des Benutzers hierauf gezogen. Ein dynamischer Vorgang wird durch Animation deutlicher, als wenn er indirekt beschrieben wird. Animation ist logischerweise entscheidend für die Wirkung vieler Computerspiele. Animation muß folglich als ein wichtiges Element der Graphikmöglichkeiten eines Computers angesehen worden.

Der normale Weg, Animation zu erreichen, ist, die Bilddaten durch den Bereich des Bildschirm-RAMs zu bewegen. Dieses erfordert einen 2-Stufen-Prozess. Als erstes muß das Programm das alte Bild löschen, indem es Hintergrund (Farb-) -Werte in den Bereich schreibt, der das augenblickliche Bild enthält. Danach müssen die Bilddaten in den RAM-Bereich geschrieben werden, welcher der neuen Bildposition entspricht. Durch wiederholtes Ausführen dieses Vorgangs erscheint auf dem Bildschirm ein sich bewegendes Bild.

Bei dieser Technik tauchen allerdings zwei Probleme auf. Erstens: wird die Animation mit größeren Pixeln ausgeführt, so ist die Bewegung nicht mehr "gleitend"; das Bild bewegt sich ruckartig über den Schirm. Bei vielen Computern besteht die einzige Lösung dieser Schwierigkeit in der Wahl kleinerer Pixel (höhere Auflösung). Das zweite Problem ist allerdings weit wichtiger. Der Bildschirm ist ein zweidimensionales Gebilde, wogegen der gesamte (und damit auch der ihm zugehörige) RAM-Bereich eindimensional organisiert ist. Das bedeutet, daß Objekte, welche auf dem Schirm nebeneinander liegen, im RAM nicht hintereinander liegen. Abbildung 4.1 verdeutlicht dieses.

          Bild                 Entsprechende

                          Bytes im RAM-Bereich

     00 00 00

     00 99 00

     00 BD 00

     00 FF 00

     00 BD 00

     00 00 00

     Verteilung der Bild-Bytes im RAM

Abbildung 4.1

Bilder auf dem Schirm liegen im RAM nicht hintereinander

Die Bedeutung dieses Umstandes wird erst offensichtlich, wenn man ein Programm zum Bewegen eines solchen Bildes schreibt. Um die im RAM verstreuten Bytes zu löschen, muß das Programm ihre jeweilige Adressen berechnen. Diese Berechnung ist im allgemeinen nicht sehr einfach. Ein Assembler-Programm, das auf ein einzelnes Byte an der Bildschirmposition XPOS, YPOS zugreift, sieht wie folgt aus (es wird eine Zeilenlänge von 40 Zeichen vorausgesetzt):

LDA  SCRNRM    Anfangsadresse des Bildschirm-RAMs

STA  POINTR    Zero-Page-Zeiger

LDA  SCRNRM+1  Höherwertiges Byte der Adresse

STA  POINTR+1  Höherwertiger Zeiger

LDA #$00

STA  TEMPA+1   Zwischenregister

LDA  YPOS      Senkrechte Position

ASL  A         Mal 2

ROL  TEMPA+1   Schiebe ‹bertrag nach TEMPA+1

ASL  A         Mal 4

ROL  TEMPA+1   Schiebe ein weiteres Mal

ASL  A         Mal 8

ROL  TEMPA+1   Schiebe erneut

LDX  TEMPA+1   Speichere YPOS mal 8

STX  TEMPB+1   in TEMPB

STA  TEMPB     Niederwertiges Byte

ASL  A         Mal 16

ROL  TEMPA+1

ASL  A         Mal 32

ROL  TEMPA+1

CLC

ADC  TEMPB     Addiere zu YPOS x 8 um YPOS x 40 zu erhalten

STA  TEMPB

LDA  TEMPA+1   Nun bearbeite das höherwertige Byte

ADC  TEMPB+1

STA  TEMPB+1

LDA  TEMPB     TEMPB enthaelt den Offset vom oberen

CLC            Bildschirmrand zum Pixel

ADC  POINTR

STA  POINTR

LDA  TEMPB+1

ADC  POINTR+1

STA  POINTR+1

LDY  XPOS

LDA  (POINTR),Y

Es ist klar, daß dieses Programm zu "schwerfällig" zum Zugriff auf eine Bildschirmadresse ist. Dieses ist also nicht die schnellste und eleganteste Methode, um das Problem zu lösen; ein guter Programmierer könnte allerdings das Programm mit Hilfe von speziellen Schaltungen verdichten und kompakter machen. Der springende Punkt hierbei ist aber, daß das Zugreifen auf Pixel auf dem Schirm sehr viel Berechnung benötigt. Die obere Routine braucht ungefähr 100 Maschinenzyklen, um auf ein einziges Bildschirm-Byte zuzugreifen. Um ein Bild zu bewegen, das eine Größe von 50 Bytes besitzt, würden 100 solcher Zugriffe benötigt, was 10.000 Maschinenzyklen oder ca. 10 Millisekunden entspricht. Dieses klingt nicht nach viel, aber wenn eine gleitende Bewegung erreicht werden soll, muß ein Objekt alle 17 Millisekunden bewegt werden. Werden nun noch andere Objekte bewegt oder Berechnungen ausgeführt, dann hat der Prozessor nicht mehr viel Zeit, um diese zu bearbeiten. Hinzu kommt allerdings noch, daß diese Art der Animation (sog. "Playfield"-Animation: Playfield = Spielfeld) für viele Zwecke zu langsam ist. Animation kann natürlich trotzdem auf diesem Wege erreicht werden, sie muß dann allerdings auf wenige (oder kleinere) Objekte oder langsamere Bewegung beschränkt werden. Die bei dieser Art der Animation vom Programmierer zu machenden Abstriche sind also schwerwiegend.

Die ATARI-Computer-Lösung dieses Problems sind die sogenannten "Player-Missile" Graphiken. Um diese Graphik-Möglichkeit zu verstehen, ist es wichtig, daß der Leser das grundsätzliche Problem der Playfield-Animation begreift: das Bild auf dem Schirm ist zweidimensional, wogegen das Bild im RAM eindimensional ist. Die Lösung dieser Schwierigkeit besteht in der Schaffung eines Bildes, das sowohl im RAM, als auch auf dem Bildschirm eindimensional ist. Dieses Objekt, genannt Player, erscheint im RAM als ein 128 bzw. 256 Bytes großer Bereich. Dieser Bereich wird aus dem Speicher direkt auf den Bildschirm projeziert. Es erscheint auf dem Bildschirm als ein senkrechtes Band, das vom oberen bis zum unteren Rand reicht. Jedes Byte dem Bereichs entspricht entweder einer oder zwei Horizontal Scan Lines. Diese Auswahl trifft der Programmierer. Das Bild auf dem Schirm ist ein einfacher bitweiser Auswurf der Daten dieses Speicherabschnittes. Besitzt ein Bit in diesem Bereich den Wert 1, so leuchtet das entsprechende Pixel auf der Mattscheibe; enthält es den Wert 0, so ist das Pixel dunkel. Player-Bilder sind also nicht strikt eindimensional; sie sind 8 Bits breit.

Das Zeichnen eines Players auf dem Schirm ist sehr einfach. Als erstes muß das gewünschte Bild auf kariertem Papier entworfen werden. Dieses Bild darf allerdings nicht breiter als 8 Pixel sein. Danach wird das Bild in Binär-Code umgesetzt, d.h. für jedes erleuchtete Pixel wird eine 1 notiert; für jedes dunkle Pixel eine 0. Die so entstehende Zahl wird in eine Dezimal- oder Hexadezimalzahl übersetzt, abhängig davon, was dem Programmierer vertrauter ist. Schließlich werden die Bilddaten in den Player-RAM-Bereich geschrieben, wobei das erste Byte des Player-Bildes oben und das letzte unten im Speicher steht (d.h. bei niedriger bzw. höherer Adresse). Je weiter unten die Bilddaten innerhalb des entsprechenden Bereichs im RAM plaziert werden, desto weiter unten erscheint das Bild auf der Mattscheibe.

Die Animation dieses Bildes geht sehr einfach von statten. Senkrechte Bewegung wird erreicht, indem die Bilddaten durch den RAM-Bereich geschoben werden. Dieses ist im Prinzip die gleiche Methode, die auch bei der Playfield-Animation verwendet wird. Es gibt allerdings einen großen Unterschied: die Bewegungsroutine für senkrechte Bewegung ist eine eindimensionale, anstelle einer zweidimensionalen Bewegung. Das Programm muß zur Errechnung der senkrechten Position des Objektes die Zeilenlänge berücksichtigen, und es wird nur sehr selten von indirekter Adressierung Gebrauch gemacht. Ein Programm für diese Aufgabe könnte folgendermaßen aussehen:

     LDX #$01

LOOP LDA PLAYER,X

     STA PLAYER-1,X

     INX

     BNE LOOP

Diese Routine benötigt ungefähr 4 Millisekunden, um den gesamten Player zu bewegen; das entspricht fast der halben Zeit, die die Playfield-Animation benötigt. Weiterhin bewegt die Playfield-Animation nur 50 Bytes, wogegen die obige Routine 256 Bytes verschiebt. Wenn noch höhere Geschwindigkeiten nötig sind, könnte die Schleife darauf ausgerichtet werden, nur die Bild-Bytes selbst (anstelle des gesamten Players) zu bewegen; eine solche Schleife würde leicht eine Ausführungszeit von 100 bis 200 Mikrosekunden erreichen. Der maßgebliche Punkt bei dieser Art der Animation ist, daß senkrechte Bewegung der Player sehr viel einfacher ist als mit Playerfield-Objekten.

Einfacher noch als die senkrechte Bewegung eines Players ist dessen waagerechte. Es gibt für jeden Player ein Register, daß als "Horizontal Position"-Register bezeichnet wird. Der Wert in diesem Register legt die waagerechte Position des Players auf dem Bildschirm fest. Um einen Player an eine bestimmte Bildschirmposition zu bringen, muß lediglich der entsprechende Wert in dieses Register geschrieben werden.

Waagerechte und senkrechte Bewegung eines Players sind voneinander unabhängig; sie können beliebig miteinander kombiniert werden.

Die Einheit für das Horizontal-Position-Register ist das Color Clock. Wird der Wert des Registers um 1 erhöht, dann bewegt sich der Player um ein Color Clock nach rechts. Es gibt 228 Color Clocks in einer einzelnen Scan Line, von denen aber aus Gründen des Overscans nicht alle sichtbar sind. Abhängig vom Overscan des jeweiligen Fernsehgerätes befinden sich die Positionen 0 bis 44 außerhalb des linken, und die Positionen 220 bis 255 außerhalb des rechten Bildschirmrandes. Die sichtbaren Player-Positionen liegen zwischen den Stellen 44 bis 220. Dieses kann manchmal Probleme aufwerfen, eröffnet aber eine praktische Möglichkeit: um den Player vom Bildschirm verschwinden zu lassen, muß seine waagerechte Position auf 0 gesetzt werden. Durch einfaches Laden und Speichern (mit POKE in BASIC) wird der Player unsichtbar.

Das soweit beschriebene System macht Animation mit hoher Geschwindigkeit möglich. Es sind allerdings noch einige zusätzliche Anmerkungen zu machen. Als erstes gibt es vier voneinander unabhängige Player. Jeder dieser Player besitzt einen eigenen RAM-Bereich; d.h. ihre Operationen sind voneinander völlig unabhängig. Die Player besitzten die Label (Bezeichnungen) P0 bis P3. Sie können nebeneinander benutzt werden, um eine Auflösung bis zu 32 Bits (in der Breite) zu liefern, oder um einzelne Objekte darzustellen.

Jeder Player besitzt weiterhin ein eigenes Farbregister, das unabhängig von allen anderen (Playfield- oder Player-Farbregister) die Farbe des Players bestimmt. Dieses Farbregister wird mit COLP(X) bezeichnet und besitzt eine Schattenadresse mit dem Namen PCOLR(X). Dieses gibt dem Benutzer die Möglichkeit, mehr Farbe auf den Bildschirm zu bringen. Jeder Player besitzt allerdings, da für jeden nur ein Register vorhanden ist, eine Farbe; mehrfarbige Player sind nur mit Display Liest Interrupts möglich (siehe Kapitel 5).

Jedem Player wird außerdem ein Register zur Festlegung seiner Breite zugeordnet. Er kann auf einfache, doppelte und vierfache Breite gesetzt werden. Dieses geschieht mit dem SIZEP(X)-Register.

Schließlich kann die senkrechte Auflösung vom Benutzer gesteuert werden. Es gibt eine Auswahl zwischen Einzel-Zeilen- und Doppel-Zeilen-Auflösung. Bei ersterer legt ein Byte des Speicherbereiches das Aussehen einer Scan Line fest; bei Doppel-Zeilen-Auflösung das Aussehen von zwei Scan Lines. Bei Einzel-Zeilen-Auflösung ist der Speicherbereich für einen Player 256 Bytes lang, bei Doppel-Zeilen-Auflösung 128 Bytes lang.

Dieses ist auch der einzige Fall, bei dem die einzelnen Player voneinander abhängig sind; die senkrechte Auslösung gilt für alle Player. Sie wird durch Bit D4 des DMACTL-Registers bestimmt. Bei Doppel-Zeilen-Auflösung befinden sich die ersten 10 Bytes des Bereiches außerhalb des oberen und die letzten 20 Bytes außerhalb des unteren Bildschirmrandes. Bei Einzel-Zeilen-Auflösung sind es entsprechend 20 und 40 Bytes, die verlorengehen.

Die nächste Erweiterung liegt in den sogenannten Missiles. Dieses sind 2-Bit breite Graphik-Objekte, ähnlich den Playern. Jeweils eine Missile wird einem Player zugeordnet; sie erhält ihre Farbe aus dem entsprechenden Farbregister des Players. Das Aussehen einer Missile wird ebenfalls in einem bestimmten RAM-Bereich festgelegt. Dieser liegt genau vor dem RAM-Bereich der Player. Alle Missiles befinden sich innerhalb des gleichen Bereichs (4 Missiles mit jeweils 2 Bits sind zusammen 8 Bits). Missiles können unabhängig von den Playern bewegt werden; sie besitzen ihre eigenen Horizontal-Position-Register. Außerdem besitzen Missiles ein eigenes Register für die Größe (SIZEM), das genauso wie das SIZEP(X)-Register für die Player funktioniert. Dieses Register gilt allerdings für alle Missiles, d.h. sie werden immer auf die gleiche Breite gesetzt.

Missiles können als Kugeln oder dünne senkrechte Linien auf dem Bildschirm benutzt werden. Wenn erforderlich, können die Missiles zu einem fünften Player zusammengesetzt werden, wobei dessen Farbe dann durch das Farbregister für Playfield 3 bestimmt wird. Dieses wird durch Setzen des Bits D4 des Prioritäten-Kontroll-Registers (PRIOR) erreicht. Die Missiles können natürlich auch in dieser Option unabhängig voneinander bewegt werden, da ihre Positionen von den zugehörigen Horizontal-Position-Registern gesteuert werden. Das "Einschalt-Bit" für den 5. Player beeinflußt nur die Farbe der

Missiles.

Eine senkrechte Bewegung der Missiles wird wie bei den Playern erreicht: durch Schieben der Bilddaten durch den zugehörigen RAM-Bereich. Hierbei können sich allerdings Probleme ergeben, da die Missiles, wie schon angesprochen, in ein- und demselben Bereich stehen. Um also eine Missile senkrecht zu bewegen, müssen die Bits der anderen ausmaskiert werden.

Eine wichtige Fähigkeit der Player-Missile-Graphik ist die absolute Unabhängigkeit der Player und Missiles vom Playfield.

Diese Objekte können mit jedem Graphik- oder Textmodus gemischt werden. Dieses wirft wiederum ein Problem auf: was geschieht, wenn ein Player oder eine Missile sich mit einem Playfield-Objekt überschneidet? Welches Bild hat Vorrang? Hierfür gibt es ein sogenanntes Prioritäten-Kontroll-Register, mit dem es dem Programmierer möglich ist, diese Vorrangigkeit zu definieren. Dieses Register wird mit PRIOR bezeichnet und besitzt eine ‹bertragungsadresse, genannt GPRIOR. Durch diese Auswahlmöglichkeit können interessante Effekte erzeugt werden indem ein Player vor einem und hinter einem anderen Playfield-Objekt vorbeiläuft.

Die letzte Erweiterung liegt in der Lieferung der sogenannten Kollisions-Abfrage (Collision Detection = Kollisions- Erfassung), die über die Hardware läuft. Es ist hiermit möglich zu prüfen, ob ein Objekt (Player oder Missile) mit irgendeinem anderen (Player, Missile oder Playfield) zusammengestoßen ist. Genaür gesagt, können folgende Kollisionen erfaßt werden: Missile - Player, Missile - Playfield, Player - Playfield, Player - Player sowie Player - Missile. Es gibt 54 Möglichkeiten solcher ‹berschneidungen, denen jeweils ein Bit zugeordnet wird. Dieses Bit enthält eine 1, wenn eine zugehörige Kollision auftrat. Die Bits befinden sich in 15 CTIA-Registern (wobei jeweils nur die unteren Nybbles benutzt werden). Diese Register sind Nur-Lese-Register, d.h. sie können nicht durch Nullschreiben gelöscht werden. Letzteres geschieht, indem irgendein beliebiger Wert in das HITCLR-Register geschrieben wird, wodurch dann alle Kollisions-Register gelöscht werden.

Hardwaremäßig wird eine Kollision durch die ‹berschneidung von zwei Bildern, z.B. Player und Playfield, verursacht; das bedeutet, das Kollisionsbit wird erst gesetzt, nachdem der Teil des Bildschirmes, auf dem sich die ‹berlappung ereignet, gezeichnet wurde. Eine Kollision wird daher frühestens 16 Millisekunden nachdem der Player bewegt wurde, registriert. Die beste Lösung ist, eine Abfrage der Kollisionsregister während der Vertical-Blank-Interrupt-Routine (siehe Anhang I) durchzuführen. In diesem Fall sollte als erstes die Kollisions-Abfrage durchgeführt, dann die Register gelöscht und schließlich der Player bewegt werden. Es kann allerdings auch 16 Millisekunden gewartet werden, bevor die Kollisions-Register abgefragt werden.

Es gibt eine Anzahl von Schritten, die für die Benutzung der Player-Missile-Graphiken erforderlich sind. Als erstes muß ein RAM-Bereich für die Player und Missiles vorbereitet werden. Danach wird dem Computer mitgeteilt, wo dieser Bereich sich befindet. Wenn Einzel-Zeilen-Auflösung benutzt wird, ist dieser RAM-Bereich 1280 Bytes lang; bei Doppel-Zeilen-Auflösung ist er 640 Bytes lang. Ein guter Platz für diesen ist das RAM direkt vor dem Display-Bereich am Anfang des Speicherbereiches. Das Layout des Player-Missile-Bereiches wird in Abbildung 4.2 dargestellt.

Abbildung 4.2

Layout des Player-Missile Bereiches im RAM

Der Zeiger, der auf den Anfang des Player-Missile Bereiches zeigt, wird mit PMBASE bezeichnet. Aufgrund der internen Beschränkungen ANTICs muß PMBASE bei Einzel-Zeilen-Auflösung an einer 1K-Grenze und bei Doppel-Zeilen-Auflösung an einer 2K-Grenze liegen. Werden nicht alle Player benutzt, ist es vorteilhaft, den restlichen RAM-Bereich wieder für andere Zwecke zu verwenden. Sobald festgelegt wurde, wo der RAM-Bereich für die Player und Missiles liegen soll, wird ANTIC informiert, indem die Page-Nummer von PMBASE in das PMBASE-Register ANTICs geschrieben wird.

Als nächstes werden die Parameter der Player, z.B. Farbe, horizontale Position und Breite, auf die gewünschten Werte gesetzt. Ebenso können die Prioritäten gesetzt werden. Schließlich muß ANTIC noch über die senkrechte Auflösung informiert werden. Für Einzel-Zeilen-Auflösung wird das Bit D4 im DMACTL-Register gesetzt. Bei Doppel-Zeilen-Auflösung wird dieses Bit gelöscht. Die Schattenadresse von DMACTL trägt die Bezeichnung SDMCTL. Als letztes wird die Player-Missile-Graphik durch Setzen des PM-DMA-Bits in DMACTL aktiviert. Bei diesem Setzen muß darauf geachtet werden, daß die anderen Bits dieses Registers nicht geändert werden. Das folgende Programm ist ein Beispiel für das Aufbauen und Bewegen eines Players.