von Bernd Dongus Ja, ja, ja. Ich weiß es. Ich sagte, ich hätte meinen letzten Artikel verbrochen. Doch man hat mich mit Geld zu einem weiteren gezwungen. Ernsthaft. Ich habe mich mal wieder vor meinen 8-Bit gesetzt um ein Erfolgs- erlebnis zu haben. Im Vorspann des Spiels ALTERNATE REALITY ist ein 'Weltraum-Effekt' zu bewundern. Eine abgespeckte Version des hier erzeugten Sternenhimmels erkor ich zu meinem Ziel aus. Die erste Frage, die zu beantworten war, lautet : Wie läßt sich ein Stern beschreiben ? - Er hat X-/Y-Koordinaten - Er bewegt sich in beide Richtungen - Für jede Richtung hat er eine Geschwindigkeit - Je 'näher' er dem Betrachter ist, desto schneller ist er. Er besitzt also eine Beschleunigung. Mit einem Stern allein fällt der ganze Effekt aber noch etwas kümmerlich aus. Man benötigt also Tabellen, die die Stern-Daten zwischenspeichern. Dies wird von folgenden Tabellen übernommen: - SPCXTBL, SPCXTBH (X-Position Low/High) - SPCYTBL, SPCYTBH (Y-Position Low/High) - SPCXATB (Beschleunigung X-Richtung) - SPCYATB (Beschleunigung Y-Richtung) - SPCXSTBL, SPCXSTBH (Geschwindigkeit X-Richtung) - SPCYSTBL, SPCYSTBH (Geschwindigkeit Y-Richtung) Es gibt aber noch weitere Faktoren, die beachtet werden müssen. Die Sterne brauchen einen Start- bzw. Mittelpunkt. Weiterhin ist unser Weltraum nach oben, unten, rechts und links begrenzt. Die Anzahl der Sterne, die Begrenzungen und die Startposition werden an die Routine SPCINIT übergeben. Hierbei ist die Anzahle der Sterne auf 32 begrenzt. Die Parameterübergabe geschieht hier auf eine etwas andere, für den Anwender aber bequemere, Art. Die Befehle LDA #SID PHA LDA /SID PHA übergeben den Zeiger auf die Initiali- sierungstabelle SID an SPCINIT. Die nähere Funktionsweise von SPCINIT wird später abgehandelt, denn zuerst müssen noch ein paar grundlegende Dinge geklärt werden. Zum einen dürfte aufgefallen sein, daß die Geschwindigkeiten und die Positionen einen Low- und einen High-Anteil aufweisen, die Beschleunig- ungen aber nicht. Der Grund ist die flüssige Bewegung der Sterne. Die ist nur mit Kommastellen erreichbar. Wird nur mit ganzen Zahlen gerechnet, würden die Sterne ruckelige Bewegungen ausführen und wären viel zu schnell. Nun sind richtige Fließkomma- berechnungen aber sehr zeitintensiv, kommen also auch nicht in Frage. Hier hilft man sich mit einem Trick. Da man keine wissenschaftlichen Berechnungen vor hat, genügen 'ungenaue' Nachkommastellen.Dies wird durch Low- und High-Anteile einer Zahl realisiert. Der Low-Anteil der Daten stellt dabei die Nachkommastellen dar und der High-Anteil die Vorkommastellen. Da bei der Beschleunigung Werte zwischen Null und Eins ausreichen, gibt es hier keine Aufteilung in Low und High. Die Tabellen SPCXATB und SPCYATB enthalten nur Nachkommastellen (Low-Anteile), also Werte 0,... . Als letzte Vorüberlegung muß man wissen, wie man einen Stern bewegt. ... Richtig ! Der Stern muß an seiner alten Position gelöscht und nach der Berechnung der neuen wieder gesetzt werden. Schaut man sich den Quellcode von SPCDEMO.SRC an, so müsste einem der seltsame Anfang des Bildspeichers auffallen. '$6010'. Da ANTIC mit dem überspringen von 4 Kb-Grenzen (hex: $1000-Grenzen) Probleme hat, muß man darauf achten diese Grenze auf einen Zeilenanffang fallen zu lassen. ($6010+102*$28 = $6fff) Doch nun zu den Routinen, die der Aufgabe gerecht werden sollen. Oben sprach ich vom Setzen und Löschen der Sterne. Am Einfachsten tut man sich mit einer Routine, die beides macht, indem der jeweilige Punkt mit dem Befehl EOR an/aus geknipst wird. Dies erledigt die Routine SPCEOR. Hier wird zunächst die Startadresse der anzusprechenden Zeile aus einer Tabelle geholt. Da ein Byte vier Punkte anthält, teilt man die X-Position durch vier und zählt das Ergebnis zur Zeilenadresse dazu. Nun hat man aber nur das Byte im Speicher, welches den Punkt enthält. Zur Ermittlung der richtigen Bits ist der Rest der obigen Division und eine weitere Tabelle nötig. Den Rest stellen die unteren zwei Bit der X-Position dar. Die Tabelle enthält dann jeweils die zu invertierenden Bits. Die Initialisierungs-Routine (SPCINIT) muß, wegen der Parameterübergabe, zuerst die Rücksprungadresse vom Stack holen, um an den zuvor auf dem Stack abgelegten Zeiger heranzukommen. Natürlich ist die Rücksprungadresse wieder auf dem Stack abzulegen, sonst wäre ein Absturz die Folge. Der Zeiger muß auf eine Tabelle mit den Startwerten zeigen. Den Aufbau entnehme man bitte dem Quellcode, im Moment ist dieser nicht so wichtig. Nachdem die Startparameter kopiert wurden, werden die Zeilenadressen ermittelt. Jetzt fehlt nur noch die Hauptsache. Die Sterne. Jeder Stern erhält eine Startposition, Geschwindigkeit, Beschleunigung und wird dargestellt. Das Darstellen der Sterne ist wichtig, da die Animations-Routine zunächst die Sterne löscht. Wären aber noch keine Sterne da, würden sie stattdessen am Anfang der Animations-Routine dargestellt und am Ende wieder gelöscht werden. SPCNEWSTAR übernimmt die Aufgabe für den im X-Register übergebenen Stern die Startpsoition, Richtung, Geschwindig- keit und Beschleunigung festzulegen. Für die Richtung ist nur ein Bit von Nöten. Dieses Bit ist Bit 7 in den Bytes der Tabellen SPCXATB und SPCYATB. Mit 'AND #$BF' wird also dieses Richtungsbit erlaubt und die Beschleu- nigung auf Werte von 0-$3f begrenzt. Sind nun alle Sterne generiert und die grundlegenden Routinen vorhanden (SPCNEWSTAR und SPCEOR), fehlt nur noch die eigentliche Animations-Routine. Sie wurde von mir SPCMOV getauft und wird im VBI (Vertical-Blank-Interupt) aufge- rufen. Um einen Stern zu verschieben, wird er mit einem Aufruf von SPCEOR zunächst an der alten Position gelöscht. Bevor man sich aber an die Berechnung der neuen Position macht, muß man die Beschleu- nigung zur die aktuellen Geschwin- digkeit addieren. Man will ja keinen Stern, der immer gleich schnell fliegt. Die Berechnung der neuen X- und der neuen Y-Koordinaten läuft gleich ab. Bit 7 der Beschleunigungstabelle bestimmt jeweils hoch/runter und links/rechts. Je nach Wertigkeit dieses Bits wird nun die Geschwindigkeit von der aktuellen Position abgezogen oder dazuaddiert. Die so ermittelte neue Position wird auf Überschreiten der Begrenzungen kontrolliert und ggf. wird ein neuer Stern generiert. Nun noch zu zwei Besonderheiten in SPCMOV die einem aufstoßen könnten. Erstens das Ausblenden von BiT 7 beim Beschleunigen. Hier wird ein 'ASL' verwendet. Natürlich kann auch, wie sonst üblich, ein AND #$3F verwendet werden. Der einzige Unterschied dürften allgemmein langsamere Sterne und ein unwesentlich längeres Programm sein. Zweitens sieht es so aus, als ob beim Kontrollieren der Begrenzungen ein 'BCC' zuviel reingerutscht wäre. LDA SPCXTBH,X ADC SPCSXTBH,X BCC ... Das 'BCC' ist nötig, da es sein kann, daß die neue Position im negativen Bereich liegt. Diese Situation läßt sich nur mit diesem zusätzlichen 'BCC' feststellen, denn: -1 wird im Speicher als $ff abgebildet und $ff ist immer >= SPCBORDL, also wird die Grenze nie überschritten. Folge: Ein Stern, der wild über den Bildschirm huscht. So daß wäre es dann mal wieder gewesen. Die Kopf raucht und niemand hat es verstanden. Das ist auch kaum zu erwarten. Wer jedoch ein wenig im Quellcode herumpfuscht, ausprobiert und sich eigene Gedanken macht wird dahinter kommen. Natürlich gibt es andere, schnellere, schönere Lösungen. Aber es ist meine und ich habe sie nirgends abgekupfert. Aber einen anderen Lösungsansatz will ich den Interessierten doch noch geben. Anstelle der Rechnungen mit Beschleunigung, Geschwindigkeit, etc. lassen sich Tabellen einsetzen, die die Flugbahnen bestimmen. So lassen sich die wildesten Effekte erzeugen. Dieser Ansatz hat zwar Vorteile, aber auch einen entscheidenden Nachteil (zumindest für faule Leute, wie mich): Die Flugbahnen der Sterne müssen von Hand errechnet und in Tabellen abgelegt werden !