Die Tür zum Cyberspace - Der DSP als Grafikkoprozessor, Teil 3: Das Host-Programm
Die ersten beiden Teile dieser Artikelreihe behandelten die für eine komplette 3D-Transformation notwendigen Berechnungen und deren Umsetzung in DSP-Assembler. Diesmal geht es um die Handhabung der Objektwelt-Datenstrukturen auf der Seite des Host-Prozessors, die Kommunikation mit dem DSP, die Darstellung auf dem Bildschirm und die Möglichkeiten zur Erzeugung dreidimensionaler Objekte. Anwendungsbeispiele, Ideen zur Weiterentwicklung und ein Blick auf den gegenwärtigen Stand der Technik auf dem Gebiet der „Virtuellen Realität“ beenden dann diesen Kurs.
Vom 3D-Action-Spiel für den Home-Computer bis zum hochentwickelten Flugsimulator der NASA arbeiten alle Systeme, die im allerweitesten Sinne dem Bereich „Virtuelle Realität“ zuzuordnen sind, nach dem selben Prinzip: Eine künstliche, im Speicher des Rechners definierte Objektwelt wird in einem sich ständig wiederholenden Kreislauf entsprechend der Positionen und Blickwinkel des Betrachters transformiert und zur Darstellung gebracht. Ein kompletter Transformationszyklus besteht aus den drei Komponenten: Interaktion mit dem Benutzer -> Berechnung der 3D-Grafik -> Darstellung. Schafft der Rechner 25 Zyklen pro Sekunde, kann man von einem wirklichen Echtzeitsystem sprechen. Durchaus zufriedenstellend sind aber schon Frequenzen ab acht Bildern pro Sekunde.
Realisierung mit dem Falcon030
Mit seiner Farbenvielfalt und dem DSP als Koprozessor scheint ATARIs Falcon dafür geeignet zu sein, mal einen Schritt in den Cyberspace zu wagen. Die nötigen Berechnungen können vom DSP in jedem Fall schnell genug durchgeführt werden; das schwächste Glied der Kette bildet die Ausgabe auf dem Bildschirm. Hier muß man sich als erstes für einen geeigneten Grafikmodus entscheiden. Ein wichtiges Kriterium ist dabei die Größe des Video-RAMs, da allein das Löschen des Bildschirms eine nicht zu unterschätzende Zeit in Anspruch nimmt. Letztendlich läuft es auf einen Kompromiß zwischen Auflösung und Farbtiefe hinaus. Lassen wir den monochromen und den 4-Farb-Modus außer Acht (obwohl für manche Anwendungen auch diese Modi geeignet sein mögen), bleibt die Wahl zwischen 16 oder 256 Farben und dem True-Color-Modus.
Im 16-Farbmodus wird es schwierig, die berechneten Schattierungen wiederzugeben. Hier könnte man entweder die Farbpalette auf 16 Graustufen einstellen oder die verschiedenen Helligkeiten durch Füllmuster darstellen. Die Größe des Bildschirmspeichers wäre mit ca. 150 KB bei 640 * 480 Pixeln akzeptabel. Versuche im 256-Farb-Modus mit einer hohen Auflösung habe ich ziemlich schnell wieder aufgegeben - 300 KB Video-RAM zu beschreiben dauert einfach zu lang. Halbiert man die Auflösung, kann die Farbtiefe erhöht werden, und die Größe des Bildschirmspeichers liegt wieder bei 150 KB. Ich habe mich also für den True-Color-Modus entschieden, wobei die Pixel-Packed-Organisation des Bildschirms und die daraus resultierende Unabhängigkeit von einer Farbpalette den Ausschlag gegeben haben. Als nächstes stellt sich die Frage der Grafikausgabe. Notwendige Voraussetzung für flüssigen, flackerfreien Bildschirmaufbau ist die Installierung eines zweiten Bildspeichers. Während Screen 1 angezeigt wird, wird Screen 2 im Hintergrund aufgebaut. Mit dem nächsten VBLwerden die Screens dann gewechselt. Am einfachsten wird dies über die XBIOS-Funktion Setscreen erreicht, mit der man einen reservierten Speicherbereich als neue Logbase anmelden bzw. Physbase und Logbase tauschen kann. Hier verläßt man allerdings das Terrain kompatibler Programmierung, da keine mir bekannte Grafikkarte für ATARI-Rechner dieses s.g. Pageflipping unterstützt (vgl. [4]). Obwohl dies meiner Meinung nach ein Manko der Grafikkarten ist (eine VGA-Karte für den PC ermöglicht es ohne Probleme, mehrere Bildschirmseiten zu verwalten), müßte für ein „sauberes“ GEM-Programm eine andere Lösung gefunden werden. NVDI (ab Version 2.5) erweitert das ATARI-VDI um die Funktionen v_opnbm() (OPEN BITMAP) und v_clsbm() (CLOSE BITMAP) zum Verwalten und Bearbeiten von Off-Screen-Bitmaps. Dadurch kann man VDI-Ausgaben auf einem Hintergrundschirm vornehmen und anschließend dessen Inhalt ohne Benutzung von vr_trnfm() auf den sichtbaren Bildschirm kopieren.
Das VDI unterstützt die Grafikausgabe im True-Color-Modus leider nur sehr halbherzig. Man kann keiner Ausgabefunktion den direkten Farbwert (16 Bit) übergeben, sondern muß einen Umweg nehmen, der doch wieder über eine 256-Farben-Palette (!) führt, da das VDI nur Farbindizes von 0 bis 255 akzeptiert. Allerdings kann die Palette neu gesetzt werden, ohne daß sich die Farbe der bereits gesetzten Pixel ändert. Normalerweise installiert ein Grafikprogramm im Zuge der Programminitialisierung ggf. eine neue Palette mit vs_color und setzt dann vor der Ausgabe die entsprechende Füll-bzw. Linienfarbe mit vsf_color und vsl_color. Im TC-Modus kann man den umgekehrten Weg gehen: Bei Programmstart legt man sich auf eine Farbe fest, deren RGB-Zusammensetzung man dann für die Ausgabe des gewünschten Farbtons neu setzt.
Eine Alternative wäre, die Grafikausgabe selbst zu programmieren. Das ermöglicht zum einen die direkte Verarbeitung des True-Color-Farbwerts, zum anderen kann durch eine Optimierung auf den speziellen Anwendungsfall (hier konvexe Polygone) eine Geschwindigkeitssteigerung von bis zu 40% erreicht werden! Die Moral der ATARI-Zunft verbietet zwar das direkte Beschreiben des Bildschirmspeichers, aber ein Programm kann ja beide Möglichkeiten anbieten. Selbst die strengen Richtlinien von Apple erlauben, „unter Umständen direkt auf den Bildschirmspeicher zuzugreifen" [4], Dabei gibt es keine Probleme mit Grafikkarten, da sich deren Hersteller ebenfalls an diese Richtlinien halten.
Um möglichst kompatibel zu sein, müßte ein Programm also die Grafikumgebung (NVDI, Grafikkarte) prüfen und entsprechende Ausgabemodule bereitstellen. Um den Quelltext nicht ins Unendliche zu treiben, bedient sich das Beispielprogramm der zuerst genannten Methode des Pageflippings, die für Rechner ohne Grafikkarte in puncto Geschwindigkeit die optimale Lösung ist. Die Ausgabe kann wahlweise über VDI oder eine Assembler-Routine, die direkt in den logischen Bildschirm schreibt, erfolgen.
Erlauben Sie mir noch eine Bemerkung zum Thema „kompatible Programmierung“: Ein Programm, mit dem sich nur auf einem getunten Rechner mit schneller Grafikkarte vernünftig arbeiten läßt, ist fast genauso ärgerlich wie eines, das unter eben diesen Bedingungen seinen Dienst versagt. Da in den meisten Fällen nur wenige Stellen eines Programms zeitkritisch sind, wäre eine mögliche Lösung, hier zwei Alternativen anzubieten: ein hardwarenah programmiertes Modul, das die Ressourcen des Rechners voll ausreizt, und eines, das rechnerunabhängig arbeitet, d.h. nur die Funktionen des Betriebssystems benutzt.
Das Host-Programm
Das in Pure C geschriebene Beispielprogramm für den MC68030 bringt eine im 3DX-Format vorliegende Objektwelt in einer sich endlos wiederholenden Schleife auf den Bildschirm.
Dabei können interaktiv über entsprechende Tastaturkommandos (siehe Listing) Position und Blickwinkel des Betrachters sowie verschiedene Darstellungsparameter (Zoom, Weitwinkel, Licht-Schatten-Kontrast) verändert werden. Mit den Funktionstasten Fl-F5 können diverse Rotationsdemos (Kamera- und Lichtbewegungen auf einer Kreisbahn) gestartet werden, und mit F6-F8 kann zwischen drei Möglichkeiten der Grafikausgabe (v_pline und v_fillarea des VDI und der Assembler-Routine polyfill) umgeschaltet werden. Für einen Vergleich der Ausgabegeschwindigkeiten kann mit [Backspace] die zuletzt gemessene Bildfrequenz erfragt werden.
Das Host-Programm hat folgenden Aufbau:
- Programminitialisierung,
- Programm beim GEM anmelden
- virtuelle Workstation öffnen
- Bildschirmauflösung speichern
Grafikinitialisierung
Videomodus (modecode) ermitteln und Farbtiefe prüfen (nur True-Color). Zweite Bildschirmseite und VBL-Routine installieren. Die in Assembler geschriebene VBL-Routine übernimmt das Löschen des (logischen) Bildschirms und holt den Tastatur-Scancode direkt aus dem ACIA-Hardware-Register, um eine ständige Tastaturüberwachung zu ermöglichen. Ein in die Hauptschleife des Programms integrierter evnt_multi-Aufruf hätte ein „Nachlaufen" der Tastatur zufolge, da das AES alle Tastendrücke speichert und nacheinander ausführt. Versuche, die Tastenwiederholung während der Berechnungen abzuschalten, konnten den Effekt nur mildern. Für ein „sauberes“ GEM-Programm müßte hier sicherlich noch eine andere Lösung gefunden werden.
DSP-Initialisierung
DSP reservieren, LOD-Datei laden und DSP-Programm starten. Hier sollte man zur Sicherheit noch die DSP-Word-Größe mittels Dsp_GetWordSize erfragen, da es möglich ist, daß sich diese in ferner Zukunft einmal ändern könnte.
Sinustabelle erzeugen
Da, wie bereits in Teil 1 erwähnt, die Sinus-ROM-Tabelle des DSP nicht fein genug aufgelöst ist, wird mit einer eigenen Tabelle gearbeitet, die vom Programm zur Laufzeit erzeugt wird. Die Werte werden durch Multiplikation mit 0x800000L in das fraktionale Zahlenformat des DSP umgerechnet und mit Dsp_BlkUnpacked im 32-Bit-Format übertragen, wobei die oberen acht Bits abgeschnitten werden. Der Sinus von 90° (+1) muß durch 0.999999 (=0x7FFFFF) ersetzt werden, da 0x-800000 als „-1“ interpretiert würde.
3D-Objekt-Datei laden
Um eine Dateiauswahlroutine einzusparen, interpretiert das Beispielprogramm die Kommandozeile als Dateinamen. Einem (GEM-)Programm kann ein Dateiname in der Kommandozeile übergeben werden, indem man die zu ladende Datei auf das Programm-Icon zieht. Verzichtet wurde hier auch auf eine Überprüfung des Dateiformats und die Auswertung des Datei-Headers. Insbesondere müßte geprüft werden, ob der Speicher des DSP die Daten aufnehmen kann. Alle Objekt-Dateien auf der Mega-Disk können jedoch problemlos geladen werden. Wurde keine Datei geladen, wird das im Sourcecode integrierte ATARI-Logo-Objekt verwendet.
Objektweltdaten initialisieren und zum DSP senden
Die Funktion init_3D() ermittelt die Adressen jeder Fläche und speichert diese im Pointer-Array fladress[]. Da die Struktur jeder Fläche unterschiedlich lang ist, kann nur so auf die Flächendaten direkt zugegriffen werden. Zur Vereinfachung des Datentransfers liegen die Koordinaten nicht in getrennten x-, y-, z-Arrays, sondern blockweise direkt hintereinander im Array welt[], daher müssen auch die Anfangsadressen der Koordinatenkomponenten berechnet und in entsprechenden Pointer-Variablen gespeichert werden.
Die Funktion send_init() sendet nun alle statischen Daten zum DSP. Zuerst die Sinustabelle, dann die Objektweltdaten inklusive der konstanten Parameter. Direkt im Anschluß werden die mit jedem Zyklus veränderbaren Parameter verschickt, die zugleich die Berechnungen im DSP auslösen.
Hauptschleife
Kernstück des Programms ist die immer wieder zu durchlaufende „do-while“-Schleife in der eingangs beschriebenen Form. Die Schleife wird ohne Verzögerung ständig wiederholt, auch wenn keine Parameter verändert worden sind. Bedingt durch die Technik des „Pageflippings", gibt es kein Warten auf (Benutzer-)Ereignisse, wie dies in menügesteuerten GEM-Programmen normalerweise üblich ist.
Sind die Berechnungen im DSP abgeschlossen, werden alle Ausgabedaten von der Funktion recv_data entgegengenommen. Dies sind die Bildschirmkoordinaten inklusive der errechneten Bewegungsrichtungskomponenten und eine Liste der zu zeichnenden Flächen. Jetzt werden eventuelle Benutzeraktionen ausgewertet und die variablen Parameter zum DSP gesendet. Der nächste Transformationszyklus wird also gestartet, bevor mit der Zeichnung der Objektwelt begonnen wird. Auf diese Weise arbeiten beide Prozessoren parallel. Nachdem alle sichtbaren Flächen von draw_objc() gezeichnet worden sind, wird wieder zum Schleifenanfang gesprungen, wo in der Regel ohne Verzögerung die neuen Daten entgegengenommen werden können.
Programm verlassen
Vor der Rückkehr zum Desktop wird in graf_exit die Bildschirmorganisation wieder in den Ausgangszustand versetzt und die VBL-Routine ausgeklinkt. Der DSP wird freigegeben und das Programm beim GEM abgemeldet.
Kommunikation mit dem DSP
Das Host-Programm tauscht die Daten mit dem DSP über das Host-Interface aus. Auf DSP-Seite wird dafür der Port B durch Setzen des Bit 0 im Port-B-Control-Register (movep #>1:M_PBC) konfiguriert. Kommandos an den DSP werden mit der XBIOS-Funktion Dsp_BlkHandShake (24 Bit) übertragen, für den Austausch der Objektweltdaten wird Dsp_BlkWords benutzt, das die 16-Bit-Words des MC68030 vorzeichenrichtig auf 24 Bits erweitert.
Der Nachteil der XBIOS-Funktionen besteht in der blockierenden Arbeitsweise. Beide Prozessoren müssen die Anzahl der zu übertragenden Werte kennen - ein Wert zuviel angefordert, und das System hängt sich auf bzw. verharrt in einer endlosen Polling-Schleife. Hier hätte man einen Timeout einbauen müssen!
Wurde fehlerfrei programmiert, läuft der Austausch jedoch wie am Schnürchen. Dabei hilft ein Bit im Host-Control-Register (HCR), das vom DSP für die Zeit der Berechnungen gesetzt wird. Dieses Bit kann vom Host-Prozessor mit der XBIOS-Funktion Dsp_Hf2 abgefragt werden. Da der Datenaustausch nicht über Interrupts gesteuert wird (der DSP pollt das Host-Status-Register), kann so vermieden werden, daß Daten zum falschen Zeitpunkt verschickt oder angefordert werden.
Zeichnen der Objektwelt
Die Assembler-Routine polyfill befindet sich als „O-Datei" auf der Mega-Disk und kann durch Setzen des Flags POLYEXT in der ersten Zeile des C-Listings und Entfernen des in der entsprechenden Zeile der Projekt-Datei zugelinkt werden. Der Assembler-Routine wird ein Zeiger auf einen Definitionsblock PDB übergeben. Der PDB enthält - neben den Koordinaten der Eckpunkte und deren Anzahl - die Farbe als 16-Bit-True-Color-Wert, die Clipping-Werte sowie die Adresse des logischen Bildschirms und die Anzahl der Bytes pro Bildschirmzeile. Die Struktur des PDB können Sie dem Listing entnehmen. Die Funktion draw_objc belegt den PDB unabhängig davon, welche Routine die Polygone zeichnet, d.h., auch die VDI-Funktionen verwenden den PDB.
Zuerst wird die Adresse des aktuellen logischen Bildschirms in den PDB eingetragen und gewartet, bis die VBL-Routine den Bildschirm gelöscht hat (clrflag = 0). Jetzt wird die vom DSP ausgegebene, nach z-Koordinaten sortierte Flächenliste in einer „while“-Schleife abgearbeitet. Die Anzahl der zu zeichnenden Flächen wird dem ersten Listeneintrag entnommen; danach folgen für jede Fläche drei Werte: mittlere z-Koordinate, Farbwert und Flächennummer (die z-Koordinate wird zum Zeichnen nicht gebraucht). Der Farbwert wird in den PDB eingetragen. Mit der Flächennummer wird über das Pointer-Array fladress[] der Zeiger auf die aktuelle Flächenstruktur geholt. Das zweite Element dieser Struktur enthält in den unteren vier Bits die Anzahl der Eckpunkte, die Bits 4-7 enthalten einen Code für einige einfache Attribute. Über die Punkt-Indizes werden die Koordinaten der Eckpunkte aus dem Bildschirmkoordinaten-Array in das „xy_array“ des PDB übertragen. Ist Bit 4 der o.g. Codebits gesetzt, wird ein Linienpolygon gezeichnet, ansonsten wird die ausgewählte Ausgaberoutine der Funktions-Pointer-Variablen (*po!y_sub)() entnommen.
Die VDI-Funktionen müssen, wie bereits erwähnt, den Umweg über die Farbpalette gehen. Aus dem 16-Bit-True-Color-Wert werden die RGB-Anteile extrahiert und auf das VDI-Format (Werte von 0 bis 1000) umgerechnet. Um dabei nicht allzuviel Zeit zu verlieren, wird dabei auf Multiplikationen verzichtet: Anstatt die 5-Bit-Anteile mit 1000/31 zu multiplizieren, werden die Werte durch Shiften um 5 Bits auf den Bereich 0 bis 992 gebracht. Diese kleine Ungenauigkeit spielt keine Rolle, da es im TC-Mode sowieso nur 32 Farbabstufungen gibt. Mit den Werten wird über vs_color die RGB-Zusammensetzung der Farbe eingestellt. Die Tatsache, daß das VDI intern auf irgendeine Art wieder auf den 16-Bit-Wert umrechnen muß, ist schon ziemlich grotesk und begründet sicherlich teilweise den Geschwindigkeitsvorteil der Assembler-Routine.
Erzeugung dreidimensionaler Objekte
Wenn Sie dem Kurs bisher gefolgt sind, haben Sie sich vielleicht schon gefragt, wie man die erforderlichen Daten in den Rechner bekommt. Bei einfachen Objekten mag die Eingabe als Sourcecode noch vertretbar sein, für komplexe Objekte, wie z.B. eine durch Polygone angenäherte Kugel, gibt es verschiedene Generierungstechniken.
Alle achsensymetrischen Körper (Kugel, Kegel, Zylinder...) lassen sich durch Rotation einer Definitionslinie um eine Achse erzeugen. Eingegeben werden müssen nur eine Linie bzw. deren Zwischenpunkte und die Anzahl der gewünschten Rotationen. Je nach Größe des Objekts lassen sich schon mit zwölf Rotationen ziemlich rund wirkende Körper erzeugen (siehe Bild 3). Alle Punkte der Definitionslinie werden dabei jeweils um 360/n° (n = Anzahl der Rotationen) schrittweise weiter rotiert und die errechneten Koordinaten gespeichert.
Gibt man eine Außenfläche bzw. deren Eckpunkte und einen Wert für die Tiefe vor, läßt sich daraus ein Extruder-Körper erzeugen. Die Eckpunkte müssen im Uhrzeigersinn eingegeben werden, und man muß darauf achten, daß die Fläche konvex ist, damit der Hidden-Line-Algorithmus fehlerfrei arbeitet. Die eingegebenen Koordinaten werden einfach kopiert und mit einer dem Tiefenwert entsprechenden z-Koordinate versehen. Auch bei der Erstellung der Flächenstrukturen muß immer darauf geachtet werden, daß die Punktindizes der Eckpunkte die Flächen im Uhrzeigersinn (von außerhalb des Objekts betrachtet) umschreiben. Im Falle des Extruders bedeutet dies bspw., daß die Reihenfolge der Punktindizes der kopierten Außenfläche umgekehrt werden muß!
Aus der Kombination von Rotationskörpern und Extrudern lassen sich schon fast alle vorstellbaren Objekte konstruieren, vor allem, wenn ein entsprechender Editor noch verschiedene Möglichkeiten zur Nachbearbeitung und Optimierung bietet. Alle in dieser Artikelserie abgebildeten Objekte - mit Ausnahme der Landschaft - sind auf diese Weise mit dem Editor „3D-GCS" konstruiert worden. Die Abbildungen sind unbearbeitete Screenshots des Beispielprogramms.
Fraktale Landschaften
Als Ausgangsbasis dient hier ein Koordinatennetz, dessen Punkte mittels einer geeigneten fraktalen Rechenvorschrift mit Höhenwerten belegt werden. Je nach Auflösung entstehen dabei allerdings riesige Datenmengen, so daß eine Verarbeitung in Echtzeit in der Regel nur als Drahtmodell möglich ist. Ein 128 * 128 Punkte umfassendes Planquadrat besteht schon aus 16384 Punkten und fast ebenso vielen Flächen! Der Landschaftsausschnitt in Bild 4 ist nach der in [3] beschriebenen Methode „Landschaft durch Mittelpunktverschiebung" entstanden, die auf der s.g. fraktalen Brownschen Bewegung (fBM) basiert.
3D2-Objekt-Import
Das 3D2-Objekt-Format unterscheidet sich in einigen wesentlichen Punkten von dem speziell für Echtzeit-Transformationen entwickelten 3DX-Format. Hauptunterschiede bestehen zum einen in der Organisation des Koordinatenspeichers, in dem für jeden Punkt die x-, y- und z-Koordinaten nacheinander abgelegt sind; zum anderen im Aufbau der Flächenstruktur. Da ein 3D2-0bjektnuraus Dreiecken besteht, gibt es keine flexible Flächenstruktur; jede Fläche wird mit genau vier Words beschrieben. Anhand des in [5] abgedruckten 3D2-Datei-Formats läßt sich eine Konvertierung relativ leicht durchführen. Das ausführlich dokumentierte 3DX-Format befindet sich als ASCII-Text mit auf der Mega-Disk.
Anwendungen und Ideen zur Weiterentwicklung
Wie schon im ersten Teil dieser Artikelreihe angedeutet, können praktisch alle Anwendungen, die sich mit dreidimensionalen Objekten befassen, von einer schnellen 3D-Transformation profitieren. In erster Linie wären hier natürlich Fahr- oder Flugsimulatoren und anspruchsvolle Action-Spiele zu nennen. Raytracing- und Animations-Software könnte aussagekräftige Previews bieten, und 3D-CAD-Programme würden schnell einen plastischen Eindruck der entworfenen Objekte vermitteln.
Das hier vorgestellte Anwendungsbeispiel macht noch keinen Gebrauch von der Möglichkeit, einzelne Objekte einer 3D-Welt zu beeinflussen. Hierfür muß eine Objektstruktur verwaltet werden, die zumindest folgende Informationen beinhalten muß: Offset bzw. Index auf die zugehörigen Punkte im Koordinaten-Array und deren Anzahl, Offset bzw. Index auf die zugehörigen Flächen und deren Anzahl sowie Position und Lage (Winkel) im Raum. Mit diesen Informationen können dann vor der Transformation einzelne Objekte bewegt und rotiert werden.
Dreidimensionale Stereobilder ließen sich realisieren, wenn die Perspektive-Transformation für jeden Punkt zweimal ausgeführt würde. Zwei im Abstand der Augen horizontal auseinanderliegende Projektionszentren liefern dann jeweils zwei Bildschirmkoordinaten, bei denen sich nur der x-Wert unterscheidet. Bei der Darstellung wird es dann etwas schwieriger. Es müssen in jedem Zyklus zwei für beide Augen getrennt wahrnehmbare Bilder gezeichnet werden. Für diese Trennung gibt es zeitparallele und zeitmultiplexe Verfahren. Zeitparallel bedeutet, daß beide Bilder gleichzeitig dargestellt werden - entweder auf einem geteilten Bildschirm oder farblich kodiert. Letzteres ermöglicht nur Schwarzweißbilder, für deren Betrachtung man die bekannte Rot-Grün-Brille benötigt. Zeit-multiplex bedeutet, daß beide Bilder alternierend gezeigt werden. Auch hier benötigt man eine Spezialbrille, die mit dem Bildwechsel synchronisiert immer nur die Sicht für ein Auge freigibt. Damit kein Flimmern entsteht, wird hierfür jedoch eine Bildwiederholfrequenz von mindestens 100 Hz benötigt, da sich subjektiv die Frequenz ja halbiert.
Virtuelle Realität
Entscheidendes Merkmal eines VR-Systems ist nicht, wie man meinen könnte, eine besonders realitätsnahe visuelle Darstellung, sondern die Art der Verbindung zum Benutzer. An die Stelle der klassischen Ein- und Ausgabegeräte Tastatur, Maus und Monitor treten Datenhandschuh, Positionssensoren und Bildschirmbrille, die dem Benutzer ein immersives (eintauchendes) „1. Person-Erlebnis“ vermitteln. Zu den Grafikberechnungen kommt noch die Simulation physikalischer Gesetze. So ist es möglich, ein Objekt zu greifen und an anderer Stelle abzusetzen. Dabei wird sogar über spezielle Sensoren im Datenhandschuh derTastsinn entsprechend stimuliert.
Bemerkenswert ist, daß „viele Personen, die heute entscheidend die VR-Entwicklung vorantreiben, bei ATARI beschäftigt waren“ [6]. Zu nennen wären hier z.B. Scott Fischer und Warren Robinett, die Mitte der achtziger Jahre zur NASA wechselten, oder Thomas Zimmermann, der bereits 1981 den Prototyp des Datenhandschuhs erfand.
Die am weitesten ausgereiften VR-Systeme finden sich, wie so oft, im militärischen Bereich in Form von hochentwickelten Rüg- und Panzersimulatoren. Ganze Manöver werden schon mit länderübergreifend vernetzten Simulatoren durchgeführt. In naher Zukunft wird der Unterhaltungssektor erobert werden; bereits heute gibt es mit VR-Systemen ausgestattete Spielhallen. In sog. „Virtuality-Cafes“ werden über mehrere Stunden andauernde Rollenspiele ausgetragen. Die fortschreitende Vernetzung mit Glasfaser wird Begegnungen mehrerer Teilnehmer in einem gemeinsamen virtuellen Raum ermöglichen.
Die Fülle möglicher und zumindest ansatzweise bereits realisierter Anwendungen ist schier unüberschaubar. Neben den bereits genannten Gebieten wird die VR-Technik zunehmend im wissenschaftlichen und gesellschaftlichen Bereich zum Einsatz kommen. Architektur, Medizin, Telearbeit sind nur einige Stichpunkte, um Ihre Fantasie anzuregen. Mitzunehmender Leistungsfähigkeit der Rechner (parallel arbeitende Prozessoren mit optoelektronischen Schaltkreisen ...) wird die VR-Technik in ferner Zukunft zum Standard eines jeden Personalcomputers gehören.
Literatur:
[1] 3D-Grafik-Programmierung, Uwe Braun, Data Becker 1986
[2] DSP56000/DSP56001 Digital Signal Processor User’s Manual, Motorola 1990
[3] Natur als fraktale Grafik, R. Scholl, O. Pfeiffer, Markt&Technik 1991
[4] ST-Computer 11/94 bis 2/95 „Kompatible Spieleprogrammierung“, Klaus-Dieter Pollack
[5] ST-Computer 10/93, S. 134 „Auge um Auge, Strahl um Strahl“
[6] Virtuelle Realität, Sven Bormann, 1994 Addison-Wesley (Deutschland)
;-------------------------------------------------
; DSP als Grafik-Koprozessor
; Assembler-Routinen zum Host-Program
; (c) 1995 by MAXON-Computer
; Autor: Klaus Heyne
;-------------------------------------------------
GLOBL vbl_init,vbl_exit,clr_val
GLOBL screen1,scrsize,clrflag,zeit,scancode
;-------------------------------------------------
; VBL-Routine installieren/entfernen (SUPERVISOR)
;-------------------------------------------------
vbl_init:
moveq #0,D1 ;Suche "Null-Eintrag"
move.l #_vbl,D2 ;Setze neue Routine
bra vbl_inex
vbl_exit:
move.l #_vbl,D1 ;Suche die Routine
moveq #0,D2 ;Setze "Null-Eintrag"
vbl_inex: ;Zeiger auf Zeigertabelle
movea.l $0456,A0 ;aller VBlank-Prozesse
move.w $0454,D0 ;Anzahl der maximal akti-
subq.w #1,D0 ;vierbaren Routinen
vblinex2:
cmp.l (A0)+,D1 ;Eintrag suchen
beg vblinex3
dbra D0,vblinex2
rts ;return (-1) (Fehler)
vblinex3:
move.l D2,-(A0) ;neuer Eintrag
moveq #0,D0
rts ;return(0)
;-------------------------------------------------
; logischen Bildschirm löschen (VBL-Routine)
; und Tastatur-Scancode holen
;-------------------------------------------------
_vbl:
tst.w clrflag ;screen löschen ?
beq _vbl2
movem.l D0-D1/A0,-(SP)
move.l screenl,A0 ;aktueller logbase
move.l scrsize,D0 ;Bildschirmgröße
lsr.l #2,D0 ;in longwords
move.w clr_val,D1 ;Hintergrundfarbe
swap D1
move.w clr_val,D1 ;als longword
cls:
move.l D1,(A0)+
subq.l #1,D0
bgt cls
clr.w clrflag ;Flag löschen
move.l $4BA,D0 ;Zeitmessung eines
move.l timer,D1 ;gesamten Zyklus’
move.l D0,timer
sub.l D1,D0
move.w D0,zeit ;Zeit merken
movem.l (SP)+.D0-D1/A0
_vbl2: ;Tastaturscancode holen
move.b $FFFFFC02,scancode+1
rts
;-------------------------------------------------
DATA
;-------------------------------------------------
timer: DC.L 0
Klaus Heyne