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 "Bit-
map-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 2x2 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 er-
stellen. Beim anwählen der Pages ändert
sich die Rahmen-farbe mit, das heißt,
daß jede Page seine bestimmte Farbe an-
zeigt. Somit ist das Arbeiten im Field-
Editor leichter, da in diesem das voll-
stä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 40x20 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, "re-
defined" Format gebracht wird (der Bild-
schirmrand 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 ent-
steht.
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 ver-
wenden, dann ist folgende Schrittfolge
anzuwenden:
Zuerst speichern wir die Grafik(Squares)
als "redefined Grafics" ab (Bereich von
$2000 bis $3f3f). 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 beeinflus-
sen...
...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 (line-
crunching) werden 7 Sprites (X-und
Y-expanded) dargestellt. Die Koordi-
naten,Blöcke und Farben werden im
Programm initialisiert. Durch ge-
zieltes Ändern ist diese Gestaltung
selbst frei einzurichten (die Y-
Koordinaten müssen allerdings gleich-
bleiben; Timing!).
2.Das Programm arbeitet in einem Haupt-
und einem Interrupt-Teil. Der Haupt-
teil wartet immer wieder darauf, ob
neue Zeilen aufgebaut werden müssen.
Im Interrupt werden die Tasten abge-
fragt, 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 Haupt-oder 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 ver-
ankert wurde (in die Area wird das
Square also auf jeden Fall geschrie-
ben).
4.Gescrollt wird, indem man die ge-
wü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 wer-
den 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 ein-und 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 $47f8. Gewöhnlich
ist dieser Bereich frei verfügbar, da
der Text-Bildschirm nur einen Bereich
von 1000 Bytes braucht (also bis $47d7).
Doch durch das Linecrunching kommt
dieser sonst unsichtbare Bereich auch
zum Vorschein, da der VIC bei der Dar-
stellung des Screens dort fortsetzt, wo
er aufgehört hat (also bei $47d8, und
erst nach $47ff springt er zu $4400 zu-
rü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)
