16-FARBEN-SCROLLING
" Wow!- So bunt und' n irrer Speed!" ;
so in etwa lauteten die Reaktionen auf
die ersten 16- Farben-Bitmaps, die vom
VIC gesteuert über den Bildschirm des
C64 rasten.
Natürlich, wie so oft, waren die ersten
Programmierer, die den Brotkasten einmal
mehr austricksten, Coder aus der Demo-Szene. Zuerst sah man die Bitmaps nur
horizontal " tanzen", doch richtig beeindruckend wurde es durch die Vertikal-Bewegung, durch das sog.' Linecrunching' was soviel wie ' Zeilen-Komprimierung' bedeutet.
In Spielen setzte sich der Trick nur
sehr träge durch. In den beiden " Stormlord"- Games waren zwar bunte Pixels am
Scrollen, doch war dies durch gesamtes
Neuaufbauen und Umschalten zwischen zwei Screens realisiert worden." Phobia", ein
altes Baller-Spektakel bediente sich
des Horizontal-Tricks, um beim Scrollen
( ein Charakter+$ d800- Farbram-Scroller) Prozessor-Zeit zu sparen. Selbiger
Trick, allerdings schon für bunte
Bitmaps, wurde in " Eskimo Games" verwendet und " Another World" lief sogar
mit Linecrunching-Scrolling, allerdings
nur horizontal. Sogar " Creatures" wartete mit Bitmap-Scrolling auf, doch
nur im Miniatur-Format um die Level-Übersich darzustellen. Das Spiel selbst
scrollte wieder in normalen Character-Modus. . .
Wir sehen, daß sich der Trick mit dem
bunten 8- Wege-Scrolling in Spielen noch
nicht manifestieren konnte. Warum, wo
die Schwierigkeiten und Hindernisse
liegen, welche Möglichkeiten es gibt, sie zu überwinden und wo letztendlich
die Grenzen des C64 in diesem Bereich
liegen, das versuche ich in diesem Kurs zu übermitteln.
Folgender ist in 3 Teile unterteilt:
Teil I: Einführung, Theoretisches
Teil II: Beispiel und Dokumentation anhand des Source-Codes
Teil III: Praxis, Einbinden des Codes in eigene Programme, Arbeiten
mit dem " Bitmap-Manager" .
Da zur Einleitung eigentlich alles erwähnt wurde, wollen wir nun zum Theoretischen kommen. Um diesen Kurs mehr oder
weniger erfolgreich zu absolvieren sind
als Vorraussetzung recht gute Assembler-Kenntnisse sowie Erfahrung mit dem VIC
des C64 mitzubringen. Ich werde mich
aber bemühen, dieses doch recht umfangreiche Thema so einfach wie möglich, und
vor Allem für jeden verständlich zu
erläutern.
Beim Thema Bitmap-Grafik- Scrolling ist
immer die Rede von einem Trick. Ja
logisch, oder ? Beim ' normalen' Scrollen
im Character-3- Farben-Modus ist lediglich beim Überlauf eines der beiden
Scroll-Register der Screen-Inhalt um
ein Zeichen zu verschieben. Im Grafik-Modus sieht' s da ganz anders aus: Zu
verschieben sind die gesamte Bitmap, der Screen und das Farbram, also insg.
knapp 10 KB. Kurz gesagt für einen C64 mit einer Taktfrequenz von 1 Mhz ist
das flüssige Scrolling einer solchen
Daten-Menge schier unmöglich. . .
. . . doch - da war doch dieses eine Demo, mit dem großen bunten Logo, das da in
alle Richtungen flog, so schnell und
flüssig, Sprites wurden auch noch dargestellt; als ob Bitmap-Scrolling noch
weniger Prozessor-Zeit schlucken würde, als übliches Scrolling.
UND GENAU DAS (!) IST ES.
Am C64 gibt es eine Möglichkeit, den
Bildschirm ohne enormen Rasterzeit-Verlust in alle Richtungen zu bewegen, als ob man die Start-Werte links oben
für Textund Grafik-RAM selbst wählen
kann. Wer sich am Amiga auskennt, der
weiß, daß es dort durch Register ganz
einfach ist, die Start-Werte links
oben für die Grafiken zu bestimmen;
ab jetzt auch für den C64 ! ! !
Gut, Haupt-Register der Scroll-Routine
ist das Register $ d011( wer öfter mit
dem VIC herumexperimentiert, weiß, daß
jenes Register bei den meisten Tricks
und Effekten ( FLI, FLD, . . .) die Haupt-Regie führt) .
Grundlegend ist das $ d011- Register wie
folgt belegt:
Bit 0-2 . . . Softscrolling ( Werte 0-7) Bit 3 . . . . .1=24 Zeilen,0=25 Zeilen
Bit 4 . . . . .0= Screen off,1= Screen on Bit 5 . . . . .0= Charmode,1= Bitmapmode Bit 6 . . . . .1= Extended Colourmode Bit 7 . . . . .8 . Bit von Reg.$ d012( Raster)
Wichtig ist es zu wissen, daß der VIC
sich jede 8 . Rasterzeile ( im Bereich des
Textes/ der Grafik), und zwar zu Beginn
jeder Cursor-Zeile, Informationen aus
dem Bildschirm-Inhalt holt um die Cursor
Zeile korrekt darzustellen. In welchen
Raster-Zeilen dies geschieht, hängt davon
ab, welche Werte das Reg.$ d011 in den
ersten 3 Bits aufweist. Und genau diese
Abhängigkeit von Scroll-Register $ d011 zum Neu-Initialisiern jeder neuen Cursor
Zeile des VIC macht die Sache so enorm
interessant. . .
Durch genaues Timing ist es nämlich
möglich, das Neu-Initialisieren einer
Zeile durch den VIC zu verzögern, indem
man den $ d011- Scrollwert gerade dann
verändert, wenn eine Cursor-Zeile z. B.
erst halb aufgebaut ist und im selben
Frame ( Rahmen =1 Rasterdurchlauf) wieder auf den ursprünglichen Wert von
zuvor zurücksetzt. Der VIC baut nämlich
eine neue Zeile immer erst dann auf, wenn die ersten 3 Bits aus Reg.$ d011 mit
den ersten 3 Bits von Reg.$ d012( Rasterzeilen- Y-Position) übereinstimmen. So
ist die Y-Position der Cursor-Zeilen- Initialisierung linear zum $ d011- Scroll-Register auf 8(0-7) Werte flexibel.
Nebenbei sei erwähnt, daß der Prozessor
dadurch in jeder 8 .( eben in dieser!) Rasterzeile um einige Taktzyklen weniger
Rechenzeit hat, da diese vom VIC " abgezwickt" werden um Werte für die Cursor-Zeilen Initialisierung und Darstellung
aus dem Bildschirm-Inhalt zu holen. Dies
berührt uns im Moment zwar wenig, ist
aber für das spätere ' Linecrunchen' von
großer Bedeutung da dort Timing auf
Zyklen genau verlangt wird.
Gut, da wir nun wissen, wie der VIC arbeitet und auf welche Weise er vorgeht, um Cursor-Zeilen ( egal ob Grafik oder
Text) darzustellen, könnte man auf die
sinnlose Idee kommen, durch Austimen mit
dem $ d012- Register ganze Cursor-Zeilen
bereits darzustellen, obwohl die Zeile
zuvor in ihrer Darstellung nicht abgeschlossen war. Das hieße, eine Zeile
sozusagen " künstlich" zu platzieren.
Es ist zwar nicht ganz so einfach, wie es
klingt, das mit dem " künstlichen Platzieren", denn es ist bei Tricks mit dem
$ d011- Register viel Erfahrung, Geduld
und vielleicht auch ein wenig Glück notwendig, doch ist dieses Grundschema der
getimtem Zeilen-Initialisierng der ( !) Baustein beim Bitmap-Scrollen und Linecrunchen.
Zuerst möchte ich das Scrolling in der
Horizontalen erklären:
Wir wissen: Der Bildschirm wird 50 mal
pro Sekunde neu aufgebaut. Ein Ganzbild
besteht aus 312 Rasterzeilen. Dabei
jagt der Elektronenstrahl jede Zeile
von links nach rechts, um die Partikel
zum Leuchten zu bringen. Nach der 312 .
Zeile wird der Strahl wieder nach links
oben gesetzt, dadurch entsteht die sog.
vertikale Austastlücke ( es gibt auch
eine horiz. Austastlücke, bedingt durch
das Zurücksetzen des Elektronenstrahls
nach links, wenn er den rechten Rand
erreicht hat) .
Um nun den VIC zu überlisten, müssen wir
einfach einen Zustand produzieren, in
welchem er eine neue Cursor-Zeile aufzubauen beginnt. Diesen Moment wählen
wir so, daß der Elektronenstrahl gerade
über den sichtbaren Bereich rast. Wenn
er nun das Kommando für den Aufbau einer
neuen Cursor-Zeile erhält, stellt er
diese sofort dar, auch wenn der Strahl
sich gerade z. B. in der Bildschirm-Mitte befindet. So produzieren wir eine " versetzte" Darstellung des gesamten Screen-Inhaltes, ab der Rasterzeile, in der wir
den VIC überlisten.
Wie weit der Inhalt nun nach rechts verschoben wird ( der Bereich, der rechts
hinausgeschoben wurde, wird übrigens und
logischerweise links, eine Zeile tiefer, wieder sichtbar), hängt von der horiz.
Position des Elektronenstrahls ab. Da
ein Prozessor-Takt (1 Mhz) genau der Zeit
entspricht, die der Strahl für die Darstellung von 8 Hires-Pixel braucht, kann
man also mit geschicktem Austimen des
Opcodes den Bildschirm-Inhalt cursorschrittweise verschieben. Das X-Soft- Scrolling erledigt ohnehin Reg.$ d016, und schon funktioniert der Trick mit dem
Horizontalen Bildschirm-" Wanken" !
Das Vertikalscrolling oder Linecrunching
funktioniert ein wenig( !) komplizierter.
Gesagt sei nur kurz, daß dabei beliebig viele Cursor-Zeilen nach oben unsichtbar
" zusammengestaucht" werden, um den Bildschirm, wie zuvor nach rechts, diesmal
nach oben zu versetzen. . .
Programmierer, für welche dieses Gebiet
absolut Neuland ist, sollten sich durch
das viele Theoretische nicht verwirren
lassen. Im Teil 2 wird der dokumentierte
Source-Code für Klarheit sorgen. . .
(hs)
