ftp.uni-stuttgart.de/pub/systems/acorn//Acorn.tar/Acorn/acornet/fun/mags/hl-03-93.arc/!HL-03_93_Text_Tips

Text File | 1993-07-30 | 9KB | 171 lines

ÿÿÿÿÿÿÿÿÿÿ Horizontales Scrolling ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ


Und nun ein Artikel ⁿber das horizontale Scrolling per VIDC, also echtes
Hardware-Scrolling. Und wer kennt sich damit schon besser aus, als der
berⁿhmte ACE (alias Michel Fasen), welcher grandiose Meisterwerke wie das
PowerDemo, Agony-Demo, Beast-Demos, ArkanoidII, etc. geschrieben hat und seit
kurzem begeisterter Hardliner-Leser ist. Mit den Beispielprogrammen zusammen
lΣ▀t sich nun Hardwarescrolling in allen Richtungen relativ leicht
nachvollziehen.

Ich ▄bersetzte Michels Originalartikel und formulierte ihn z.T. noch leicht
aus. Aber ⁿberlassen wir nun dem "Ass" die Arena:


" In der der ersten Ausgabe des Hardliners wurde der wundersch÷ne Begriff
Scrolling nΣher erforscht. Vertiakles Scrolling, um genau zu sein. Aber
natⁿrlich gibt es auch horizontales Scrolling.
Horizontales Softscrolling ist etwas problematisch, da es meistens viel
CPU-Zeit ben÷tigt, um das ganze Bild horizontal zu verschieben. Es gibt
mehrere Arten, horizontalen Softscroll zu machen, wie folgende Beispiele
zeigen. Alle Zeitangaben gelten fⁿr einen 20 MHz ARM3, und in Mode 13.  {Wieso
eigentlich 20 MHz? Das sind rund 5 MHz weniger als ⁿblich.. Ed}

- Lade Byte X und schreibe es nach X-1; wiederhole das 320*256 mal und Du hast
eine Routine, die dann insgesamt 0.065 Sekunden ben÷tigt. Ein VSync dauert
0.02 Sekunden (mit 50 Hz). Diese Methode ist also nicht gerade eindrucksvoll.

- Lade das Langwort X und schreibe es nach X-4; wiederhole das (320*256)/4 mal
und Du hast eine Routine, die 4 mal so schnell wie die obere ist: sie ben÷tigt
jetzt 'nur' noch 0.16 Sekunden, ist aber wiederum nicht immer anwendbar, da
sie gleich um 4 Pixel auf einmal scrollt.

- Lade multiple Langworte (LDM) ab Adresse X und schreibe sie nach X-48 (z.B.
mit R1-R12); wiederhole das ganze (320*256)/48 mal, und nun ben÷tigt die Sache
nur noch 0.0054 Sekunden. Es sind aber wiederum 4 Pixels auf einmal bewegt
worden. Alles in allem ist diese Methode die einfachste zum Programmieren, die
schnellste in der Ausfⁿhrung, und das Scrolling ist auch noch gut zu
gebrauchen.

- Lade multiple Langworte, verschiebe sie intern nach rechts und schreibe die
ganze 'Wurst' zurⁿck. Diese Methode ist dann nicht so schnell wie die vorige
(sie ben÷tigt nun 0.012 Sekunden = 60% CPU-Zeit innerhalb eines 50 Hz VSyncs),
aber sie sehr leicht so zu verΣndern, da▀ sie 1, 2 oder auch 3 Pixel auf
einmal scrollt. Dieses Verfahren arbeitet aber nur aktzeptabel, wenn es gilt,
einen Teilbereich des Bildes zu scrollen, da der ARM2 nicht so schnell wie der
ARM3 ist. Das Beispielprogramm "SoftScroll" zeigt, was mit solchem
Pixel-Softscroll gemeint ist.

Zusammenfassend lΣ▀t sich sagen, da▀ Softscrolling mit weniger als 4 Pixel auf
einmal zu langsam ist, wenn es auf das ganze Bild angewandt wird. Wenn wir
eine wirklich extrem schnelle Methode fⁿr Scrolls wollen, mⁿssen wir wohl den
VIDC und MEMC etwas nΣher untersuchen. Um den folgenden Text voll zu
verstehen, bietet es sich an, den Artikel ⁿber vertikales Scrolling im ersten
Hardliner nachzulesen.
{Ich m÷chte noch anmerken, da▀ viele pixel-scrollende Spiele gar kein
Scrolling anwenden, sondern ihr Bild jedesmal komplett aufbauen, mit rotierten
Hintergrⁿndbl÷cken, etc etc, was natⁿrlich schneller als jeder Softscroll ist,
aber auch wesentlich mehr Speicherplatz ben÷tigt. Aber eigentlich ist das
wieder ein ganz anderes Kapitel (vielleicht ein zukⁿnftiger Artikel im HL?)
und deshalb - Silentium. Ed} [Hey Ed, war das eben ein indirektes Angebot,
mal einen solchen Kurs zu erstellen ? Tim]


Der VIDC benutzt zwei Anzeige-Tabellen, oder auch Einheiten genannt, eine
physikalische, und eine logische.

Die vier physikalischen Register sind:
 - Horizontal Display Start Register  (&8C)
 - Horizontal Display  End  Register  (&90)
 - Vertical   Display Start Register  (&AC)
 - Vertical   Display  End  Register  (&B0)

Die vier logischen Register sind:
 - Horizontal Border Start Register   (&88)
 - Horizontal Border  End  Register   (&94)
 - Vertical   Border Start Register   (&A8)
 - Vertical   Border  End  Register   (&B4)

Die physikalische Einheit legt die physikalische Bildschirmgr÷▀e fest (also
auch, wieviel RAM-Speicher das Bild ben÷tigt). Zu diesem Zweck haben wir einen
Mode 127 erstellt (siehe Diskette), welcher prinzipiell dem Mode 13
entspricht, aber 44x36 Zeichen gro▀ ist, anstatt 40x32. Warum? Nun, an jeder
Seite des Randes wurden 16 Pixel hinzugefⁿgt, was zwei Zeilen bzw. zwei
Spalten extra an den vier RΣndern entspricht. Warum wir das brauchen, wird
nachher erklΣrt.
Wo genau das Bild auf dem Monitor erscheint, wird durch die physikalischen
Register bestimmt. Wenn wir nun beide horizontalen Register "Display Start"
und "Display End" jeweils um 1 erniedrigen, so wird das gesamte sichtbare Bild
um 2 Pixel nach links geschoben (um 2 Pixel deshalb, da der VIDC nur in
Einheiten von geraden Pixel-Zahlen programmiert werden kann).

Die logische (sichtbare) Bildschirmgr÷▀e ist durch die logischen Register
festgelegt. Wenn der "Border" (Border-Register) vor dem "Display"
(Display-Register) beginnt, so stellt der VIDC einen Border dar  {den jeder
sicherlich noch vom CPC her kennt. Ed} . Wenn der Border nach dem Display
beginnt, wird der "Fehlbereich" einfach schwarz dargestellt. Das gilt fⁿr
oben, unten, links und rechts, also alle vier RΣnder.

Wir wollen diese Theorie an einem kleinen Beispiel aus der "realen Welt"
nachvollziehen: Nehmen wir ein grⁿnes Papier der Gr÷▀e 12x12 cm (ein blaues
funktioniert theoretisch auch ;-). Dann ben÷tigen wir noch ein Bild der Gr÷▀e
10x10 cm, und ein schwarzes Papier der Gr÷▀e 14x14 cm. Aus dem schwarzen
Papier schneiden wir ein Rechteck der Gr÷▀e 7x7 cm aus. Nun legen wir das
grⁿne Papier auf den Tisch, dann das Bild darauf. Und zuletzt legen wir das
schwarze Papier (mit dem Loch) ganz oben drauf, und zwar so, da▀ wir den Tisch
nicht im Loch sehen k÷nnen.
Was bedeuten diese drei BlΣtter? Das grⁿne Blatt soll dem Monitor entsprechen.
Das Bild stellt die physikalische Einheit dar (das "Display"), und das Loch im
schwarzen Papier soll der logischen Einheit, dem "Border", entsprechen. Auf
dieses Beispiel werden wir gleich nachher noch einmal zurⁿckgreifen.

In unserem Mode 127 haben wir Folgendes gemacht: Die physikalische Gr÷▀e ist
44x36 Zeichen, wΣhrend die logische Gr÷▀e nur 40x32 Zeichen ist (wie im Mode
13). D.h. da▀ 16 Pixel jeweils oben, links, rechts und unten nicht angezeigt
werden, obwohl sie vom Bildschirmspeicher her gesehen dennoch da sind.
Warum um alles in der Welt sollten wir solch einen Modus ben÷tigen? Nun, diese
Technik alleine gesehen kann schon in Spielen eingesetzt werden, und zwar beim
Clipping: Weil es 32 Bytes (=Pixels) extra Speicher pro Rasterlinie gibt (16
links + 16 rechts), die NICHT angezeigt werden, aber physikalisch vorhanden
sind, brauchen wir alle kleineren Sprites ( <=32 Pixels) horizontal nicht mehr
zu clippen. Der Verlust an Speicher (19 K) ist nichts im Vergleich zur
Geschwindigkeit, die wir beim Malen von Sprites gewinnen (mit optimierten
Algorithmen, die nicht zu clippen brauchen).


Wie aber k÷nnen wir diese Technik anwenden, um an unser horizontales
Hardware-Scrolling zu kommen? Wie wir am Beispiel mit dem Papier sehen k÷nnen,
wird durch das Verschieben des Bildes (ohne allerdings das Loch im schwarzen
Papier zu verschieben) der Eindruck erweckt, da▀ das Bild scrollen wⁿrde.
Genau das machen wir auch mit dem VIDC: Wir verschieben die physikalische
Einheit nach links oder rechts (um zwei Pixels auf einmal), um horizontales
Hardware-Scrolling zu erreichen (bzw. zu simulieren).

Allerdings taucht dann nach ganz kurzer Zeit ein Problem auf: Wir k÷nnen das
Bild nicht weiter nach links als zur linken Monitorseite (Horizontal Back
Porch genannt) verschieben, and genauso wenig geht das mit der rechten
Monitorseite (Horiztonal Front Porch). Die L÷sung ist dennoch nicht schwer:
Das VInit Register im MEMC. Dieses Register sagt uns (vor allem aber dem VIDC
:-), ab welcher Adresse der VIDC mit dem Auslesen der Bildschirmdaten beginnen
soll, und zwar immer in Sprⁿngen von Quadwords, also 16 Bytes auf einmal.
Wenn wir das Bild 7 mal gescrollt haben (also die Display-Register verschoben
haben), hat sich die Position des Bildes um 7*2 = 14 Pixels verschoben. Wenn
wir nun das nΣchste mal wieder um die 2 Pixel scrollen wollen, um also quasi
16 Pixel insgesamt verschoben zu bekommen, so wenden wir einfach folgenden
Trick an: Wir setzen die beiden Display-Register wieder auf ihren
Ursprungswert und sagen dem MEMC, er soll um 16 Bytes verschoben auslesen, was
ja dann den gewⁿnschten 16 Pixeln (also 8*2 Schritten) entsprΣche. Nun, das
mag vielleicht kompliziert aussehen, aber es ist gar nicht so schwierig. Wenn
wir das ProgrΣmmchen "VIDC1" anschauen, wird uns einiges klarer.

Ach ja, bitte nicht vergessen, da▀ die Beispiel-Programme "nur" zeigen, wie
Hardware-Scrolling funktioniert, aber nicht, wie man Spiele programmiert! Viel
Spa▀ beim Testen!

- Michel Fasen - "


Wow - das war ja wohl HighTech vom Feinsten, auch noch anschaulich erklΣrt!
Obwohl sogar ich zugeben mu▀, da▀ ich einige Abschnitte mehrmals durchlesen
mu▀te, um meinen Knoten im Hirn wieder l÷sen zu k÷nnen... Spa▀ beseite, es mag
anfangs kompliziert klingen, aber in Wirklichkeit ist es doch gut
nachvollziehbar, und logisch. Vor allem mit solch einem Lehrer!


                                                               - Eduard Pfarr -