Da diese Serie erst neu ab dieser Undercover Edition er÷ffnet wurde, m÷chte ich Euch erst kurz was ⁿber Sinn und Zweck der ganzen Vorstellung erzΣhlen.
Ich bin Mike of STAX und wurde von Moondog/TNB dazu ⁿberredet, ihn beim Aufbau einer
ST Coding Corner zu unterstⁿtzen.
Vielleicht hat der ein oder andere schon mal was von der Gruppe STAX geh÷rt, in der letzten
Zeit aber bestimmt nicht viel, da es doch sehr ruhig um uns geworden ist. Neben Matt war/bin
ich fⁿr Coding/Design und in alten Tagen auch mal fⁿr die ein oder andere Grafik zustΣndig
gewesen - doch das ist ehrlich gesagt schon eine Weile her. So war ich den TrΣnen der Rⁿhrung nahe, als ich die alten Quellen hervorholte und analysierte (wie war das noch anno
94 ...???). Soviel mu∞ gleich vorweg gesagt werden: sΣmtliche Codes haben schon ein
ehrfurchtsvolles Alter (Copyright 1994 und frⁿhes 1995), auch wurde nichts mehr daran ver-
Σndert oder gar optimiert. Fast alle Effekte sind mit der Intention entstanden, m÷glichst viele
verschiedene FX m÷glichst bald zu haben (Grundlagenforschung !).
Moondog/TNB zufolge gibt es noch ein paar hartgesottene ST Coder (auch die Polen sind ja
schwer im kommen ...), so da∞ ich mich fⁿr die Idee einer Coding Ecke begeistern lie∞. Ich
selbst habe meine lehrreichen Lektionen noch aus der ehrwⁿrdigen "Hexer" - Serie in der
68000er/ST-Magazin um die Jahre 88/89. In jenen Tagen drehte sich noch alles um das שffnen
der RΣnder, Raster Interrupts und Plane FX. Wer hierzu mehr wissen und das Gefⁿhl der ST-
Hochzeiten spⁿren will, dem seien diese Ausgaben empfohlen (bei Interesse gebe ich gerne
die genauen Heftnummer an - im Kopf habe ich die nicht mehr ...).
Genauer betrachtet hat sich auf dem ST seit diesen Zeiten doch viel getan. Dominierten am
Anfang noch Raster/Randeffekte, wurde im Anschlu∞ daran die Copy-Leistung des ST's
hinsichtlich Scrolling (Screen, Laufschriften) und Bl÷cken aller Art (Shapes, Sprites) ausgelotet.
Heutzutage dreht sich fast alles um Pixel Effekte - also VerΣnderung von einzelnen Pixeln,
natⁿrlich m÷glichst viele (freilich gab es auch viele Sternenfeld Routinen, aber die aktuellen
FX fordern viel mehr PunktverΣnderungen). In diese Gruppe geh÷ren sicherlich die Zoomer,
Rotierer, Texturemapper, Gouraudshader oder sogar Bumpmapper ... (die Liste kann beliebig
fortgesetzt werden - siehe PC - aber fⁿr uns ST-Jⁿnger ist bei der Rechenzeit irgendwo auch
mal Schlu∞, in der Fantasie nicht ...).
Lamers Heaven als Coding Ecke soll eine feste Instanz des beliebten Undercover Mags werden, ob ich immer dabei bin, ist allerdings fraglich. Auf jeden Fall schon mal viel Spa∞
mit dieser und den folgenden Ausgaben.
THEMA
Ich m÷chte hier hauptsΣchlich Effekte der Pixelgruppe vorstellen, aktuelles Thema in dieser, der ersten Ausgabe, ist:
VOXELSPACE
Einige Anmerkungen zur Vorgehensweise. Ich werde keine kompletten Quellen mitliefern,
sondern neben allegemeinen ErklΣrungen und detailierten Hinweisen nur Schlⁿsselteile
des Codings vorstellen. Wer sich etwas damit beschΣftigt, kommt damit sicherlich zurecht.
Ausfⁿhrbare PRG Files schon eher (leider hat die Zeit diesmal nicht mehr gereicht, sowas
auf die Beine zu stellen - folgt noch) - schlⁿsselfertige Quellen, wie gesagt nicht.
Manche der vorgestellten Methoden oder Tricks sind nicht auf meinem Mist gewachsen. So ist diesmal ein Trick beim Ablegen der Raydaten (folgt noch ...) und deren Berechnungs-routine nicht 100% original von mir. Manchmal bringt einen ein GesprΣch mit anderern ST
Leidensgenossen auf neue Ideen ...
Motivation
"Hallo Mike, hast Du schon Commanche gesehen, kuck doch mal her !". Tja, und da habe ich dann mal auf den PC Monitor geschaut - und gestaunt. Das ist ja echt ⁿbel gewesen.
Ich habe dann spontan auf dem ST rumprobiert, aber da kam nix raus. Erst spΣter wollte es
dann klappen - und diesmal haben die PCler auch etwas bl÷d geschaut. Soviel vorweg:
natⁿrlich kann man das Vorbild nicht total erreichen, aber ein bi∞chen was geht immer ...
Wer noch keine Voxelspace Routine gesehen hat, hier kurz ein ץberblick:
Voxelspace ist eine Technik mit der man 2D Aufnahmen mit einfachen Mitteln als 3D Modelle
bzw. Volumenk÷rper anzeigen kann (Voxel = Volume Pixel), indem man diesen Aufnahmen
mit den Voxeln rΣumliche Tiefe verleiht.Gern benutzt um ⁿber Landschaften zu gleiten, deren
Ursprung oftmals Satellitenaufnahmen sind; wird auch in der Medizin - IT vielfach eingesetzt.
In unserem Fall soll es um die Darstellung von Landschaften gehen, ⁿber die man mit einem
FluggerΣt gleiten kann.
Ausgehend vom PC Commanche ergeben sich folgende Anforderungen:
1) M÷glichst gro∞e Landkarte
2) Nuancenreich sowohl bei der Aufl÷sung der Voxel als auch bei der naturgetreuen Farb-gebung
3) Hohe Geschwindigkeit der Animation
4) Freie Bewegbarkeit des Gleiters in alle Richtungen mit Drehung
5) VerΣnderbarkeit der Flugh÷he des Gleiters
Grundlagen
ץble Geschichte, oder ? Ok, gehen wir mal durch, was wir alles brauchen und warum.
1) Landkarte
Ausganspunkt ist eine 2D Landkarte, die wir dreidimensional darstellen wollen. Die einzelnen
Pixel haben eine bestimmte Farbe. Den Pixeln wird nun noch eine H÷he zugewiesen.
Damit steht schonmal die grundlegende Datenstruktur.
Wenn wir so ⁿber die Landschaft dⁿsen, sehen wir immer einen Ausschnitt aus unserer Karte.
Um es erstmal einfach zu machen, stellen wir uns diesen Ausschnitt als Rechteck dar, der
ausgelesen und auf dem Screen dargestellt wird.
Unser Landkartenausschnitt k÷nnte so aussehen (hier mal nur 4x4 Pixel, von oben betrachtet):
M N O P
I J K L
E F G H
A B C D
/\
||
Betrachter
Stellt man sich nun jeden Pixel als einen kleinen Turm vor mit einer bestimmten H÷he, so
sieht man vorne die erste Zeile mit den Tⁿrmen A,B,C,D. Sind diese etwas niedriger, sieht
man auch die Tⁿrme dahinter, vielleicht sogar die MNOP Turmreihe. Die Tⁿrme werden zusΣtzlich in ihrer H÷he entsprechend ihrer Entfernung vom Betrachter perspektivisch angepa∞t. Ein Turm weiter hinten ist zwar kleiner in seiner eigenen H÷he, aber beginnt am Boden auch etwas weiter oben. Am besten selbst mal in die Ferne sehen, um diese Perspektive in der Praxis zu sehen.
Ok, unsere Pixel werden also zu Tⁿrmchen mit einer bestimmten Farbe und H÷he (diese beiden Informationen bilden zusammen unsere erste Voxel Datenstruktur). Wie man die Tⁿrmchen zeichnet, werden wir gleich kennenlernen.
Man baut den Screen in Spalten auf. Jede X Spalte wird einzeln aufgebaut, bis der Screen-
inhalt steht. Ausgehend von unserem Beispiel betreffen die Pixel A, E, I, M (Pixel + H÷he,
ab jetzt Voxel = Turm genannt) unsere erste Scanspalte. Wir beginnen in jeder Screenspalte unten mit dem Zeichnen, die Landkarte gehen wir von vorne nach hinten durch.
In unserem Fall also Turm A. Dieser habe die H÷he 2 , also werden zwei Pixel mit der
Farbe A von unten nach oben gezeichnet (Schritt 1).
Spalte 1 (Spalte ganz links zeigt die Zeile (H÷he) an):
Schritt 1 Schritt 2 Schritt 3 Schritt 4
6
5
4 M
3 E E E
2 A A A A
1 A A A A
Turm E habe die H÷he 3, da wir uns weiter vom Betrachter wegbewegen, wird die H÷he auf
2 angepa∞t, das Grundoffset sei 1, 2+1 = 3 (immer von unten gerechnet !). Jetzt m÷chten
wir aber den Turm A nicht ⁿbermalen, da der ja eigentlich vor uns steht und somit ja als erstes sichtbar sein mⁿ∞te. Man merkt sich nach jeder Zeichenoperation die H÷he des VorgΣngers und vergleicht sie mit der neu zu zeichnenden H÷he. Ist die neue H÷he kleiner als die alte, mu∞ ja nichts gezeichnet werden, da der neue Turm hinter dem Vordermann und somit un-sichtbar fⁿr den Betrachter ist. Liegt sie ⁿber dem VorgΣngerturm, zeichnet man nur die H÷hendifferenz darⁿber (Schritt 2).
Voxel I hat die H÷he 2, nach Perspektivenanpassung nur noch 1, Grundoffset sei 2, macht 3.
Da der VorgΣngerturm schon die Zeichenh÷he von 3 hatte ist der neue Turm nicht sichtbar
(Schritt 3).
Turm M sei wieder sichtbar (Schritt 4). Somit ist eine Bildschirmspalte gefⁿllt. Das gleiche Ver-
fahren wird nun auf alle Spalten angewendet (Spaltenberechnung mit Voxeln B, F, J, N, usw.)
bis der Landschaftscreen steht (siehe auch Grafik TURM.IFF).
Noch ein Satz zur Voxeldatenstruktur. Da pro Voxel H÷he + Farbe anfallen (angenommen, wie
auf dem PC 256 Farben = 1 Byte + 256 H÷hen = 1 Byte -> 2 Byte pro Voxel) kommt da fⁿr eine
ordentliche Landschaft schon was zusammen:
512 X 512 in der Ausdehnung macht 512x512x2 = 524 KB und das ist noch keine gro∞e Landschaft ! Bei Commanche waren die Maps gr÷∞er (ca. 1024x1024 = 2MB), fⁿr den ST ist das indiskutabel, noch dazu weil noch anderes Zeugs mit in den Speicher mu∞ (siehe
IMPLEMENTIERUNG).
2) Nuancenreich sowohl bei der Aufl÷sung der Voxel als auch bei der naturgetreuen Farb-gebung
Die Breite unserer Voxeltⁿrme ist natⁿrlich entscheidend fⁿr die Aufl÷sung insgesamt. Eine
angestrebte ScreenzeichenflΣche von 256x160 (wer will, kann auch noch mehr machen ...)
bedeutet bei einer 1 Pixel Turmbreite fⁿr den ST Overkill. Man mu∞ es hier etwas grober an-gehen. Hier gibt es die Varianten von 4 (mein Vorschlag) oder 8 Pixeln. Das ist machbar.
Bei den Farben ist bei 16 Schlu∞. Leider. Diese sollten daher gut aufeinander abgestimmt sein.
Ich habe mal probiert mit Rasterungen Zwischenfarben zu erzeugen. Das Ergebnis war
scheu∞lich ...
3) Hohe Geschwindigkeit der Animation
Mit einer 4er Aufl÷sung und einem kleinerem Fenster (wie unter 2) beschrieben) sind Frame-
raten um die 17 Bilder drin. Das geht in Ordnung.
4) Freie Bewegbarkeit des Gleiters in alle Richtungen mit Drehung
Das kommt gut, macht aber die Landkartenauswertung etwas schwieriger. Wer darauf ver-
zichten kann, wertet die Landschaft wie oben beschrieben mit einem rechteckigen Fenster
aus, welches er in X und Y Richtungen verschieben kann (aber eben nicht drehen ...).
Wer es sich und dem ST so richtig geben m÷chte, macht es mit Drehung.
Man kann hier nicht einfach ⁿber- bzw. nebeneinander liegende Voxel auslesen.
Auslesen in AbhΣngigkeit von der Richtung kann man wie folgt:
Man stelle sich einen Kreis vor mit Mittelpunkt B. B ist der Betrachter. man schickt nun Strahlen von diesem Mittelpunkt in die Welt hinaus; diese stellen die Sehstrahlen des Betrachters dar.
Eine volle Umdrehung hat 360 Grad, also nehmen wir mal 360 Strahlen (Abstand 1 Grad).
Wenn der Betrachter jetzt genau nach Norden schaut (Grad 0) und wir annehmen, da∞ sein
Sichtkegel noch ein wenig nach links und rechts geht, werten wir z.B. die Strahlen 330 - 30 Grad aus (angenommen 60 Grad Sichtkegel). Wenn wir uns etwas nach rechts drehen (30 Grad), dann werten wir die Strahlen 0 - 60 aus (man stelle sich den Kreis mit den Strahlen vor;
siehe auch Grafik STRAHL.IFF !).
Viel mehr ist es gar nicht. Die Strahlen werden vorher berechnet (genauer: x + y Offsets - siehe IMPLEMENTIERUNG !) und auf die Landkarte angewendet (in AbhΣngigkeit von der Betrachterposition).
Als weiters Goodie kann man auch noch das Kippen des Horizontes einbauen. Hierfⁿr werden
die Startscreenoffsets fⁿr die einzelnen Spalten = Tⁿrmchen nach oben/unten modifiziert.
5) VerΣnderbarkeit der Flugh÷he des Gleiters
Wenn sich die Flugh÷he verΣndert, verΣndert sich auch die Perspektive auf die Landschaft.
In AbhΣngigkeit davon mu∞ die Perspektivenanpassung bei der H÷henberechnung wΣhrend des Spaltenzeichnens durchgefⁿhrt werden. Dies beeinflu∞t die Perspektivenanpassung der
Voxelgrundh÷he (wie in der Landkarte abgespeichert) und das H÷hengrundoffset. Das
lΣuft das auf mehrere Perspektiventabellen hinaus - das erklΣre ich nicht weiter. Mit einem
einfachen Strahlensatz kommt man da weiter - probierts mal.
Neben der Drehbarkeit ist diese FunktionalitΣt sicherlich auch optional.
Implementierung
0) Landschaftsdaten
Unsere Landschaft soll die Gr÷∞e 256x256 haben. Fⁿr jeden Voxel speichern wir ein Byte fⁿr die
H÷he und ein Byte fⁿr die Farbe ab. Man k÷nnte es auch so angehen, da∞ man aus der H÷he
die Farbe ableiten kann. Ich habe mich fⁿr die erste Methode entschieden. Eine Zeile der
Landschaftsmatrix wird folgenderma∞en im Speicher abgelegt:
256 H÷henbytes -> erste Landschaftszeile
256 Farbbytes -> erste Landschaftszeile
256 H÷henbytes -> zweite Landschaftszeile
256 Farbbytes -> zweite Landschaftszeile
...
Wichtig: die H÷henwerte sind mit 4 multipliziert - damit man bei der Spaltenzeichenroutine
direkt in den Code einspringen kann. Somit bleiben nur noch 64 H÷hen (=256/4) ⁿbrig.
Eine Landschaftsvoxelzeile hat also 512 Bytes. Insgesamt braucht die Landschaft:
512 Byte * 256 Zeilen = 128kb
Wie man sich eine solche Landschaft generiert, ist eine andere Frage. Ich habe mir mit einem
Fraktalprogramm 2D Ansichten berechnen lassen und diese in mein Format konvertiert (nach
dem Schema: H÷he->Farbe). Eine Auswertung einer Sinuskurve ist natⁿrlich auch m÷glich (und spart fⁿr das Programmfile Speicherplatz -> weniger Daten, wenn zur Laufzeit generiert).
1) Strahlenvorberechnung
Wie bereits angesprochen, berechnen wir die Strahlen vorher. Eine Umdrehung soll hier aber aus 512 Stufen = Strahlen bestehen - hieraus resultiert eine etwas feinere Drehung. Bitte beachtet ierzu die Grafik STRAHL.IFF.
Ein Sichtstrahl ist spΣter zustΣndig fⁿr das Auslesen der Landschaftspunkte einer Spaltenbe-
rechnung. Ein solcher Strahl besteht hier aus 64 Punktoffsets. Dies stellt die Sichtweite dar, mit der wir in die Landschaft Richtung Horizont kucken. Diese Offsets werden dann bei der
Spaltenberechnung auf die aktulle Position aufaddiert - also um von einem Strahlpunkt zum
nΣchsten zu kommen, addiert man das x-y-Offset. Dadurch wird das alles relativ zu der
aktuellen Position in der Landkarte (absolute Punkte wⁿrden bei einer Bewegung nix bringen).
Ein Punktoffset besteht aus X+Y Offset, die wir in einem Longword ablegen, und zwar so:
Highword| Lowword
y offset x offset
Man nimmt als Strahlausgangspunkt meist nicht den Mittelpuntk des Kreises, sondern bewegt
sich etwas weiter weg. Diesem Umstand trΣgt die Angabe "radius1" Rechnung, indem hier
der Abstand vom Mittelpunkt des Sichkreises (siehe Grafik, Grundlagenbesprechung) ange-geben wird.
******* Source: Vorberechnung der Strahlen mit x,y Positionen ******
map_groesse equ 256 ; unsere Landschaft ist 256x256 gro∞
add.l D2,D4 ; Weiter in x Richtung auf dem Strahl bewegen
add.l D3,D5 ; weiter in y Richtung auf dem Strahl bewegen
dbra D6,punkt_loop ; Strahl abarbeiten
move.l (SP)+,D0
addq.w #1,D0 ; naechster Strahl
cmp.w #strahlen,D0 ; Schon alle Strahlen ?
bne strahlen_loop
rts
2) Vorberechnung der Junk-Konvertierungstabelle und Junk Format
Wie setzt man einzelne Punkt schnell auf dem ST (in 4 Planes natⁿrlich) ???
Hierbei hilft der movep.l Befehl - aber der wird bestimmt in einer anderen Ausgabe be-sprochen. Fⁿr Voxel brauchen wir ihn gar nicht ...
Allerdings kann die Aufl÷sung einige Probleme machen. WΣhlt man 8 Pixel Breite fⁿr einen Voxel, dann ist es doch ein Job fⁿr movep.
Wenn wir eine Voxelbreite von 4 Pixeln wollen, wird alles etwas komplizierter, aber sieht eben auch besser aus ! Aber wie setzte ich schnell 4 Pixel ?
Man schreibt in der Spaltenzeichenschleife ⁿberhaupt keine Pixel, sondern benutzt einen
Zwischenpuffer mit einem dafⁿr gⁿnstigen Format - nennen wir ihn mal Junk Puffer. Hier schreiben wir dann unsere Voxeldaten rein. Im zweiten Schritt wird dann dieser Puffer aus-
gewertet und in den ST Bildschirmspeicher geschrieben. Das mu∞ natⁿrlich flott gehen.
In diesem Fall ist es schneller als Voxel gleich direkt zu zeichnen.
So sieht das Format des Junk Puffers aus:
Wir haben 16 Farben, man kann also mit 4 Bit alle Farben codieren. Also soll ein Voxel durch
diese Information seine Farbe codieren (da∞ die Breite spΣter 4 ist, interessiert uns hier noch
nicht ! Eine Farbe pro Einheit = Voxel ). In ein Byte unseres Puffers passen somit 2 Voxelfarb-
Beim Schreiben in unseren Puffer mⁿssen wir nur aufpassen, da∞ wir einmal Bits 4,5,6,7 und
einmal Bits 0,1,2,3 beschreiben (Highnibble, Lownibble). Dies werden spΣter zwei ver-schiedene Spaltenzeichenroutinen ⁿbernehmen.
Die nΣchste Frage ist natⁿrlich, wie die Daten des Junk Puffers in den Bildschirmspeicher
kommen. Ganz einfach - eine gro∞e Tabelle hilft mal wieder !
Die Junk Puffer Konvertierungsroutine (siehe Punkt 4) geht so vor:
Es wird immer ein Wort aus dem Junk Puffer ausgelesen. Dieses Wort codiert ja 4 Voxel (pro
Byte 2). Bei einer angestrebten Voxelbreite von 4 macht entsprechen dieser Information
4 Voxel * 4 Pixel = 16 Pixel. H÷rte ich gerade 16 Pixel ??? Das ist doch schon was fⁿr unseren
ST Bildschirmspeicher. Und so geht es weiter ... ץber die Tabelle werden die 4 Farb-informationen in die 4 Planew÷rter des STs umgesetzt und in den Bildschirmspeicher geschrieben. Mehr ist es nicht. Zur Tabelle selbst: sie mu∞ alle Kombinationen abdecken,
also 16 Farben (Voxel 1) * 16 Farben(Voxel 2) * 16 Farben (Voxel 3) * 15 Farben (Voxel 4, ich
benutze Farbe 16 fⁿr Rasterfarben, kann ich mir hier also sparen ...) * 4 Planew÷rter ST =
491520 Bytes ! Ist nicht gerade wenig .... ich wei∞.
********** Source: Vorberechnungen der Junk Tabelle ***********
precalculate_junk_tab:
lea mammut_table,A0
lea d0_tab(PC),A1
lea d1_tab(PC),A2
lea d2_tab(PC),A3
lea d3_tab(PC),A4
moveq #0,D0
moveq #0,D1
moveq #0,D2
moveq #0,D3
loop:
; Spalte 0
move.w D0,D4
lsl.w #3,D4
movem.l 0(A1,D4.w),D5-D6
; Spalte 1
move.w D1,D4
lsl.w #3,D4
or.l 0(A2,D4.w),D5
or.l 4(A2,D4.w),D6
; Spalte 2
move.w D2,D4
lsl.w #3,D4
or.l 0(A3,D4.w),D5
or.l 4(A3,D4.w),D6
; Spalte 3
move.w D3,D4
lsl.w #3,D4
or.l 0(A4,D4.w),D5
or.l 4(A4,D4.w),D6
; In Tabelle schreiben
move.l D5,(A0)+
move.l D6,(A0)+
; NΣchste Kombination
addq.w #1,D0
cmp.w #16,D0 ; 16 * ...
blt.s loop
moveq #0,D0
addq.w #1,D1
cmp.w #16,D1 ; ... * 16 * ...
blt.s loop
moveq #0,D1
addq.w #1,D2
cmp.w #16,D2 ; ... * 16 * ...
blt.s loop
moveq #0,D2
addq.w #1,D3
cmp.w #15,D3 ; ... * 15
blt.s loop
rts
d0_tab: DC.W $000F,$000F,$000F,$000F
DC.W $000F,0,0,0
DC.W 0,$000F,0,0
DC.W $000F,$000F,0,0
DC.W 0,0,$000F,0
DC.W $000F,0,$000F,0
DC.W 0,$000F,$000F,0
DC.W $000F,$000F,$000F,0
DC.W 0,0,0,$000F
DC.W $000F,0,0,$000F
DC.W 0,$000F,0,$000F
DC.W $000F,$000F,0,$000F
DC.W 0,0,$000F,$000F
DC.W $000F,0,$000F,$000F
DC.W 0,$000F,$000F,$000F
DS.W 4
d1_tab: DC.W $00F0,$00F0,$00F0,$00F0
DC.W $00F0,0,0,0
DC.W 0,$00F0,0,0
DC.W $00F0,$00F0,0,0
DC.W 0,0,$00F0,0
DC.W $00F0,0,$00F0,0
DC.W 0,$00F0,$00F0,0
DC.W $00F0,$00F0,$00F0,0
DC.W 0,0,0,$00F0
DC.W $00F0,0,0,$00F0
DC.W 0,$00F0,0,$00F0
DC.W $00F0,$00F0,0,$00F0
DC.W 0,0,$00F0,$00F0
DC.W $00F0,0,$00F0,$00F0
DC.W 0,$00F0,$00F0,$00F0
DS.W 4
d2_tab: DC.W $0F00,$0F00,$0F00,$0F00
DC.W $0F00,0,0,0
DC.W 0,$0F00,0,0
DC.W $0F00,$0F00,0,0
DC.W 0,0,$0F00,0
DC.W $0F00,0,$0F00,0
DC.W 0,$0F00,$0F00,0
DC.W $0F00,$0F00,$0F00,0
DC.W 0,0,0,$0F00
DC.W $0F00,0,0,$0F00
DC.W 0,$0F00,0,$0F00
DC.W $0F00,$0F00,0,$0F00
DC.W 0,0,$0F00,$0F00
DC.W $0F00,0,$0F00,$0F00
DC.W 0,$0F00,$0F00,$0F00
DS.W 4
d3_tab: DC.W $F000,$F000,$F000,$F000
DC.W $F000,0,0,0
DC.W 0,$F000,0,0
DC.W $F000,$F000,0,0
DC.W 0,0,$F000,0
DC.W $F000,0,$F000,0
DC.W 0,$F000,$F000,0
DC.W $F000,$F000,$F000,0
DC.W 0,0,0,$F000
DC.W $F000,0,0,$F000
DC.W 0,$F000,0,$F000
DC.W $F000,$F000,0,$F000
DC.W 0,0,$F000,$F000
DC.W $F000,0,$F000,$F000
DC.W 0,$F000,$F000,$F000
DS.W 4
3) Spaltenzeichnerroutine
Die Spaltenzeichenroutine geht nach dem bereits geschilderten Algorithmus vor (siehe
Grundlagen). Anzumerken ist noch, da∞ die Farbtabelle die 4 Bit Farbinformationen
im oberen Nibble eines Bytes speichert. In der zweiten Routine mⁿssen die Farben dann noch
fⁿr das untere Nibble geshiftet werden.
********** Source: Zeichnen der Spalten ***********
mask equ %00000000000000011111111011111111
spalten equ 64 ; wir zeichnen 64 Spalten (256 Screenpixel / 4 Pixel pro Voxel)
scan_nibble_high:
;**** Registerbelegung innerhalb der Schleifen ****
; d0= x+y Position
; d1= Neue Hoehe
; d2= Alte Hoehe
; d3= Spaltenpunkte ZΣhler
; d4= pers adr + work byte
; d5= perts adder
; d6= Offset einer Zeile innerhalb des Junk Puffers
; d7= And Maske fⁿr Bleiben innerhalb der Landschaft
* a0= Delta-xy-offset Tabelle eines Strahls
* a1= Zugriff auf die H÷hendaten der Landschaft
* a2= Zugriff auf die Farbdaten der Landschaft
* a3= Fⁿr Direkteinsprung in die Turmzeichenbefehlsfolge
