★ APPLICATIONS ★ PROGRAMMATION ★ Spritzige Sprites ★ |
| RSX Sprite (Happy Computer) | Applications Programmation |
Nur wenige Bytes Maschinencode erlauben extrem schnelle Bildschirmausgaben. Da haben sogar die Sprites des Commodore 64 das Nachsehen. Vorsicht - Feind von rechts! Das kleine Männchen rast mit ungeheuerlicher Geschwindigkeit auf unsern Held in der Mitte des Bildschirms zu. Und dabei nähern sich von oben noch zwei fliegende Untertassen - ganz zu schweigen von den Wogen des turkistanischen Meers auf Xylon. Je mehr Bewegung auf dem Bildschirm, desto besser ist ein Spiel. Software wirkt um Längen professioneller, wenn die Bildausgabe nur Bruchteile einer Sekunde dauert. Bei den Schneider-Computern der CPC-Serie wird der Bildschirm bei der Zeichenausgabe mit sehr komplexen und leistungsfähigen Betriebssystemroutinen angesprochen. Diese sind dadurch natürlich sehr lang - und dementsprechend langsam. Die meisten Konkurrenzprodukte unterscheiden zwischen einem Text-und einem Grafikmodus. Bei Schneider gibt es nur den Grafikmodus. Jeder einzelne Buchstabe und jedes Grafikzeichen wird als Punktmuster in den Bildschirm geschrieben. Dabei wird unter anderem auf Windows und Farben geachtet, zwischen zu druckenden und Steuerzeichen unterschieden und was der Dinge mehr sind. Ferner sind alle Routinen so geschrieben, daß sie in allen Bildschirmmodi gleichermaßen arbeiten. Alle Programme, die eine direkte Ansteuerung des Bildschirms verlangen, laufen deshalb auf einem Schneider-Computer sehr langsam ab. Wer sich bereits einmal daran versucht hat, ein Spiel mit viel Bewegung auf dem Schneider zu realisieren, der weiß davon ein Lied zu singen. Ganz schlimm wird es, wenn Sie versuchen, Zeichen direkt vom Bildschirm zu lesen (beispielsweise beim 664/6128 mit COPYCHR$). Mit den hier vorgestellten Sprite-Routinen lösen sich viele Programmierprobleme wie von selbst. Zunächst wird das verwendete Sprite-Konzept vorgestellt. Ein Sprite ist ein 8x8 Punkte großer Bildschirmbereich und entspricht damit im Modus 1 genau einem Zeichen. Da in diesem Modus jeder Punkt auf dem Bildschirm durch zwei Bit dargestellt wird, braucht man für ein Sprite 128 (=8x8x2) Bit Speicherplatz (Bild 1). Die gleiche Struktur haben alle Buchstaben, die im Modus 1 auf den Bildschirm gebracht werden. Das Betriebssystem geht dabei von einer 8x8-Schablone für jedes Zeichen aus. Diese Schablone wird je nach Schriftfarbe in das entsprechende Bit-Muster für die Bildschirmausgabe umgerechnet. Zudem wird aber jedesmal auch noch die effektive Adresse des Zeichens im Video-RAM aus der X- und Y-Position des Cursors bestimmt. Das kostet ebenfalls viel Rechenzeit. Bei unseren Sprite-Routinen verzichten wir auf alle diese rechenintensiven Vorgänge. Die Anweisung erwartet das fertige Bitmuster aus 16 Byte. Diese werden mit einer sehr kurzen und daher extrem schnellen Routine direkt in den Bildspeicher geschrieben. Im Modus 1 gibt es 1000 Zeichen auf dem Bildschirm (40x25), somit auch 1000 erlaubte Sprite-Positionen. Sprites können also nur an solche Positionen geschrieben werden, an denen bei der normalen Textausgabe Buchstaben erscheinen. In der Praxis ist das nur ein kleiner Nachteil. Die Steuerung der Sprites erfolgt mit den zwei Kommandos PUT und GET. Beide sind sehr ähnlich aufgebaut. Listing 1 zeigt den Assembler-Quellcode der beiden Routinen. Listing 2 ist das gleiche Programm als Basic-Lader. Das Maschinencode-Programm ist voll relokatibel, das heißt, es darf unverändert an jede beliebige RAM-Adresse gestellt werden. Bewußt wurden PUT und GET nicht als RSX-Anweisungen konzipiert. RSX-Aufrufe sind vergleichsweise langsam, da das Basic bei jedem RSX zuerst alle angeschlossenen ROMs nach dem Befehl durchsucht. Unser Aufruf soll aber möglichst wenig Zeit brauchen. Der Aufruf über CALL ist genauso komfortabel - vorausgesetzt, man definiert gleich zu Anfang die Variablen PUT und GET als Startadresse beziehungsweise Startadresse plus 2. Um vom Basic-Programm aus bequem mit den Sprites zu arbeiten, holen sich die Maschinencode-Programme PUT und GET die Sprite-Daten aus dem Speicherbereich der Stringvariablen. Mit anderen Worten: Sprites werden in Strings gespeichert. Jeder Sprite-String muß exakt eine Länge von 16 Byte haben. Solch ein String muß deshalb von dem Programm definiert werden, bevor es zum Aufruf der Sprite-Routinen kommt. Da die Information für die Sprites reine Bit-Muster sind, lassen sich solche Sprite-Strings mit der PRINT-Anweisung nicht auf dem Bildschirm ausgeben. Beim Aufruf von PUT und GET müssen die Ausgabeadresse und die Adresse des Sprite-Strings angegeben werden. Die Ausgabeadresse ist einfach die Nummer des Zeichens auf dem Bildschirm im Modus 1 (Bild 2). Die Adresse des Sprite-Strings wird durch den Operator »@« gewonnen. Um beispielsweise das Sprite X$ an den Anfang der zweiten Bildschirmzeile (also an Position 40) zu schreiben, müssen Sie in Ihr Programm »CALL PUT,40, @X$« schreiben. Um das erste Zeichen der letzten Zeile aus dem Bildschirm in einen Sprite-String mit dem Namen HILF$ zu lesen, geben Sie »CALL GET,960,@HILF$« ein. Ein paar Dinge beachten Sie bitte bei der Arbeit mit den Sprites:
Im Listing 3 finden Sie ein Unterprogramm in Basic, das Sprites aus DATA-Zeilen erzeugt. Die ersten Zeilen zeigen dabei gleich ein Demonstrationsprogramm zum Einsatz von Sprites. Der Sprite-Generator wird mit »GOSUB 60000« aufgerufen, nachdem der DATA-Zeiger mittels »RESTORE« auf die gewünschte Zeile gesetzt wurde. Jeweils 8 DATA-Zeilen zu je 8 Zeichen definieren ein Sprite. Die Ziffern 0, 1, 2 und 3 innerhalb einer solchen Zeile stehen für die vier im Modus 1 erlaubten Farben. Statt der Null ist auch ein Leerzeichen (Space) zulässig. Die Basic-Routine erzeugt aus den DATA-Anga-ben die Sprite-Binärwerte und speichert den entsprechenden Sprite in der Variablen SPRITES. Da sich mit GET nicht nur Original-Sprites, sondern beliebige Zeichen aus dem Bildschirm in einen Sprite-String einiesen lassen, ist es sehr einfach, jedes Zeichen des Schneider-Zeichensatzes in ein Sprite zu verwandeln. Hierzu dient beispielsweise das Programm aus Listing 4.
|
