16-FARBEN-SCROLLING
Teil III
Endlich! Diesmal wollen wir das Ding mit
der $ d011- Trickserei hinter uns bringen.
Als Krönung dazu befindet sich der " Bitmap- Manager" auf der Diskette. Dieser
Editor verwaltet Grafik-Areas für die
Routine des dok. Scroll-Source- Codes der
vorigen Ausgabe. Zu Beginn eine kurze
Einführung in das Arbeiten mit diesem
Editor. . .
Mit dem " Bitmap-Manager" lassen sich
Grafik-Backgrounds in einem Format von
100 x 40 Squares gestalten. Ein Square
ist ein Feld der Größe von 2 x2 Cursors.
Insgesamt also eine Area von rund
5 x 4 Screens. Die Squares werden von
einem Grafik-Bild von 40 x 20 Chars
ausgelesen ( z. B. ein normales Koala-Pic
in der Höhe von 20 Chars), womit wir bei 200 verschiedenen Squares wären.
Zu Beginn befindet man sich im Haupt-Menu, in welchem man mit den Cursor-Tasten und Return bestimmte Funktionen
startet. Wenn wir in den Field-Editor
gelangen, gelten folgende Tasten als
funktionstüchtig:
Return,Pfeil links........ins Haupt-Menu
Cursor oder Joystick.....Pointer bewegen
1-8........................Square setzen
Space oder Feuer........Square #0 setzen
F1/F2...................Hintergrundfarbe
F7....................in den Page-Editor
+,-...................Page 0-31 anwählen
shift+clr home...........Area löschen(!)
*...................Sprite-Block-pointer
(die '*'-Funktion wird später noch
genauer erläutert werden...)
Die Squares lassen sich also mit den
Tasten 1-8 setzen, abhängig von der
aktuellen Page. Um nun die Pages zu editieren, gelangen wir mit ' F7' in den
Page-Editor, welcher mit folgenden
Tasten bedient wird:
F7...................in den Field-Editor Cursor oder Joystick.....Pointer bewegen 1-8.............Square in Page schreiben +,-........................Page anwählen
So lassen sich 32 verschiedene Pages erstellen. Beim anwählen der Pages ändert
sich die Rahmenfarbe mit, das heißt, daß jede Page seine bestimmte Farbe anzeigt. Somit ist das Arbeiten im Field-Editor leichter, da in diesem das vollständige Darstellen der 8 Squares einer
Page aus technischen Gründen nicht
möglich ist. Orientierung schafft nur
die Page-Nummer rechts oben und eben
die entsprechende Rahmenfarbe.
NUN GANZ PRAKTISCH:
Wie gestalte ich mein eigenes Demo/ Game?
Zuerst mal wird gemalt. Ein Picture in
der Größe 40 x20 Cursors, welches alle
200 Squares repräsentiert. Abgespeichert
wird im Koala-Format. Nun läßt sich
dieses Bild mit dem " Bitmap-Manager" laden, wonach es in das richtige," redefined" Format gebracht wird ( der Bildschirmrand flackert kurz) .
So, nun kann' s schon mit der Field-Gestaltung losgehen. Zuerst mal die
Pages zusammenstellen. Am Besten die
Squares, die in Verbindung miteinander
stehen ( ganze Grafik-Elemente), in die
gleiche Page bringen. Jetzt zurück in
den Field-Editor und den Background
designen. . .
Hat man sich einmal an das Prinzip mit
den Pages und dem 1-8- Modus gewöhnt, läuft das Gestalten so richtig schnell
und macht Spaß. Vor Allem dann, wenn
man schon weiß, wo bestimmte Squares sind, die man z. B. öfter braucht, was
nach einer gewissen Zeit sowieso entsteht.
Gut, die Area ist abgeschlossen und wir
begeben uns wieder ins Hauptmenu. Dort
speichern wir vorsorgend gleich die
Pages und die gesamte Area ($ c000-$ cfa0) . Beim Wiederbearbeiten einfach
die Grafik, Area und Pages reinladen, und losgeht' S ( die Pages haben also nur
für den Editor Bedeutung) !
Wollen wir ernst machen und den gesamten
Background für ein eigenes Projekt verwenden, dann ist folgende Schrittfolge
anzuwenden:
Zuerst speichern wir die Grafik( Squares) als " redefined Grafics" ab ( Bereich von
$2000 bis $3 f3 f) . Bevor wir nun die
Routine starten ( ich rede vom Sourcecode
der letzten Ausgabe von Kurs Teil 2), laden wir die Area ($ c000) normal und die " redefined Grafic"( gespeichert ab
$2000) nach $ e000 in den Speicher. Wenn
wir jetzt die Routine starten, haben
wir nicht viel Unterschied zum Editor, da die Routine ( vom Sourcecode) dem
Editor ähnlich ist. Aber wir befinden
uns schon mal im Assembler und können
die ganze Sache entscheidend beeinflussen. . .
. . . ab hier ist jeder Programmierer auf
sich selbst angewiesen. Man sollte sich
ein wenig in den Code einarbeiten und
herumexperimentieren. Ein wenig Tips
und Hilfe möchte ich hier aber noch
auflisten:
1 . Im schwarzen, oberen Bereich ( linecrunching) werden 7 Sprites ( Xund
Yexpanded) dargestellt. Die Koordinaten, Blöcke und Farben werden im
Programm initialisiert. Durch gezieltes Ändern ist diese Gestaltung
selbst frei einzurichten ( die Y- Koordinaten müssen allerdings gleichbleiben; Timing!) .
2 . Das Programm arbeitet in einem Hauptund einem Interrupt-Teil. Der Hauptteil wartet immer wieder darauf, ob
neue Zeilen aufgebaut werden müssen.
Im Interrupt werden die Tasten abgefragt, die Softscreenmoving-Routine
aufgerufen sowie ins Linecrunching
verzeigt. Wird nun im Hauptprogramm
gerade eine Cursor-Zeile aufgebaut, wird der Vorgang meist, denn er dauert
eine gewisse Zeit, vom Interrupt
unterbrochen.
Also: Routinen, die alle 1/50 Sekunde
stattfinden müssen, werden einfach in
den Interrupt eingabaut. Dabei ist zu
beachten, daß nicht zuviel Rasterzeit
verbraucht wird, da das Linecrunching
zur bestimmten Rasterzeile unbedingt
stattfinden muß. Wenn die freie Zeit
zuwenig ist, einfach den Raster-IRQ- Einsatz um ein paar Zeilen verfrühen,
und sozusagen vom Hauptoder Aufbau-Programm etwas abzwicken.
3 . Im Sourcecode befindet sich eine
Routine mit dem Namen " SET PIECE" .
Wenn ein Square auf den Bildschirm
gestzt wird, muß sie aufgerufen
werden. Die " set piece"- Routine ist
sehr praktisch: Sie prüft, ob das
Square, welches gesetzt wird, im
sichtbaren Bereich liegt oder nicht.
Wenn ja, wird es in die angezeigte, aktuelle Bitmap geschrieben. Wenn
nicht, dann nur als Byte in der Area
festgehalten, d. h. wenn dorthin
gescrollt wird, wird jenes Square
angezeigt, da' s ja in der Area verankert wurde ( in die Area wird das
Square also auf jeden Fall geschrieben) .
4 . Gescrollt wird, indem man die gewünschten Werte direkt in den Opcode
der Screenmoving-Routine schreibt.
Die Labels heißen " mo1"-" mo4" . Also
um nach oben zu scrollen, den Soft-Wert nach " mo1+1" schreiben und die
Routine Screenmoving aufrufen. Die
Werte können von 0-8 liegen und werden nach jedem Aufruf automatisch
gelöscht.
Zum Schluß möchte ich noch auf einen
kleinen " Hindernis"- Umstand eingehen, welchen ich oben zu Beginn dieses
Kurs-Teiles angesprochen habe. Es geht
um den Sprite-Blockpointer- Bereich, welcher sich im Editor durch die "*"- Taste und im Sourcecode mit der Return-Taste einund ausschalten läßt ( diese
8 nebeneinanderliegenden ( phew!) Cursor-Bytes " flashen" dann) .
Bekanntlich belegen die Blockpointer für
die Sprites die letzten 8 Bytes des
aktuellen Text-Bildschirms. In unserem
Beispiel liegt dieser ab $4400, die
Blockpointer also ab $47 f8 . Gewöhnlich ist dieser Bereich frei verfügbar, da
der Text-Bildschirm nur einen Bereich
von 1000 Bytes braucht ( also bis $47 d7) .
Doch durch das Linecrunching kommt
dieser sonst unsichtbare Bereich auch
zum Vorschein, da der VIC bei der Darstellung des Screens dort fortsetzt, wo
er aufgehört hat ( also bei $47 d8, und
erst nach $47 ff springt er zu $4400 zurück) .
Dies ist auch der Grund, warum beim
Linecrunchen der Bereich auch in X-Richtung versetzt auftaucht, nämlich
genau um diese 24 Bytes/ Cursors!
Um mit diesem Umstand keine " Troubles" zu bekommen, läßt man jene Cursors
einfach leer oder vom Screen-Colour- RAM
unbeeinflußt ( nur $ d800- Farb-RAM!) .
Wenn man auf Sprites über der Scroll-Area verzichtet, stellt sich selbiges
Problem ohnehin nicht.
Mein letzter und vielleicht wichtigster
Tip lautet:
Durchbeißen!
Durchbeißen!
Durchbeißen!
. . . und NIIIIIEEMALS aufgeben!
(Hannes Sommer,'93)
