Hinweis: Eine Sammlung der besten Programme, die wir für Jugend forscht geschrieben haben, kann hier gezogen werden.
Fachgebiet und Thema: Mathematik / Informatik Kurzfassung
Entwicklung hochoptimierter Hi-Color Routinen in SVGA für DOS PC's.Unsere Jugend-forscht-Arbeit beschäftigt sich mit der Entwicklung von Videoroutinen für PCs. Die Anforderung war die Programmierung von Videobibliotheken für PCs mit einem Minimum an Aufwand für möglichst viele verschiedene Auflösungen und Farben. Der "normale" Weg der Programmierung des SVGA-Modus wird im Allgemeinen so aussehen, daß für jeden Bildschirmmodus eigene Routinen entwickelt werden. Dem spricht eigentlich auch nichts entgegen, zumal dieses Vorgehen die Entwicklung hochoptimierter Routinen unterstützt. Es erfordert jedoch eine komplette Neuentwicklung der Routinen für jeden einzelnen Modus. Ein nahezu unmögliches Unterfangen für kleine Firmen oder gar Einzelpersonen, wie z.B. Shareware-programmierer. Unsere Idee war jedoch eine andere. Da wir bereits eine große Sammlung an Routinen für den MCGA-Modus 13h (320x200x256) entwickelt hatten und wir nicht für jede andere Auflösung eigene Routinen entwickeln wollten, kam uns die Idee, den Bildschirm in SVGA-Auflösung (z.B. bei 640x400 oder 640x480 Bildpunkten) nicht mehr als eine Einheit zu betrachten, sondern diesen in kleine Blöcke aufzuteilen. Daher ergab sich kanonisch eine Aufteilung der "höheren" Bildschirmauflösungen in 320x200 große Pixelblöcke. Jeder Block wird also als virtuelle Seite eines MCGA-Bildschirms angesehen. Zusammen ergeben sie dann einen virtuellen Bildschirm einer höheren Auflösung. Bei einer Auflösung von 640x400 Punkten besteht der Bildschirm nun also aus vier 320x200 Pixel großen Blöcken. Ein 640x480 Pixel großes Bild aus sechs 320x200 Pixel großen Blöcken, wobei die untersten beiden Blöcke nur zu 80 Pixelreihen sichtbar sind ( Siehe dazu auch Bild 1 ). Dazu analog haben wir anschließend Routinen für die HiColor-Modi ( 65.536 Farben ) entwickelt, d.h. wir sind noch einen Schritt weiter als die aktuelle Entwicklung der Industrie gegangen ( die gerade erst mit der Entwicklung von Echtfarbenbibliotheken beginnt ). Der Vorteil unseres Vorgehens ist, daß die Zeit für die Entwicklung neuer Funktionalitäten einer bestehenden Video-Bibliothek und die Entwicklung ganz neuer Bibliotheken für eine andere Auflösung etc. drastisch verringert wird, so daß es nun selbst kleinen Firmen und Einzelpersonen möglich ist, eigene Grafikbibliotheken zu entwickeln, die den hohen Qualitätsansprüchen bzgl. Stabilität, Geschwindigkeit und Bedienbarkeit genügen. Die vorliegende Jugend-forscht-Arbeit hat diese unsere Entwicklungen - Hx3 genannt - zum Inhalt.
Langfassung
1.) Einleitung Hi-Speed, Hi-Color, Hi-Resolution
Die multifunktionale Videoengine für PCs
Gliederung:
2.) Entwicklung der Routinen
2.1) Der "normale" Weg
2.2) Unser Weg
2.3.) Umfang und Funktionalitäten von Hx3
3.) Betatester und Meinungen
4.) Glossar
5.) Literatur
Anhang: Bild1, Bild2
1.) Einleitung :
Jeder kennt sie, die reichhaltige Anzahl an Sharewarespielen mit den 256 Farben in der sogenannten "MCGA-Klötzchenauflösung". Dahingegen ist der SVGA-Bereich mit Spielen rar gesät, denn die Programmierung der hochauflösenden SVGA Grafikkarten ist BISHER den großen Softwareschmieden vorbehalten gewesen. BISHER? Ja, denn dieser Umstand wird hiermit geändert! Aber HALT! Diese Arbeit beschäftigt sich nicht nur mit der Entwicklung von praxistauglichen (und damit kommerziell einsetzbaren) Super-VGA-Routinen bei 256-Farben, sondern geht noch einen Schritt weiter. Während die (Computerspiele-)Industrie gerade erst mit der Entwicklung von HiColor-Spielen beginnt, haben wir bereits eine, in der Praxis einsetzbare, Videoengine in 65.5536 (HiColor) geschaffen, die Hx3 - Videoengine (Hx3 steht für Hi-Speed, Hi-Color und Hi-Resolution). Aus diesem Grund haben wir unsere Arbeit Hx3 - technology getauft.2.) Entwicklung der Routinen :
2.1) Der "normale" Weg :
Der "normale" Weg der Programmierung des SVGA-Modus wird im Allgemeinen so aussehen, daß für jeden Bildschirmmodus eigene Routinen entwickelt werden. Dem spricht eigentlich auch nichts entgegen, zumal dieses Vorgehen die Entwicklung hochoptimierter Routinen unterstützt. Es erforderd jedoch i.A. eine komplette Neuentwicklung der Routinen für jeden einzelnen Modus. Ein unmögliches Unterfangen für kleine Softwarefirmen oder gar Einzelpersonen, wie z.B. Sharewareprogrammierer. Unsere Idee war jedoch eine andere.2.2) Unser Weg :
Da wir bereits eine große Sammlung an Routinen für den MCGA-Modus 13h (320x200 bei 256 Farben) entwickelt haben und wir nicht für jede weitere Auflösung eigene Routinen entwickeln wollten, kam uns die Idee, den Bildschirm in SVGA-Auflösung (z.B. bei 640x400 oder 640x480 Bildpunkten) nicht mehr als eine Einheit zu betrachten, sondern diesen in kleine Blöcke aufgeteilt anzusehen. Wie sich später herausstellen sollte, hatten wir mit diesem Gedanken den Grundstein zu schnell entwickelbaren, sicheren, einfach zu bedienenen und effizienten Videoroutinen gelegt. Innerhalb kürzester Zeit ist es uns (zwei Einzelpersonen) gelungen, den aktuellen Entwicklungsstand der Industrie einzuholen, ja sogar zu überholen! Dieses ohne jegliche finanzielle Unterstützung oder anderweitige Hilfen. Dies bekräftigt unsere These, daß mit guten Ideen auch heute noch mehr erreicht werden kann, als mit einem großen Entwicklerteam und dem Geld eines Konzerns im Rücken. Nun zurück zu unser Idee: Wie bereits erwähnt, hatten wir Routinen für den Modus 320x200 bei 256 Farben entwickelt. Daraus ergibt sich kanonisch eine Aufteilung der "höheren" Bildschirmauflösungen in 320x200 große Pixelblöcke. Bei einer Auflösung von 640x400 Punkten besteht der Bildschirm nun also aus vier 320x200 Pixel großen Blöcken. Ein 640x480 Pixel großes Bild aus sechs 320x200 Pixel großen Blöcken, wobei die untersten beiden Blöcke nur zu 80 Pixelreihen sichtbar sind (Siehe dazu auch Bild 1). Dazu analog haben wir anschließend Routinen für die HiColor-Modi entwickelt, d.h. wir sind noch einen Schritt weiter, als der aktuelle Entwicklungsstand der Industrie gegangen. Das Ergebnis dieser Arbeit haben Sie gerade vor sich liegen und heißt Hx3. Der Vorteil unseres Vorgehens ist, daß die Zeit für die Entwicklung neuer Funktionalitäten einer bestehenden Video-Bibliothek und die Entwicklung ganz neuer Bibliotheken für eine andere Auflösung etc. drastisch verringert wird. Der Programmierer kann sich nun auf das, für ihn Wichtige, konzentrieren, nämlich die Entwicklung des eigentlichen Programms und nicht die Entwicklung neuer Videoroutinen. Durch die Aufteilung des Bildschirms in 320x200 große Blöcke entsteht natürlich ein künstlich erzeugter Verwaltungsaufwand, ein sog. Overhead. Man mag vermuten, daß die eigentlichen Videoroutinen zusammen mit dem Overhead sehr viel langsamer sind als die entsprechenden Routinen, die nach der konventionellen Methode entwickelt worden sind. Dem ist jedoch nicht so, denn zum einen ist der zusätzliche Verwaltungsaufwand sehr gering und zum anderen können die Routinen für den Modus 320x200 sehr stark optimiert werden (durch Einsatz von Assembler) , so daß in der Praxis keine Geschwindigkeitsunterschiede vorhanden sind. Ein Programm/Spiel, welches die Hx3 - Bibliothek verwendet, soll jedoch nicht nur schnell, sondern auch stabil sein, d.h. es soll nicht zu Programmabstürzen aufgrund der Videoroutinen kommen. Die Hx3 - Bibliothek erfüllt diese Anforderung, denn die Entwicklung von Routinen für eine Bildschirmauflösung von 320x200 Punkten bei 256 Farben (MCGA-Auflösung) ist sehr einfach und übersichtlich. Außerdem existieren bereits zahlreiche Anleitungen und Sourcen zur Programmierung dieser Bildschirmauflösung. Es treten also im Allgemeinen wenige Programmierfehler auf. Der für höhere Auflösungen zusätzliche Verwaltungsoverhead stellt kein zusätzliches Risiko für die Stabilität dar, da im Grunde nur die alten Routinen für den MCGA-Modus 320x200 benutzt werden. Außerdem wurde der Overhead in einer Hochsprache (Borland Pascal) entwickelt, was zusätzliche Stabilität garantiert. Aber auch die besten Grafikroutinen sind unbrauchbar, wenn sie in der Praxis nicht einsetztbar sind. Das Problem, mit dem die Programmierer von SVGA-Grafikkarten zu kämpfen haben, ist, daß jeder Hersteller sein eigenes "Süppchen kocht", d.h. die Grafikkarten sind i.A. nicht kompatibel zueinander. Deshalb hat das Standardisierungsgremium VESA einen Videostandard VBE (Video Bios Extensions) ins Leben gerufen. Die Hx3 - Bibliotheken basieren auf diesen Videostandard, der ausnahmslos von allen Grafikkarten unterstützt wird. Damit ist eine hohe Praxistauglichkeit der Hx3 - Bibliotheken erreicht worden. Die Grafikroutinen der Hx3 - Bibliotheken arbeiten mit jeder Standard-SVGA-Grafikkarte zusammen, die die entsprechenden HiColor-Auflösungen zur Verfügung stellen. Zur Darstellung von flimmerfreien und flüssigen Animationen unterstützt Hx3 die Verwaltung von virtuellen Bildschirmseiten. Es können beliebig viele virtuelle Bildschirmseiten verwaltet werden. Die Anzahl ist nur durch den Hauptspeicher des Rechners begrenzt (jede virtuelle Seite im Modus 10Eh (320x200x64k) benötigt 128 kByte und im Modus 111h (640x480x64k) 640kByte). Dies wird dadurch erreicht, daß die Routinen im Protected Mode ablaufen, d.h es besteht keine, wie unter DOS üblich, 640kB Hauptspeicherbegrenzung. Da im Grunde nur die alten Routinen für den Modus 320x200 benutzt wurden, wird bei der Erstellung von Routinen für höhere Auflösungen eine hundertprozentige(!) Wiederverwendung des alten Codes erreicht, wie es nicht einmal in der objektorientierten Programmierung (OOP) der Regelfall ist. Es ist mit unserem Verfahren möglich, durch Verändern weniger Zeilen Code die verschiedensten Auflösungen zu programmieren. Gerade für Einzelpersonen, wie z.B. Sharewareprogrammierer, war das bisher ein unmögliches Unterfangen. Da es in den HiColor-Modi keine Palette mehr gibt wie in den 256-Farben-Modi, in der die Farbwerte für die 256 Farben von 0 bis 255 festgelegt werden, sondern alle möglichen Farben aus der gesammten Palette gleichzeitig dargestellt werden können, haben wir noch einige zusätzliche Prozeduren für die Hx3-Bibliotheken entwickelt. Dazu gehören unter anderem die Möglichkeit zur realistischen Darstellung von Wolken. Sie können z.B. sehen, wie Wolken über einen Hintergrund herüberfliegen und den alten Hintergrund je nach Dichte der Wolke durchscheinen lassen bzw. verdecken. Auch Lichteffekte, wie z.B. das Leuchten von Sternen etc. kann nun sehr einfach simuliert werden ( Dazu haben wir einige Beispielprogramme zur Demonstration vorbereitet ). Während der Entwicklung der Hx3 Bibliotheken haben viele Freiwillige auf der ganzen Welt diese erprobt und getestet. Einen Auszug aus den Meinungen der Tester finden Sie unter dem Punkt 3.)2.3.) Umfang und Funktionalitäten von Hx3 :
Die Hx3 - VideoHiColor - Grafik Engine basiert auf unserem eigenen Video-Management System. Dieses ist die Grundlage für die gesammten Videoroutinen, die wir bisher entwickelt haben. Es existieren derzeit entsprechende Bibliotheken für folgende ModiAlle Bibliotheken umfassen nahezu denselben Funktionsumfang. Alle bieten zahlreiche Funktionalitäten zur Eingabe/Ausgabe von Sprites, Paletten etc. Das Manipulieren von Sprites, das Zeichnen und Sichern selbiger wird ebenfalls unterstützt. Auch können in jedem Modus Sprites transparent gezeichnet werden. Zum Erstaunen vieler wird auch in ALLEN Auflösungen das Skalieren , d.h. das Zeichnen von Sprites in unterschiedlicher Größe und Breite in Echtzeit, selbst in den HiColor - Modi, unterstützt. Insgesammt bieten die Hx3 - Bibliotheken über 80 Funktionalitäten. Entwickelt und optimiert wurden diese für Borland Pascal und laufen ausschließlich im Protected Mode, d.h. sie können, wie bereits erwähnt, den gesammten Arbeitsspeicher des Rechners ausnutzen und haben keine hinderliche 640kB Grenze. Da außerdem 32bit-Operationen zum Kopieren und Verschieben von Daten benutzt werden, ist die minimale Hardwareanforderung ein 386er Prozessor mit 1 MB Ram und einer VESA-kompatiblen (S)VGA-Grafikkarte. Übersicht über die Hx3 - Bibliothek eigenen Funktionalitäten für die Auflösungen 320x200x64k (Mode 10Eh) und 640x480x64k (Mode 111h) :
- Mode13h (320 x 200 x 256)
- Mode100h (640 x 400 x 256)
- Mode101h (640 x 480 x 256)
- Mode10Eh (320 x 200 x 65536 = 320 x 200 x 64k)
- Mode111h (640 x 480 x 65536 = 640 x 480 x 64k)
Alle nun folgenden Routinen berücksichtigen den mit SetWindow10Eh/111h gesetzten Fensterrahmen, d.h. nur innerhalb des gesetzten Fensterrahmens werden die Routinen tatsächlich ausgeführt. Soll z.B. ein Sprite nur innerhalb des Fensterrahmens links-oben / rechts-unten (Koordinaten (10, 10) / (320, 200)) gezeichnet werden, so wird zunächst mit SetWindow10Eh/111h(10, 10, 320, 200) der Fensterrahmen festgelegt und anschließend die Prozedur PutSpriteWindow10Eh/111h benutzt. Ist das Sprite nur halb sichtbar, z.B. wenn eine Spielfigur nur halb im Fensterrahmen steht, so wird diese auch nur in dem sichtbaren Bereich auf dem Bildschirm gezeichnet. (Siehe dazu auch Bild 2).
- initialisieren / schließen des VideoSystems
procedure InitVideo10Eh/111h;
procedure CloseVideo10Eh/111h;- setzen der gerade aktiven virtuellen Bildschirmseite; auf dieser Seite werden dann alle Bildmanipulationen ausgeführt
procedure ActivePage10Eh/111h( var page : TPage10Eh/111h );- Setzen eines Videomodus, z.b: mode = Mode111h für den Modus 640x480 bei 65.536 Farben
procedure SetVideomode10Eh/111h( mode : word);- festlegen eines Fensterrahmens; nur innerhalb dieses Fensterrahmens werden die eigentlichen Routinen tatsächlich ausgeführt (Siehe dazu auch Bild 2).
procedure SetWindow10Eh/111h( x1, y1, x2, y2 : longint );- kopieren eines virtuellen, d.h. nicht sichtbaren Bildschirms, in einen anderen virtuellen Bildschirm
procedure CopyP2P10Eh/111h( var Src, Dst : TPage10Eh/111h );- kopieren eines virtuellen Bildschirms auf den visuellen Bildschirm, d.h. kopieren in den, auf dem Monitor sichtbaren, Grafikspeicher
procedure CopyP2V10Eh/111h( var page : TPage10Eh/111h );- löschen eines virtuellen Bildschirms, d.h. auffüllen mit Nullbytes
procedure ClearPage10Eh/111h( page:TPage10Eh/111h);- löschen des visuellen, d.h. sichtbaren, Bildschirms
procedure ClearVisualPage10Eh/111h;- initialisieren einer neuen virtuellen Bildschirmseite
procedure InitPage10Eh/111h( var page : TPage10Eh/111h );- schließen einer virtuellen Bildschirmseite; muß zuvor mit InitPage10Eh/111h geöffnet worden sein
procedure ClosePage10Eh/111h( var page : TPage10Eh/111h );- zeichnet einen Punkt der Farbe c direkt auf den sichtbaren Bildschirm
procedure DirectPutPixel10Eh/111h( x, y : integer; c : word );- holt sich die Farbe des angegebenen Punktes von dem sichtbaren Bildschirm
function DirectGetPixel10Eh/111h( x, y : integer ):word;- zeichnet einen Punkt der Farbe c in den zuletzt mit ActivePage10Eh/111h ausgewählten virtuellen Bildschirm; ignoriert den mit SetWindow10Eh/111h gesetzten Fensterrahmen
procedure PutPixel10Eh/111h( x, y : integer; c : word );- holt sich die Farbe eines Punktes von der virtuellen Bildschirmseite, die zuletzt mit ActivePage10Eh/111h ausgewählt worden ist; ignoriert den mit SetWindow10Eh/111h gesetzten Fensterrahmen
function GetPixel10Eh/111h(x,y:integer ) : word;- zeichnet eine Line in eine virtuelle Seite; achtet jedoch dabei nicht auf den mit SetWindow10Eh/111h gesetzten Fensterrahmen
procedure Line10Eh/111h( x1, y1, x2, y2 : Integer; color : word);
- zeichnet ein Sprite in die gerade aktive virtuelle Bildschirmseite
procedure PutSpriteWindow10Eh/111h(x,y:integer; p: TSprite );- zeichnet ein Sprite in die gerade aktive virtuelle Bildschirmseite; zudem kann jedoch ein Farbwert angegeben werden, der als transparent behandelt werden soll. Diese Prozedur dient dazu, um z.B. eine Spielfigur auf einem Hintergrund zu zeichnen, ohne den Hintergrund zu überschreiben
procedure PutSpriteWindowTrans10Eh/111h(x,y:integer; trans:word; p: TSprite );- zeichnet ein Sprite in die gerade aktive virtuelle Bildschirmseite, indem es den Inhalt der Bildschirmseite um die Werte SubR, SubG und SubB abdunkelt. SubR ist dabei der RotAnteil, SubG der GrünAnteil und SuB der BlauAnteil der abgedunkelt werden soll.
procedure PutSpriteWindowShadow10Eh/111h(x,y:integer; SubR, SubG, SubB : byte; p: TSprite );- funktioniert analog zu PutSpriteWindowShadow10Eh/111h, nur das der Inhalt des virtuellen Bildschirms nicht abgedunkelt, sondern aufgehellt wird.
procedure PutSpriteWindowLight10Eh/111h(x,y:integer; AddR, AddG, AddB : byte; p: TSprite );- mischt die Farbwerte des Sprite mit den Farbwerten des Inhalt der gerade aktiven virtuellen Bildschirmseite zusammen, indem es den Mittelwert berechnet
procedure PutSpriteWindowMix10Eh/111h(x,y:integer; p: TSprite );- addiert die Farbwerte des Sprite auf die Farbwerte des Inhalts der gerade aktiven virtuellen Bildschirmseite
procedure PutSpriteWindowAdd10Eh/111h(x,y : integer; p : TSprite);- zeichnet einen Punkt mit dem Farbwert c auf die gerade aktive virtuelle Bildschirmseite
procedure PutPixelWindow10Eh/111h(x,y : longint; c :word);- holt sich den Farbwert eines Punktes von der gerade aktiven virtuellen Bildschirmseite
function GetPixelWindow10Eh/111h(x,y : longint):word;- zeichnet ein ausgefülltes Rechteck mit der Farbe c in die gerade aktive virtuelle Bildschirmseite
procedure RectangleWindow10Eh/111h(x1,y1,x2,y2,x3,y3,x4,y4:longint; c : word);- zeichnet ein ausgefülltes Dreieck mit der Farbe c in die gerade aktive virtuelle Bildschirmseite
procedure TriangleWindow10Eh/111h(x1,y1,x2,y2,x3,y3:longint; c : word);- zeichnet eine Linie mit der Farbe c in die gerade aktive virtuelle Bildschirmseite
procedure LineWindow10Eh/111h( x1, y1, x2, y2 : longint; c : word );- holt sich den Bildschirminhalt der gerade aktiven virtuellen Bildschirmseite von der Position (x,y) in das Sprite p; dient z.B. dazu, um Hintergründe zu sichern oder zur Realisierung eines Mauszeigers
procedure GetSprite10Eh/111h(x,y:integer; p: TSprite );- zeichnet das Sprite p an der Position (x,y) mit der Breite dx und Tiefe dy; mit dieser Prozedur kann also ein Sprite beliebig skaliert werden und das bei 64k Farben!
procedure PutSpriteScaled10Eh/111h(x,y,dx,dy:integer; p: TSprite );- analog zu PutSpriteScaled10Eh/111h, jedoch wird hier der Scalierungsfaktor in Prozent angegeben und aus der realen Breite und Tiefe des Sprites berechnet.
procedure PutSpritePerCent10Eh/111h(x,y:integer; factor:real; p : TSprite);- funktioniert analog zu PutSpriteScaled10Eh/111h; es kann jedoch zusätzlich noch ein Farbwert Tcol angegeben werden, der als transparent betrachtet werden soll
procedure PutSpriteScaledTrans10Eh/111h(x,y,dx,dy:integer; Tcol:word; p: TSprite );- funktioniert analog zu PutSpritePerCent10Eh/111h; es kann jedoch zusätzlich noch ein Farbwert Tcol angegeben werden, der als transparent betrachtet werden soll
procedure PutSpritePerCentTrans10Eh/111h(x,y:integer; factor:real; Tcol:word; p : TSprite );3.) andere Meinungen zu Hx3 :
PC-Spiel 12/96: "VideoHi ... ist ein besonderes Schmankerl für alle Spieleprogrammierer unter unseren Lesern. Diese Routinensammlung erlaubt Grafikprogrammierungen für Turbo Pascal bei einer Bildschirmauflösung von 640 x 480 Punkten. ... "Auswahl aus ca. 150 eMails die uns via Internet erreicht haben:
5 May 1996 Stefan Ihringer; Deutschland "...Das Toolkit fuer VESA ist genau das, wonach ich gesucht habe..."
15 Sep 1996 Mogamat Abrahams; Toakai Computers/Cyberworx "...PS: Please inform Me of Updates to your toolkits as I think they Are EXCELLENT !!!!!."
30 Sep 1996 Absender unbekannt; Frankreich "...the toolkit video13h is really fast and easy to use. i'am looking for registering this software. how much does it cost?"
6 Oct 96 Bastian Hanisch; Deutschland "Hi. Ich habe neulich über's FIDOnet ne Empfehlung deiner Internet-Site gesehen. Ich muss sagen, die ist wirklich gelungen. [...] Ich hätte gerne mehr Infos uber Virtech und vor allem uber eure Demos und GFX-Proggis."
8 Oct 1996 Jason Job; Österreich "...Sounds like a brilliant lot of code you've got, though..."
8 Oct 1996 Christian Lassem; Norwegen "I would love a copy of these (Videoroutines), if you could mail them to me!"
11 Oct 1996 Lanny Sher; Taiwan; NATIONAL CHIAO TUNG UNIVERSITY (Alumni Center) "I want to register your video101h and video13h toolkit. Please tell me how to register it ?"
17 Oct 1996 Robert Dytmire; Technical Support Manager bei Access Corporation "An excellent kernal! ... I have a couple of questions before I decide to convert all 6000 lines of code to your kernal... I'd like to fully implement this engine layer over your high resolution kernals... "
13 Nov 1996 Ray Charest; Kanada "...I would like to ask your permission to post it our website to make it (the files) available for download... "
28 Nov 96 Andy Yeo; Malaysia "Dear video gurus can I please ask how much is the registeration of your pascal libs?..."
Zu erhalten sind die Hx3 - Bibliotheken unter anderem von der Homepage von Ansgar Scherp und Joachim Gelhaus: http://www.artis.uni-oldenburg.de/~ansgar/ Oder via ftp von folgenden ftp-Servern: ftp.x2ftp.oulu.fi ftp.tu-clausthal.de Und diverse weitere ftp-Server und Spiegelungen.
4. Glossar :
Pixel = Bildpunkt; eindeutig adressierbar über x- und y-Koordinate
Sprite = i.d.R. quadratischer Bildausschnitt zur Darstellung von Animationen etc.
visueller Bildschirm = der vom Benutzter sichtbare Bildschirm; Monitorbild
virtueller Bildschirm = nichtsichtbarer Bildschirm; in diesem kann das spätere
Monitorbild im "Hintergrund" ( für den Benutzer nicht sichtbar ) aufgebaut werden und anschließend auf den visuellen Bildschirm in "einem Rutsch" kopiert werden Bibliothek = Sammlung von ähnlichen und zusammengehörenden Routinen in einer Datei
Funktionalität = stellt eine bestimmte Tätigkeit/Funktion zur Verfügung; das Zeichnen eines Sprites oder das Setzen eines Bildpunktes stellt eine Funktionalität dar
Overhead = hier: Der Aufwand in den höheren Bildschirmauflösungen zur Verwaltung der eigentlichen Grafikfunktionalitäten
Palette = existieren nur bei Auflösungen bis zu 256 Farben; in der Palette werden die Farbwerte für die 256 Farben von 0 bis 255 festgelegt
Modi = ist ein bestimmter Bildschirmmodus; durch den Modus ist die Auflösung und die Farbanzahl eineindeutig ( bijektiv ) definiertHiColor = Bildschirmauflösungen mit einer max. gleichzeitig darstellbaren Farbanzahl von 65.536 Farben
- Mode13h = MCGA = Normal/Standard VGA = 320 x 200 Bildpunkte und 256 Farben
- Mode100h = 640 x 400 Bildpunkte und 256 Farben
- Mode101h = 640 x 480 Bildpunkte und 256 Farben
- Mode111h = 320 x 200 Bildpunkte bei 65.536 ( = 64k ) Farben
- Mode10Eh = 640 x 480 Bildpunkte bei 65.536 ( = 64k ) Farben
A x B x C = Breite in x-Richtung x Tiefe in y-Richtung x max. Anzahl an gleichzeitig darstellbaren Farben
5.) Literatur :
[1] c't 6 / 95 [2] PC Games Programmers Encyclopedia version 1.0Anhang : Bild1, Bild 2
