DGL Wiki - Benutzerbeiträge [de]

Diskussion:Tutorial Quickstart

2007-07-15T21:17:38Z

Infinite: "...auf SDL umgestellt..."

;Efficiency:
Die DGLOpenGL.pas funktioniert leider nicht mit Delphi 3. Gibt's da was älteres Brauchbares oder muss ich die von Borland mitgelieferte nehmen? Gruß Efficiency

;Flo:
Delphi 3??? Nimm Lazarus [http://www.lazarus.freepascal.org/index.php ] wenn du eine IDE brauchst und FreePascal als Compiler!

;Efficiency:
Danke für den Tipp, ich kenne Lazarus noch zu wenig. Und leider haben wir etwa 600.000 Zeilen Quelltext der sich nur in Delphi 3 problemlos kompilieren lässt...

;Flo:
600.000 Zeilen Quelltext die nun um OpenGL funktionalitaet erweitert werden sollen? Ich bin erlich gesagt etwas ueberrascht. Hatte erwartet das du ein paar Beispielprogramme zum ueben erstellen willst.

;Efficiency:
Ist ja auch so. Erst bisschen üben. Dann muss es aber bald rund gehen ;-) Bei Lazarus habe ich Angst wegen der Leistungsfähigkeit. Die Compilergeschwindigkeit ist beim Übersetzen ja leider deutlich langsamer. Ich müsste mal testen, wie es mit der Geschwindigkeit des Codes im Vergleich zu Delphi 3 aussieht. Aber erstmal werden wir sicher bei Delphi 3 bleiben müssen. Wir haben zwar neuere Delphi-Versionen, aber Delphi 4 hat nicht gelohnt und bei Delphi 5 waren die Umstellungen schon zu groß. Und Delphi 3 kann praktisch alles, was für uns wichtig ist. Wenn jetzt 64 Bit kommt und auch was bringt, dann müssen wir uns generell neu orientieren.

Nochmal die Frage: Gibt es vielleicht einen besseren OpenGL Header für Delphi 3 als den von Borland mitgelieferten?

;Flo:
Such mal im Forum, denke das hat schonmal jemand gesucht. Ansonsten brauchst du dir bei der Ausfuergeschwindigkeit bei FreePascal keien sorgen machen. Nur die Dateigroesse ist bei LCL Einsatz bei Lazarus groesser als bei Delphi mit VLC.

Ja. Guck ins Forum. Wir haben schon ein paar Anfragen zu dem Thema gehabt.
--[[Benutzer:Flash|Flash]] 18:19, 16. Jan 2006 (CET)

;Efficiency
Jo. Danke. Und danke auch an [http://www.basegraph.com Mars]. Das Ding findet sich unten auf dieser Seite: [[DGLOpenGL.pas]]

== "...auf SDL umgestellt..." ==

Dann hab ich mir die TForm wohl nur eingebildet :)

Tutorial Quickstart

2006-08-21T16:35:35Z

Infinite: /* Nachwort */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL, wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man, um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen, nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz sich schon nach den ersten 3 Wochen Programmierarbeit den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt, werdet Ihr es schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe), dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und dem letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen, kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschlägen ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial Quickstart

2006-08-21T16:34:11Z

Infinite: /* Tipps für den OpenGL Anfänger */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL, wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man, um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen, nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz sich schon nach den ersten 3 Wochen Programmierarbeit den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt, werdet Ihr es schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe), dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und dem letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschläge ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial Quickstart

2006-08-21T16:26:05Z

Infinite: /* Methode 1: Timer */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL, wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man, um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen, nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz schon nach den ersten 3 Wochen Programmierarbeit sich den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt werdet Ihr schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe) dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und den letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschläge ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial Quickstart

2006-08-21T16:22:14Z

Infinite: /* Die Ereignisbehandlung */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL, wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man, um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz schon nach den ersten 3 Wochen Programmierarbeit sich den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt werdet Ihr schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe) dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und den letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschläge ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial Quickstart

2006-08-21T16:21:33Z

Infinite: /* Die Ereignisbehandlung */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL, wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz schon nach den ersten 3 Wochen Programmierarbeit sich den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt werdet Ihr schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe) dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und den letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschläge ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial Quickstart

2006-08-21T16:18:49Z

Infinite: /* Das Template - Delphi fit für OpenGL machen */

=Quickstart: Delphi & OpenGL=

==Einleitung==

Willkommen beim Delphi & OpenGL Quickstart. Diese kurze Einleitung soll euch auf die Tutorials bei DelphiGL.com und allgemein auf die Grafikprogrammierung mit OpenGL und Delphi vorbereiten. Dieser Quickstart ist kein Tutorial für sich, sondern soll ein Grundgefühl vermitteln wie OpenGL und Delphi miteinander arbeiten.

Wozu OpenGL? Mit OpenGL kann man eine Vielzahl von Aufgaben bewältigen. Ob man Forschungsergebnisse aller Art visualisieren, 2D oder 3D Spiele schreiben oder einfach seiner Anwendung eine Oberfläche geben möchte, die nicht dem windowsgrauen Standardlook entspricht. All das ist möglich mit OpenGL.

==Wie fange ich an?==
Genau zwei Dinge braucht der OpenGL-Programmierer um effektiv arbeiten zu können:
#Einen OpenGL Header
#Eine Codebasis von der aus man neue Projekte starten kann (ein sog. Template)

===Der OpenGL-Header===
Das is ja easy! Denn Delphi bringt ja schon einen OpenGL-Header mit...

'''STOP!'''

Denn wir reden von einem guten Header. Leider ist der original von Delphi mitgelieferte Header alles andere als zu empfehlen. Er ist fehlerhaft, hält sich nicht an OpenGL-Normen und außerdem ist er absolut veraltet.

Was nun? Ganz einfach: Bei [http://www.DelphiGL.com DelphiGL.com] (kurz DGL) gibt es '''DEN''' OpenGL-Header für alle Pascalsprachen:
'''Die [[DGLOpenGL.pas]].'''

Diesen solltet Ihr euch jetzt besorgen, wenn Ihr ihn nicht schon habt. Der Header wird bei neuen OpenGL-Versionen vom DGL-Team aktualisiert.

===Codebasis/Templates===
So... das war schon alles was Ihr aus dem Netz benötigt. Den Rest machen wir jetzt per Hand.

Im nächsten Kapitel zeige ich euch wie man sich ein einfaches [[Template]] schreibt. Natürlich hat DelphiGL.com auch bereits [http://www.delphigl.com/download.php?cat=1 fertige Lösungen], die durchaus zu empfehlen sind und auch extra Features wie Vollbildrendering besitzen. ABER aus Erfahrung kann ich sagen: Man findet sich im eigenen Code viel einfacher zurecht. (Und die Extras kann man nachher immer noch einbauen.)

==Das Template - Delphi fit für OpenGL machen==
Bevor man wirklich loslegen kann, muss noch die runtergeladene DGLOpenGL.pas an den richtigen Ort gebracht werden. Gut wäre z. B., sie in das Verzeichnis "\lib" in Eurem Delphiverzeichnis zu legen. (Wenn ihr den [[DGLSDK]] verwendet wurden die Suchpfade schon eingerichtet.)

Dann startet mal Delphi. Vor euch sollte jetzt ein leeres Projekt erscheinen. Das leere Formular kann gleich minimiert werden, denn jetzt wird erstmal hübsch gecodet.

''(Am Ende von Kapitel 1.3 findet ihr den Kopf der Template-Klasse. Dort seht ihr auch welche Variablen, von welchem Typ deklariert werden müssen. )''

===Initialisieren von OpenGL===
Dieser Teil ließ früher dem OpenGL Anfänger die Haare nicht nur zu Berge stehen, sondern gleich ausfallen. Dank der DGLOpenGL.pas wurde das aber um Längen einfacher.

Zuerst einmal solltet Ihr die DGLOpenGL.pas in die '''uses'''-Klausel des '''interface'''-Teils der Unit1 schreiben.

Die eigentliche Initialisierung soll direkt beim Erstellen des Formulars gemacht werden. Deshalb kommt der folgende Quelltext ins OnCreate-Ereignis des Formulars.
<pascal>procedure TForm1.FormCreate(Sender: TObject);
begin
DC:= GetDC(Handle);
if not InitOpenGL then Application.Terminate;
RC:= CreateRenderingContext( DC,
[opDoubleBuffered],
32,
24,
0,0,0,
0);
ActivateRenderingContext(DC, RC);
end;</pascal>
'''Zeile 3:''' Hier wird der Gerätekontext (Device Context) von Formular Form1 abgefragt.

'''Zeile 4:''' Mit InitOpenGL wird OpenGL initialisiert. Wenn das nicht funktioniert wird die gesamte Anwendung sofort beendet.

'''Zeile 5:''' Hier wird der [[Renderkontext]] erzeugt. Den braucht OpenGL zum Zeichnen auf das Formular. Was die Parameter genau bewirken lernt ihr im [[Tutorial_lektion1]].

'''Zeile 11:''' Abschließend wird der Renderkontext aktiviert. OpenGL ist jetzt prinzipiell startbereit.

{{Hinweis|DC und RC sind Eigenschaften des Formulars. Siehe [[Tutorial_quickstart#Das_fertige_Templateformular|Definition des Templateformulars]].}}

Nach dieser durchaus simplen Initialisierung (man kann auch alles per Hand machen was InitOpenGL macht!) steht OpenGL ziemlich nackt da. Soll heißen, alle OpenGL Eigenschaften/Zustände stehen auf den definierten Anfangswerten. Es kommt aber durchaus oft - eigentlich ständig - vor, dass bestimmte Einstellungen von OpenGL benutzt werden sollen. Deshalb schreiben wir uns noch eine kleine Zusatzprozedur: SetupOpenGL

<pascal>procedure TForm1.SetupGL;
begin
glClearColor(0.3, 0.4, 0.7, 0.0); //Hintergrundfarbe
glEnable(GL_DEPTH_TEST); //Tiefentest aktivieren
glEnable(GL_CULL_FACE); //Backface Culling aktivieren
end;</pascal>

Was hier passiert wird durch die Kommentare bereits erklärt (Für mehr Infos siehe [[Tiefentest]] bzw. [[Backface Culling]]). Die Hintergrundfarbe könnt ihr nach Belieben einstellen. (Wenn ihr später einmal geschlossene Szenen rendern wollt, dann ist es günstig eine sehr schräge Farbe als Hintergrundfarbe einzustellen, so findet man leichter Fehler in der Szene.)

Außerdem hat man ja hin und wieder auch noch globale Variablen, die man initialisieren möchte. Da wir mit solchen Sachen unser schön aufgeräumtes '''FormCreate''' nicht zumüllen wollen bietet sich ein Unterprogramm namens '''InitGlobals''' oder kurz '''Init''' an.
Beide Unterprogramme (SetupGL und Init) sollten am Ende von '''FormCreate''' gerufen werden:

<pascal> [...]
ActivateRenderingContext(DC, RC);
SetupGL;
Init;
end;</pascal>

===Die Ereignisbehandlung===
Für OpenGL sind vor allem die Ereignisse von Bedeutung, die an der Zeichenfläche von OpenGL herumwerkeln. Da OpenGL direkt auf das Formular (oder auch auf ein Panel) zeichnet, müssen Ereignisse, die diese Zeichenfläche ändern, behandelt werden. Dies wären das '''OnResize-''' und das '''OnDestroy'''-Ereignis.

Zuerst '''FormResize''':
<pascal>procedure TForm1.FormResize(Sender: TObject);
var tmpBool : Boolean;
begin
glViewport(0, 0, ClientWidth, ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
IdleHandler(Sender, tmpBool);
end;</pascal>

Außerdem müssen im '''const''' Teil die beiden Konstanten Near- bzw. FarClipping definiert werden. Diese geben die Entfernung für die [[Clipping Plane|Clippingebenen]] (Szenenbegrenzung) an.

<pascal> NearClipping = 1;
FarClipping = 1000;</pascal>

'''Zu FormResize''':

'''Zeile 2:''' Diese Boolean-Variable wird in Zeile 11 verwendet und ist nur ein Dummy.

'''Zeile 4:''' Mittels [[glViewport]] sagt Ihr OpenGL wie groß die OpenGL-Ausgabe werden soll. Genau diese Größe hatte sich ja durch das Resize verändert.

'''Zeile 5/9:''' Hier seht Ihr 2 der 3 möglichen Matrixmodi. '''GL_PROJECTION''' wird benutzt um nachfolgend die OpenGL-Ausgabe zu manipulieren, '''GL_MODELVIEW''' benutzt man um OpenGL mit Daten zu füttern.

'''Zeile 6:''' [[glLoadIdentity]] füllt die aktuelle Matrix mit der Identitätsmatrix.

'''Zeile 7:''' Hier wird eingestellt wie der Betrachter die Welt sehen soll.

'''Zeile 11:''' Was der IdleHandler macht kommt später im Abschnitt 1.3.3 (Zeichenroutine).

Nun noch schnell das '''FormDestroy''':

<pascal>procedure TForm1.FormDestroy(Sender: TObject);
begin
DeactivateRenderingContext;
DestroyRenderingContext(RC);
ReleaseDC(Handle, DC);
end;</pascal>

Was es macht? Steht doch da: Den RenderingContext deaktivieren und freigeben.

===Die Zeichenroutine===
Das Herzstück unseres Templates fehlte bisher. Irgendwann muss der Grafikkarte ja auch gesagt werden, was sie denn überhaupt ausgeben soll. Das kommt jetzt: '''TForm1.Render'''

<pascal>procedure TForm1.Render;
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45.0, ClientWidth/ClientHeight, NearClipping, FarClipping);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glTranslatef(0, 0, -5);

glBegin(GL_QUADS);
glColor3f(1, 0, 0); glVertex3f(0, 0, 0);
glColor3f(0, 1, 0); glVertex3f(1, 0, 0);
glColor3f(0, 0, 1); glVertex3f(1, 1, 0);
glColor3f(1, 1, 0); glVertex3f(0, 1, 0);
glEnd;

SwapBuffers(DC);
end;</pascal>

'''Zeile 3:''' Dieser Aufruf sorgt dafür, dass der [[Farbpuffer]] und [[Tiefenpuffer]] gelöscht werden. Wenn man das nicht macht, sieht man alles mögliche, nur nicht das was Ihr rendern wollt. Probiert es ruhig mal ohne aus! Man wird dadurch nicht dümmer.

'''Zeile 7:''' Hier wird wieder die Perspektive gesetzt. Dieser Aufruf und der bei '''FormResize'''
müssen von den Parametern identisch sein. Sonst sieht die Ausgabe nach einem Resize kurz anders aus.
Wenn sich die Perspektive zwischen den Renderdurchgängen nicht ändert kann das auch weg gelassen werden.

'''Zeile 12:''' Dieser Aufruf verschiebt die "Kamera" (so etwas gibt es eigentlich nicht, aber das nur am Rande. Mehr zu diesem Thema gibts im [[Tutorial Matrix2]]) etwas nach hinten. Schließlich wollen wir das, was wir zeichnen auch sehen. Alles was zu nah ist wird durch die '''Near-[[Clipping Plane]]''' abgeschnitten.

[[Bild:GlShadeModel_SMOOTH.jpg|right]]

'''Zeile 14:''' [[glBegin]]/[[glEnd]] kapseln die eigentlichen Zeichenbefehle. Diese sorgen hier für ein '''hübsches buntes Viereck'''. Das soll für den ersten Test ausreichen. Wichtig ist in dem Zusammenhang noch folgendes: OpenGL ist es egal woher ein Befehl kommt. Alles wird ausgewertet und landet unter Umständen im Framebuffer. Ihr könnt also ein Unterprogramm, welches ein Unterprogramm, welches ... ..., welches die OpenGL Befehle enthält schreiben. Das interessiert OpenGL bzw. die Grafikkarte überhaupt nicht.

'''Zeile 21:''' [[SwapBuffers]] sorgt dafür, dass der Inhalt des [[Framebuffer]]s auf dem
Bildschirm erscheint. Ohne diesen Befehl seht Ihr gar nichts von OpenGL. (Interessanter Artikel dazu: [[Doppelpufferung]])

So... ganz toll. Jetzt habt Ihr Eure Zeichenfunktion... und nun? Irgendwie müsst Ihr diese auch aufrufen. Das wäre aber zu einfach. Die Ausgabe ändert sich ja normalerweise (z. B. in Spielen). Deshalb muss die Zeichenfunktion immer wieder ausgegeben werden. Dazu gibt es zwei Möglichkeiten, die beide Ihre Vor- und Nachteile haben.

<div align="center">
{|{{Prettytable_B1}}
!Argument
!Timer
!OnIdle
|-
|Maximale Framezahl erreichbar "Benchmark"
|nein
|ja
|-
|Framezahl steuerbar
|ja
|bedingt (/umständlich)
|-
|Für flüssige Animationen nutzbar (Egoshooter)
|bedingt/schlecht
|ja
|-
|Für Menüs nutzbar
|ja
|ja
|-
|Für einfache Animationen nutzbar (Strategiespiele)
|ja
|ja
|-
|Laptopfreundlich (Anti-Akku-Killer)
|ja
|NEIN!
|}
</div>

Wer einfache Anwendungen schreiben möchte, die auch mit 25 FpS (Bilder Pro Sekunde) auskommen und den Akku von Laptopusern schonen will, sollte die Timervariante nutzen. Wer die Potenziale der Grafikkarten voll ausnutzen möchte sollte OnIdle verwenden.

====Methode 1: Timer====
Bei dieser Methode muss ein Timer (zu finden bei den Systemkomponenten) auf das Formular gezogen werden. Der Timer besitzt eine Eigenschaft names "Interval". Mit dieser Eigenschaft kann man einstellen nach wie vielen Millisekunden das Ereignis OnTimer ausgelöst wird. Man kann "Interval" nicht beliebig verkleinern. Werte unter 25 können vom Standardtimer den Windows verwendet nicht mehr korrekt erzeugt werden.

Der Inhalt von OnTimer könnte dieser sein:

<pascal>procedure TForm1.Timer1Timer(Sender: TObject);
begin
inc(FrameCount);
Render;
If FrameCount = 20 then
begin
ErrorHandler;
FrameCount := 0;
end;
end;</pascal>

Tiefgreifende Erklärungen sind hier nicht notwendig. Was der ErrorHandler ist wird nach der Methode 2 erklärt.

====Methode 2: OnIdle====

OnIdle ist ein besonderes Ereignis, welches das gesamte Programm betrifft. Wenn die Anwendung nichts zu tun hat, also faul ist (engl. idle), tritt das Ereignis ein.

Die Methode mit OnIdle kann gleich mit zum Auswerten der Framezahlen (Anzahl Bildwiederholungen pro Sekunde) benutzt werden (Framecounter). Der nachfolgende Code enthält selbigen bereits.

<pascal>procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
StartTime:= GetTickCount;
Render;
DrawTime:= GetTickCount - StartTime;
Inc(TimeCount, DrawTime);
Inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
TimeCount:= TimeCount - 1000;
FrameCount:= 0;
Caption:= InttoStr(Frames) + 'FPS';
ErrorHandler;
end;

Done:= false;
end;</pascal>

'''Zeile 3:''' Mittels GetTickCount wird die Systemzeit gemessen. Dies ist nicht nötig um
erfolgreich zu zeichnen, sondern dient ausschließlich der Berechnung der Framerate. Diese wiederum ist ein guter Performancemesser.

'''Zeile 4:''' Hier erfolgt der Aufruf unserer Zeichenroutine.

'''Zeile 9:''' Der hier angeordnete Block wird nur pro Sekunde einmal ausgeführt und sorgt
dafür, dass die Framerate angezeigt wird. Außerdem wird der Errorhandler aufgerufen.

'''Zeile 14:''' Der Errorhandler wird im Anschluß beschrieben.

'''Zeile 17:''' Wenn ''Done'' nach der Ausführung ''false'' ist und das Programm wieder nichts zu tun
hat, wird OnIdle erneut ausgeführt. Wenn ''Done = true'' ist wird OnIdle nur einmal ausgeführt.

Um auf das "Idle-Event" reagieren zu können, müsst ihr jetzt nur noch diese Funktion an das Event koppeln. Das macht ihr, indem ihr den nachfolgenden Code in die letzte Zeile eurer FormCreate-Methode schreibt.

<pascal>Application.OnIdle := IdleHandler;</pascal>

Wie ihr bald selbst feststellen werdet, sorgt diese Methode für eine hundertprozentige Prozessorauslastung. Umgehen könnt ihr dies mit einem kleinen Trick:

Fügt vor dem "Done := false" (Zeile 17 des IdleHandlers) noch ein sleep(1) oder sleep(5) ein. Dadurch sinkt die Prozessorlast auf ca. 80%, was schon ein Fortschritt ist.

===Der ErrorHandler - Fehler erkannt, Fehler gebannt===
Der Errorhandler ist wieder eine total einfache Funktion, denn OpenGL bietet von Haus aus eine Möglichkeit OpenGL-Fehler zu erkennen. Deshalb ist der ErrorHandler auch so klein:

<pascal>procedure TForm1.ErrorHandler;
begin
Form1.Caption := gluErrorString(glGetError);
end;</pascal>

Enttäuscht? Ihr könnt den ErrorHandler nach belieben auch komplexer machen. Zum Beispiel könnt Ihr anstatt die Fehler im Fenstertitel anzuzeigen lieber den Fehler in ein Logfile schreiben. Ganz nebenbei: Falls kein Fehler auftritt liefert [[glGetError]] '''GL_NO_ERROR'''.

===Das fertige Templateformular===
Eure Klasse TForm1 sollte also jetzt so, oder so ähnlich aussehen:
<pascal>TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure IdleHandler(Sender: TObject; var Done: Boolean);
procedure FormResize(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private { Private-Deklarationen }
StartTime, TimeCount, FrameCount : Cardinal; //FrameCounter
Frames, DrawTime : Cardinal; //& Timebased Movement
procedure SetupGL;
procedure Init;
procedure Render;
procedure ErrorHandler;
public { Public-Deklarationen }
DC : HDC; //Handle auf Zeichenfläche
RC : HGLRC;//Rendering Context
end;</pascal>

'''Zeile 3:''' Wie man sieht benutzt mein Template die zweite Methode (OnIdle).

'''Zeile 8:''' Was [[Timebased Movement]] ist könnt ihr ja mal nachlesen.

'''Zeile 14/15:''' HDC und HGLRC sind Typen die von Windows zur Verfügung gestellt werden. Ihr findet sie in der Unit "Windows". (Diese Unit sollte bei einem neuen Projekt bereits durch Delphi eingebunden worden sein.)

So... fertig. Eigentlich seid Ihr jetzt soweit von den Tutorialschreibern so richtig mit OpenGL-Wissen voll gepumpt zu werden. Das nachfolgende Kapitel könnt Ihr euch trotzdem ruhigen Gewissens durchlesen. Wer es liest tappt vielleicht nicht gleich bei der ersten Frage im DGL-Forum ins berüchtigte Fettnäpfchen.

==Tipps für den OpenGL Anfänger==
Wenn man mit OpenGL anfängt ist man meist total perplex und ein "Das war ja einfach!" huscht einem nicht nur einmal über die Lippen. Vor allem zu Beginn Eurer OpenGL-Karriere werdet Ihr viel lernen und dabei nur auf verhältnismäßig geringen Widerstand stoßen. Aber glaubt mir es gibt ihn...

Häufig tauchen hoch motivierte OpenGL Anfänger im Forum auf und verkünden stolz, sie würden gerade an einer Engine arbeiten die ''"nur auf Doom 1 Niveau arbeiten soll"''.

Dazu gibt es häufig eine durchaus beachtliche Anzahl von Forenmitgliedern die dann ungefähr folgendes sagen: ''"Fang gar nicht erst damit an. Vergiss es, und komm in einem Jahr noch mal darauf zurück!"'' (Die Forensuche sollte euch einige dieser Threads zeigen)

Sind das böse Pessimisten, die Probleme nutzen um aufzugeben? '''Nein!''' Sie haben zumeist die Erfahrungen gemacht, die Ihr noch machen werdet. Deshalb will ich euch an dieser Stelle einweihen:

1. Je älter der Code ist desto besser wird er.

Leider nein. Code und Wein unterscheiden sich hier leider grundlegend. Viele... die meisten... eigentlich alle von uns bekommen Ausschlag, wenn sie sich ihren Code von vor 1 Jahr angucken. Erst wenn man so schätzungsweise 3 bis 5 Jahre mit OpenGL gearbeitet hat, hat man ein echtes Gefühl für den Code. Am Anfang hat man nämlich, ob man will oder nicht, die Tendenz schon nach den ersten 3 Wochen Programmierarbeit sich den Code so zu zerschießen, dass die weitere Arbeit keinen Spaß mehr macht.

''Ich selbst wollte jetzt ein Projekt weiterbearbeiten, welches ungefähr ein 3/4 Jahr alt ist... Ich hab den Code weggeworfen und das fast fertige Spiel neu angefangen. (Glaubt mir: Aus solchen Fehlern lernt man!)''

2. Große Projekte = Großer Ruhm

Stimmt! ABER Ruhm gibt es in der Szene nur für beendete Projekte. Und dreimal dürft Ihr raten was durch die im Punkt 1 angesprochenen Probleme meist nicht mit euren Projekten passiert...

Wenn Ihr OpenGL nur zur Visualisierung von z. B. wissenschaftlichen Ergebnissen benutzt, ist die Arbeit im Bezug auf OpenGL sehr übersichtlich. Wenn Ihr allerdings Spiele programmieren wollt, werdet Ihr schnell merken, dass Probleme auf euch zukommen werden, die euch beim Projektstart völlig unbekannt waren. Dies ist ein sicheres Zeichen dafür, dass doch noch etwas mehr Erfahrung nötig sein wird.

'''Und woher soll ich bitte Erfahrung nehmen?'''

Darin liegt der Trick:

Alle OpenGLer haben einmal "klein" angefangen. Berühmt-berüchtigt sind die 3DPong-Clone, die zahlreich im Internet anzufinden sind. Auch Tetris-, Memory- oder "Vier Gewinnt"-Clone sind solche stillen Zeugen eines großen Lernvorgangs. Das Besondere an solchen Spielen ist, dass die Spiellogik relativ einfach ist und euch damit nur wenig von der Visualisierung ablenkt.

Ihr denkt jetzt bestimmt "Was kann man denn schon in so nem Clon unterbringen?" '''VERDAMMT VIEL!''' Hier mal ein kleiner Auszug:

*3D-Spieldarstellung
*2D Menüführung ([[glOrtho]])
*[[Blending]]
*[[Textur]]en
*Licht und Materialien (Ihr werdet Augen machen!)
*[[Selektion]] (Hin und wieder zum Haare raufen.)
*Kamerasteuerung /Bewegung durch die Szene (Da gibt es ganze Tutorials dazu)

Als Ansporn solltet Ihr euch am Anfang ein kleines Ziel setzen und sagen "Ich möchte den besten und schönsten XYZ-Clon im ganzen Internet schaffen!". So etwas trifft in der Szene auf wesentlich mehr Anerkennung als wenn mal wieder ein Anfänger etwas von Engine und Doom X faselt.

Wenn Ihr ein oder zwei solcher Projekte abgeschlossen habt, und regelmäßig im Forum bzw. Wiki gelesen habt werdet Ihr schon merken, wenn Euer Traumprojekt endlich in Angriff genommen werden kann. (Ganz vergessen müsst ihr es nämlich doch nicht ;) )

'''Als kurze Zusammenfassung solltet Ihr euch merken:'''

*Ein fertiges Projekt bringt euch Ruhm (Seelenbalsam).
*Ein hübsches, fertiges Projekt bringt euch mehr Ruhm.
*Ein großes, fertiges, hübsches Projekt bringt euch noch mehr Ruhm.

*Ein abgebrochenes oder eingefrorenes Projekt bringt euch Frust.
*Ein großes, abgebrochenes Projekt bringt euch noch mehr Frust, denn der verschwendeten Zeit werdet Ihr nachtrauern.

3.Das es lang dauert ist egal. Ich interessiere mich halt dafür.

Diese Aussage gilt nur dann, wenn Ihr schon über ein Jahr an ein und demselben Projekt gearbeitet habt. Anfänglich ist das kein Problem. Aber wenn man lange an etwas arbeitet und die gemachten Änderungen sind nicht sichtbar (weil sie z. B. den eigentlichen Motor der Anwendung betreffen und nicht die Ausgabe) dann verliert man schon mal die Lust. Folge sind die berüchtigten "Erfolgsmeldungen" wie: "Das Projekt wurde von mir bis auf weiteres aufs Eis gelegt. Ich werde sicherlich später daran weiterarbeiten." In Verbindung mit Punkt 1 und den letzen Satz aus Punkt 2 sollte euch das Endergebnis klar sein.

==Nachwort==

Soviel zur Euphoriebremse. OpenGL ist toll. OpenGL ist die Lösung für Eure Traumanwendung. Aber die wird auch mit OpenGL nicht von heute auf morgen programmiert. Deshalb heißt es Tutorials lesen kleine Testanwendungen schreiben um Effekte zu testen und Projekte bearbeiten. Dann wird es auch etwas mit den Traumprojekten. Zudem kann man anfangs auch versuchen in sehr kleinen Anwendungen einen Effekt auszuprobieren und diesen in Form eines kleinen Beispielprogramms oder eines Tutorials zu veröffenlichen. Somit lernt man nicht nur selbst etwas dazu...

Nach diesen unglaublich Weise klingenden Worten die ich mit einem hoch ernsten Gesicht geschrieben habe, könnt ihr euch jetzt hochmotiviert an die restlichen Tutorials machen.

Bis bald im [http://delphiGL.com/forum Forum]

'''Euer'''

'''Flash (Kevin Fleischer)'''

PS: Feedback wird nicht nur gewünscht, sondern ausdrücklich gefordert. Deshalb: Ab mit deinen Meinungen und Ratschläge ins [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]!

{{TUTORIAL_NAVIGATION|-|[[Tutorial_lektion1]]}}

[[Kategorie:Tutorial|Quickstart]]

Tutorial

2006-08-21T16:13:35Z

Infinite: /* Tutorials */

Auf dieser Seite findet ihr alle Tutorials die DelphiGL.com zu bieten hat. Falls ihr zu einem Thema kein Tutorial findet könnt ihr noch einen Blick auf die [[Techniken und Algorithmen]] werfen. Diese enthalten weitere Artikel zu bestimmten Techniken.

=Hinweise=
Bitte tragt selbst '''keine''' eigenen Tutorials ohne Absprache mit [[Benutzer:Flash (Kevin Fleischer)|Flash]] bzw. [[Benutzer:Phobeus|Phobeus]] hier ein. Tutorials werden prinzipiell vom DGL-Team gegengelesen, ''bevor'' sie veröffentlicht werden.

Wer mit dem Gedanken spielt, ein Tutorial für DGL zu schreiben, sollte sich bereits bei der Themenwahl mit dem DGL-Team absprechen. DGL ist sehr an neuen Tutorials interessiert. Nur sollte man beachten, dass nichts doppelt geschrieben wird, bzw. dass nicht 2 Mann zur selben Zeit das selbe Thema beackern.

==Hinweis für alle Programmieranfänger==
Falls ihr OpenGL nutzen wollt aber noch keinerlei Programmiererfahrung habt, so solltet ihr zuerst eine Programmiersprache lernen.

DGL kann folgende Tutorials empfehlen:

{|{{Prettytable_B1}} width="100%"
!Link
!Sprache
!Beschreibung
|-
|[http://dsdt.info/tutorials/ Delphitutorials bei DSDT.info]
|{{Deutsch}}
|'''D'''elphi '''S'''ource der '''D'''elphi '''T'''reff entstand durch den Zusammenschluss von Delphi-Source und dem Delphi-Treff. Diese Community verfügt über eine ausgezeichnete Sammlung von Tutorials zum Thema "Delphiprogrammierung". Es werden nicht nur die Grundlagen erklärt sondern nahezu alle Bereiche der Programmierung mit Delphi. Außerdem verfügt diese Community über ein Forum welches mit seiner ''Bastelecke'' auch für Anfänger geeignet ist.
|-
|}

=Tutorials=
{{Hinweis|Alle Tutorials sind der [[:Kategorie:Tutorial]] zugeordnet.}}

<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Schwierigkeitsgrad
!Bedeutung
|-
|{{Level_1}}
|Jeder Schritt wird ausführlich erklärt. Absolut Einsteigertauglich.
|-
|{{Level_2}}
|Verständnis der Grundprinzipien wird vorraus gesetzt. Die Materie bleibt aber einfach.
|-
|{{Level_3}}
|Ihr wisst um was es geht. Es wird erwartet, dass ihr selbst das Thema weiterdenkt.
|-
|{{Level_4}}
|Das Tutorial bietet euch einen Einstieg. Es wird erwartet, dass ihr euch selbst noch eingehender mit den beschriebenen Techniken befasst. Für Fragen steht unser Forum zur Verfügung.
|-
|{{Level_5}}
|Um das Tutorial zu verstehen werden Kenntnisse auf dem entsprechenden Gebiet vorrausgesetzt, welche über Grundwissen hinausgehen. Es wird erwartet, dass ihr euch eingehender mit dem Thema auseinandersetzt und auch andere Quellen lest/gelesen habt. Für Fragen steht unser Forum zur Verfügung.
|}
</div>

== Einsteiger-Tutorials ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
{{Hinweis|Die Einsteiger-Tutorials wurden auf SDL umgestellt. Dadurch wurde das Laden von Texturen erleichtert, vor allem aber ermöglicht SDL plattformunabhängig zu programmieren. Ihr benötigt deshalb die ''SDL.pas''. Diese Datei und alle anderen benötigten Dateien findet ihr im '''[[DGLSDK]]'''}}
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial quickstart|Tutorial Quickstart]]
{{Level_1}}
|[[Bild:Tutorial_Lektion1.gif|right]] "Quickstart: OpenGL & Delphi" 
Für alle, die einen schnellen Einstieg in die OpenGL Programmierung mit Delphi suchen, hat Flash hier einen Einstieg geschaffen. Neben dem erstellen eines eigenen OpenGL-Templates hat er für alle, die Großes mit OpenGL vorhaben, am Ende noch einige Hinweise bereitgestellt.

''Es wird empfohlen dieses Tutorial als erstes zu lesen da hier eine erste Codebasis geschaffen wird. Die Hintergründe werden dann ausführlich in den Lektionen behandelt.''
|-
![[Tutorial lektion1|Tutorial Lektion 1]]
{{Level_1}}
|[[Bild:Tutorial_Lektion1.gif|right]] "Nicht zu weit aus dem Fenster lehnen" 
Dieses Tutorial von Magellan ist für alle Neueinsteiger gedacht. Hier werden Grundlagen von "Was ist OpenGL" bis zu "Wie initialisiere ich OpenGL?" besprochen.
|-
![[Tutorial lektion2|Tutorial Lektion 2]]
{{Level_1}}
|[[Bild:Tutorial_Lektion2.jpg|right]] "Entdeckung einer neuen Welt" 
Unter dieser Überschrift empängt euch Phobeus zu eurem ersten OpenGL Tutorial welches sich mit der Anwendung der OpenGL-API befasst.
|-
![[Tutorial lektion3|Tutorial Lektion 3]]
{{Level_1}}
|[[Bild:Tutorial_Lektion3.gif|right]] "Eine Welt des Grauens?" 
Hinter diesem Titel verbirgt sich ein Einsteigertutorial zum Thema Matrizen in OpenGL. Wiederum führt euch Phobeus durch den Stoff.
|-
![[Tutorial lektion4|Tutorial Lektion 4]]
{{Level_2}}
|[[Bild:Tutorial_Lektion4.png|right]] "Texturen, Tapeten und Ihre Tücken" 
Wie bekomme ich ein Bild auf meine Primitiven? Wer sich diese Frage bei den vorigen Tutorials gestellt hat, der bekommt hier nun von Phobeus die Antworten.
|-
![[Tutorial lektion5|Tutorial Lektion 5]]
{{Level_2}}
|[[Bild:Tutorial_Lektion5.jpg|right]] "Artenvielfalten und Ihre Folgen" 
In diesem Tutorial geht Phobeus auf weitere Zeichentechniken und Methoden zur Verbesserung der Performance unter OpenGL ein.
|-
![[Tutorial lektion7|Tutorial Lektion 7]]
{{Level_2}}
|[[Bild:Tutorial_Lektion7.png|right]] "Verblendet!" 
Wenn man halbdurchsichtige Fensterscheiben, Lightmaps oder etwas ähnliches in sein Projekt einbauen will, dann kommt man um Blending nicht herum. Wie man das ganze Nutzen kann ist in diesem Tutorial von Phobeus erklärt.
|-
![[Tutorial lektion8|Tutorial Lektion 8]]
{{Level_2}}
|[[Bild:Tutorial_Lektion8.gif|right]] "Das Wesen von hell und dunkel - Licht" 
Ohne Beleuchtung sieht selbst jede 3D-Umgebung platt aus. In diesem Tutorial wird primär der richtige Gebrauch des OpenGL-Lichtes beschrieben. Darüberhinaus wird noch die Berechnung von Normalen erklärt.
|-
![[Tutorial 2D]]
{{Level_2}}
|[[Bild:Tutorial_2D.jpg|right]] "2D mit OpenGL" 
OpenGL ist zwar primär eine 3D-API, eignet sich aber, nicht zuletzt dank seiner leistungsstarken Hardwarebeschleunigung und der damit verbundenen Features, auch sehr gut für reine 2D-Anwendungen. Dieses Tutorial von Sascha Willems geht sehr ausführlich auf die Nutzung von OpenGL für 2D-Anwendungen ein.
|-
![[Tutorial Matrix2]]
{{Level_1}}
|[[Bild:Tutorial_Matrix2.png|right]] "Matrix2 - Matrizen und Matrixmanipulationen" 
Das Thema Matrizen stellt OpenGL-Einsteiger regelmäßig vor "unlösbare" Aufgaben: 
''Wieso dreht sich der Würfel so komisch, und nicht um sich selbst?'' 
''Wieso verschiebt OpenGL die Kugel denn dahin, und nicht dorthin?'' 
Dieses Tutorial von Flash befasst sich mit den 3 Matrixtypen, die es in OpenGL gibt und erklärt was die Befehle '''glScale, glRotate und glTranslate''' wirklich machen.
|-
![[Tutorial SDL Einstieg]]
{{Level_2}}
|[[Bild:Tutorial_Lektion1.gif|right]] "SDL-Einsteiger-Tutorial" 
Crossplattform-Programmierung ist das Zauberwort, welches in den letzten Jahren - dank verstärkter Präsenz von Linux - immer wieder in den Programmierforen des Internets auftaucht. Für Grafikprogrammier ist [[SDL]] hier das Mittel der Wahl. Bekannte Titel wie "Quake III" und "Civilisation - Call to Power" bauen bereits auf diese Bibiothek für ihre Linux-Ports. Phobeus zeigt euch in diesem ersten SDL-Tutorial was SDL ist und wie man es benutzt.
|-
|}
</div>

== Grundlagen-Tutorials ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Abseits eckiger Welten]]
{{Level_2}}
|[[Bild:Tutorial_Abseits_eckiger_Welten.gif|right]] "Abseits eckiger Welten" 
3D-Welten bestehen seit eh und je aus Dreiecken, was sie oft recht eckig erscheinen lässt. In diesem Tutorial lernt ihr allerdings wie man mit Hilfe von Evaluatoren in OpenGL auch Rundungen erzeugen kann.
|-
![[Tutorial Renderpass]]
{{Level_1}}
|[[Bild:Tutorial_Renderpass.jpg|right]] "Renderpass - Die Welt daneben" 
OpenGL bietet nicht nur die Möglichkeit seine Szene direkt auf den Bildschirm zu rendern, sondern auch diese in eine Textur zu rendern um diese dann auf ein Objekt zu kleben. Dadurch ergeben sich diverse neue Möglichkeiten, wie z.B. Spiegel, Portale oder nachträgliche Manipulation der Textur. Wie ihr eure Szene in eine Textur bekommt, erfahrt ihr hier.
|-
![[Tutorial Selection]]
{{Level_2}}
|[[Bild:Tutorial_Selection.gif|right]] "Objectselektion A" 
Die Selektion von Objekten braucht man spätestens dann, wenn man ein komfortable Interaktion mit der Spielwelt erstellen will. Mit diesem Tutorial von DCW_MrT ist die Thematik kein Problem mehr.
|-
! [[Tutorial Objektselektion]]
{{Level_2}}
| [[Bild:Tutorial_Selection_tut03.jpg|right]] "Objektselektion B" 
Wie simpel der Objektselektionsmodus von OpenGL zu benutzen ist, wird in diesem Tutorial von Sascha Willems vermittelt. Dazu gibt es den Source-Code und eine fertig kompilierte Anwendung.
|-
![[Tutorial TexFilter]]
{{Level_1}}
|[[Bild:Tutorial_TexFilter.jpg|right]] "Texturfilterung - Texturen-Feintuning" 
Texturen sind seit langem ein wichtiger Bestandteil im Bereich der Echtzeitgrafik. OpenGL bietet auf diesem Gebiet auch diverse Möglichkeiten Texturen auch filtern zu lassen. Welche das sind und wie sie sich auswirken, könnt ihr in diesem Tutorial von Delphic nachlesen.
|-
![[Tutorial Kamera1]]
{{Level_2}}
|[[Bild:Tutorial_Kamera1.gif|right]] "Dreht sich das Universum um uns? und andere philosophische Fragen" 
In diesem Tutorial von Delphic geht es um die Kamera. Wie eine Kameraklasse gebaut sein könnte und was sie macht wird hier erklärt.
|-
|}
</div>

== Effekte ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Nebel]]
{{Level_2}}
|[[Bild:Tutorial_Nebel.jpg|right]] "DGL Fogging Tutorial". 
Erstaunlich einfach lässt sich mit OpenGL Nebel darstellen. Wie einfach, zeigt euch Lithander in diesem Tutorial.
|-
![[Tutorial Partikel1]]
{{Level_2}}
|[[Bild:Tutorial_Partikel1.gif|right]] "Partikel-Tutorial I". 
Eine Partikel-Engine sollte in (fast) jeder Engine enthalten sein. Anhand dieses Tutorials von Lithander könnt ihr den Grundstein dazu legen.
|-
![[Tutorial BumpMap]]
{{Level_3}}
|[[Bild:Tutorial_BumpMap.png|right]] "Bumpmapping - Plastisches 2D". 
Bumpmapping ist eine immer stärker genutzte Technik, um polygonarme Oberflächen ohne Tesselation mit vorgegaukelten Details - abhängig vom Lichteinfall - zu versehen. In diesem Tutorial zeigt euch HomerS, wie man Bumpmapping über die NVIDIA-spezifischen Combiner realisiert.
|-
![[Tutorial Bumpmaps mit Blender]]
{{Level_1}}
|[[Bild:Tutorial_BumbBlend_Preview.png|right]]
Mit dem kostenlosen 3D-Program Blender können einfache Bumpmaps erstellt werden. Wie das geht, erfahrt ihr in diesem Tutorial von Flo.

{{Hinweis|Das Programm "Blender" bekommt ihr kostenlos auf [http://blender3d.org blender3d.org]}}

|-
![[Tutorial MultiTexturing]]
{{Level_2}}
|[[Bild:Multitex05.jpg|right]] "Multitexturing". 
Wie man mehrere Texturen auf ein Polygon bringen kann, erklärt auch Sascha Willems in diesem Tutorial zum Thema Multitexturing. Multitexturing ist seit OpenGL1.3 Teil des GL-Kerns und kann für z.B. für Lightmapping bzw. Detailmapping verwendet werden.
|-
![[Tutorial StencilSpiegel]]
{{Level_3}}
|[[Bild:Tutorial_StencilSpiegel.jpg|right]] "Spiegelungen mit dem Stencil-Buffer". 
Eine Echtzeit-Spiegelung ist einer der schönsten Effekte einer 3D-Welt und trägt viel zum Realismus bei. Eine Möglichkeit Spiegelungen über den Stencilpuffer zu realisieren, wird in diesem Tutorial von Sascha Willems erklärt.
|-
![[Tutorial StereoSehen]]
{{Level_3}}
|[[Bild:Tutorial_StereoSehen.gif|right]]Auch wenn moderne Grafikkarten durch eine immer besser werdende Darstellung dem Benutzer versuchen das Betreten einer virtuellen 3D-Welt vorzugaukeln, so schafft es doch auch das beste Doom3-Monster nur bis zur Glasröhre zu erschrecken, rutscht dann aber quietschend davon ab. Was also tun, wenn man einen Schritt weiter gehen und dem Anwender wirkliches 3D bieten möchte? Wer eine 3D-Brille hat, wird mit diesem Tutorial von Nico Mechaelis eine Möglichkeit finden, die dritte Dimension am Computer zur erschließen.
|-
![[Tutorial Alphamasking]]
{{Level_2}}
|[[Bild:Tutorial_Alphamasking_tut04.jpg|right]]In diesem kleinen aber feinen Tutorial erklärt Sascha Willems, wie man Alphamasking dazu verwenden kann, eine Szene optisch aufzuwerten und gleichzeitig Performance zu sparen.
|}
</div>

==Extensions==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Cubemap]]
{{Level_3}}
|[[Bild:Tutorial_Cubemap_mini.jpg|right]] "GL_ARB_Texture_Cubemap". 
In diesem Tutorial erklärt Sascha Willems die Grundfunktionen der '''GL_ARB_Texture_Cubemap'''-Extension und zeigt auch weiterführende Techniken auf.
|-
![[Tutorial Vertexbufferobject]]
{{Level_3}}
|[[Bild:Tutorial Vertexbufferobject preview.jpg|right]] "GL_ARB_Vertex_Buffer_Object". 
Wie man mit dieser Extension Vertexdaten schnell im Grafikkarten- und Hauptspeicher ablegt und darauf zugreift, erklärt Sascha Willems in diesem Tutorial.
|-
![[Tutorial Vertexprogramme]]
{{Level_3}}
|[[Bild:Tutorial_VP_preview.jpg|right]] "GL_ARB_Vertex_Program". 
In diesem umfangreichen Tutorial werden alle wichtigen Bereiche der Programmierung mit der GL_ARB_Vertex_Program-Extension abgedeckt. Man kann es als umfassende deutsche Referenz zu diesem Thema sehen, da auch alle wichtigen Funktionen aufgelistet werden und es auch sonst an nichts fehlt.
|-
![[Tutorial NVOcclusionQuery]]
{{Level_3}}
|[[Bild:Tutorial_NVO_preview.jpg|right]] "NV_Occlusion_Query". 
Lard Middendorf geht in diesem Tutorial auf die Verwendung der NV_Occlusion_Query-Extension ein.
|-
![[Tutorial Pixelbuffer]]
{{Level_3}}
|[[Bild:Tutorial_Pixelbuffer_preview.jpg|right]] "WGL_ARB_Pixel_Buffer". 
Sascha Willems erklärt hier leicht verständlich den Umgang mit der Pixelbuffer-Extension. Als Additum wird auch noch auf die Nutzung dieser Extension für Shadowmapping eingegangen.
|}

== Shader ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial glsl|Tutorial glSlang]]
{{Level_4}}
|[[Bild:Tutorial_glsl1.png|right]] "Einführung in GLSL". 
Nach langem Ringen und Handeln hat es das ARB letztendlich doch geschafft, eine einheitliche Shaderhochsprache für OpenGL zu veröffentlichen, nämlich ''glSlang''. Mit glSlang können nun auch unter OpenGL Vertex- und Fragment-Shader in einer lesbaren, C-ähnlichen Hochsprache geschrieben werden, was deren Entwicklung stark vereinfacht. Diese Einführung von Sascha Willems ist weniger ein Tutorial, als ein kompletter Überblick über glSlang. Hier erfährt der Leser nicht nur etwas über die Benutzung von Shadern im Programm, sondern auch alles über die Sprachelemente, inklusive diverser Beispiele.
|-
![[Tutorial glsl2|Tutorial glSlang 2]]
{{Level_4}}
|[[Bild:Tutorial_na.jpg|right]] "GLSL-Ergänzungen und Beispiele". 
Dieses Tutorial von La_Boda ist eine direkte Fortsetzung des GLSL-Tutorials. Es behandelt verstärkt die Praxis und liefert anhand von einigen Beispielen eine bessere Sicht auf die bereits gelernte Theorie.
|-
|}

== KI ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial pathfinding|Tutorial Pathfinding]]
{{Level_2}}
|[[Bild:Tutorial_pathfinding.png|right]] "Pathfinding 1". 
In diesem Tutorial zeigt euch Flo wie man recht simpel eine Wegfindungsroutine implementiert. Besonders wenn man sowas ohne großen Lernaufwand in sein Spiel einbinden möchte, sollte man einen Blick riskieren.
|-
![[Tutorial pathfinding2|Tutorial Pathfinding 2]]
{{Level_3}}
|[[Bild:Tutorial_pathfinding2.png|right]] "Pathfinding 2". 
Gerade bei aktuelleren Programmen reicht es meist nicht aus, wenn man seine Einheiten nur in 8 Himmelsrichtungen bewegen kann. Frase stellt in diesem Tutorial vor, wie man eine Wegfindungsroutine implementieren kann, wie diese in einem heutigen RTS vorkommen kann.
|-
|}

== Terrain und Landschaften ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Terrain1]]
{{Level_4}}
|[[Bild:Tutorial_Terrain1.gif|right]] "Aussenlandschaften mit System - Heightmaps". 
Anhand der Graustufenwerte einer Bitmap-Datei kann man relativ einfach eine imposante Landschaft erstellen. Wie das ganze funktioniert erklärt euch Nico Michaelis in diesem Tutorial. Außerdem wird noch die Implementation von Skyboxen erklärt.
|-
![[Tutorial Terrain2|Tutorial Terrain 2]]
{{Level_4}}
|[[Bild:Tutorial_Terrain2.gif|right]] "Heightmap-Texturen". 
Da das Terrain aus dem vorigen Tutorial noch recht eintönig grau aussieht und das natürlich geändert werden soll, erklärt euch Nico, wie man schmucke Schatten und Texturen für die Heightmap generieren kann.
|-
![[Tutorial Terrain3|Tutorial Terrain 3]]
{{Level_5}}
|[[Bild:Tutorial_Terrain3.gif|right]] "Terrain im Detail". 
Da größere Landschaften aufgrund der hohen Polygonanzahl sehr aufwändig zu rendern sind erklärt euch Nico hier, wie man entfernte Dreiecke "zusammenlegen" kann, um Rechenleistung zu sparen.
|-
![[Tutorial Skyboxen]]
{{Level_2}}
|[[Bild:Tutorial_Skybox_Vorschau.jpg|right]] "Skyboxen". 
In diesem Tutorial erklärt Sascha Willems kurz und bündig den Umgang mit Skyboxen, mit denen man Landschaften schnell sehr stark optisch aufwerten kann. Es wird sowohl auf die Erstellung der Skybox-Texturen mit dem Programm Terragen als auch die Implementation der Skybox in OpenGL eingegangen.
|-
|}

== Spieletutorials und Softwareentwicklung==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Bomberman1|Tutorial Bomberman 1]]
{{Level_3}}
|[[Bild:Tutorial_Bomberman1.jpg|right]] "Bomberman1 - Codebasis und Editor". 
Im ersten Teil dieser kleinen Tutorialserie zum Thema Spieleprogrammierung kümmern wir uns neben der Erstellung unseres Basiscodes auch um einen fertigen Editor. Nach der Durcharbeitung dieses Tutorials von Sascha Willems sollte der Leser alle Grundprinzipien zur Programmierung eines Spiels verstanden haben.
|-
![[Tutorial Bomberman2|Tutorial Bomberman 2]]
{{Level_3}}
|[[Bild:Tutorial_Bomberman2.jpg|right]] "Bomberman2 - Der 3D-Bombermanklon (Grundversion)". 
Im zweiten Teil gehts ans Eingemachte, nämlich einen fertigen Bombermanklon. In Sascha Willems Tutorial werdet ihr zusätzlich zu den bereits erworbenen Prinzipien diverse Techniken die in so ziemlich jedem Spiel Verwendung finden erlernen.
|-
![[Tutorial Softwareentwicklung1|Tutorial Softwareentwicklung 1]]
{{Level_3}}
|[[Bild:Tutorial_SWE1.jpg|right]] "Softwareentwicklung1 - Objektorientierte Softwareentwicklung mit UML". 
Im ersten Teil dieser Tutorialserie zum Thema Softwareentwicklung erklärt euch Flash, wie man an ein Projekt herangeht und herausfindet was eigentlich zu tun ist. Es geht dabei um Analyse der Anforderungen und die Modellierung sogenannter Use Cases. Die hier vorgestellten Arbeiten sind Grundlage um später Klassen zu finden auf denen dann der Code aufgebaut wird.
|-
![[Tutorial Softwareentwicklung2|Tutorial Softwareentwicklung 2]]
{{Level_3}}
|[[Bild:Tutorial_SWE2.jpg|right]] "Softwareentwicklung2 - Objektorientierte Softwareentwicklung mit UML". 
Im zweiten und umfangreichsten Teil der Serie steht das Thema "Klassen" im Zentrum. Flash erklärt euch wie man aus den Use Cases Klassen ableitet und welche unterschiedlichen Einsatzgebiete Klassen innerhalbd er Software haben können.
|-
|}

== Mathematisches ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Lineare Algebra]]
{{Level_2}}
|[[Bild:Tutorial_lineare_Algebra_Preview.jpg|right]] "Vektorrechnung". 
In vielen Tutorials tauchen eine Menge Begriffe aus der linearen Algebra und analytischen Geometrie auf. Wer bei Begriffen wie Vektoren, Skalar-Produkt, Vektorkreuzprodukt, etc. ein wenig Auffrischung und Implementationshinweise braucht, ist mit diesem Tutorial von EternalLearner an der richtigen Stelle.
|-
![[Tutorial Nachsitzen]]{{Level_1}}
|[[Bild:Tutorial_Nachsitzen_preview.png|right]] "3d-Mathematik". 
Wer die mathematischen Grundlagen wie Sinus, Cosinus und Matrizen aus der Schule schon wieder vergessen oder noch vor sich liegen hat, der kann mit Hilfe dieses Tutorials von Nico Michaelis dieses Wissen erlernen bzw. auffrischen.
|-
![[Tutorial Objekt gedreht und dennoch nach vorne bewegt]]
{{Level_2}}
|[[Bild:Tutorial_Objekt_gedreht_und_dennoch_nach_vorne_bewegt_preview.gif|right]] "Objekt gedreht und dennoch nach vorne bewegt". 
SchodMC erklärt in diesem Tutorial wie man ein Objekt drehen und dabei trotzdem vorwärts bewegen kann. Quer fahrende Autos sind zwar praktisch zum Einparken Aber doch eher selten ;-)
|-
![[Tutorial Objekt immer um eigene Achse drehen]]
{{Level_2}}
|[[Bild:Tutorial_Objekt_immer_um_die_eigene_Achse_drehen_preview.gif|right]] "Objekt immer um eigene Achse drehen". 
Wenn ihr euer Objekt nun noch um die eigene Achse drehen wollt, seid ihr mit diesem Tutorial von SchodMC an der richtigen Adresse
|-
|}

== Grafik und Modellierung ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Modellierung eines Low-Poly Menschen Teil 1]]
{{Level_4}}
|[[Bild:Tutorial_Low-Poly-Mensch1_preview.jpg|right]] "Modellierung eines Low-Poly-Menschen". 
Die Modellierung von organischen "Objekten" gehört mit zu den kompliziertesten Aufgaben, die es beim Modelling gibt. Wie man einen Menschen mit aus möglichst wenigen Polygonen mit dem Programm 3D Studio Max erstellen kann wird in diesem Tutorial von Sascha Willems erklärt.
|-
![[Tutorial Modellierung eines Low-Poly Menschen Teil 2]]
{{Level_4}}
|[[Bild:Tutorial_Low-Poly-Mensch2_preview.jpg|right]] "Kleider machen Leute (UVW-Mapping)". 
Nun spendiert Sascha Willems seinem Menschen aus dem 1. Tutorial eine schmucke Uniform, so dass er sich endlich in der Öffentlichkeit blicken lassen kann.
|-
|}

== Skripte ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Scripting mit JvInterpreterProgram]]
{{Level_2}}
|[[Bild:Tutorial_JvInterpreter_preview.png|right]] "Skripting mithilfe der Jedi-Code-Library". 
SchodMC erklärt hier wie man mit relativ wenig Aufwand Skripte in eigene Programme integrieren kann.
|-
![[Tutorial Scriptsprachen Teil 1]]
{{Level_5}}
|[[Bild:Tutorial_Skriptsprachen1_preview.gif|right]] "Scriptsprachen Teil 1 - Einführung". 
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Nico Michaelis genau das richtige.

Der erste Teil widmet sich der Lexikalischen Analyse und dem Parsen des Quellcodes
|-
![[Tutorial Scriptsprachen Teil 2]]
{{Level_5}}
|[[Bild:Tutorial_Skriptsprachen2_preview.gif|right]] "Scriptsprachen Teil 2 - Virtuelle Computer und Code Erzeugung". 
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Nico Michaelis genau das richtige.

Der zweite Teil beschreibt den Bau einer VM und der Codeerzeugung
|-
|}

== Delphi allgemein ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial Debugging]]
{{Level_2}}
| [[Bild:Tutorial Debugging.gif|right]] "Debugger benutzen und andere praktische Tipps" 
In diesem Tutorial werdet von Nico mit der Nutzung des Delphi-Debuggers eingeführt. Auch werden Wege zur Vermeidung von Fehlern aufgezeigt. Genauso findet Ihr aber auch in diesem Tutorial Hinweise, zu häufig begangenen Fehlern und deren Ursachen.
|-
! [[Tutorial Komponentenentwicklung]]
{{Level_2}}
| [[Bild:Tutorial Komponentenentwicklung.png|right]] "Komponentenentwicklung" 
In diesem Tutorial werdet ihr ein wenig tiefer in die Entwicklung von Komponenten unter Delphi eingeführt. Es wird Grundwissen auf diesem Gebiet vorausgesetzt.
|-
![[Tutorial Multithreading]]
{{Level_3}}
|[[Bild:Tutorial_Multithreading.gif|right]] "Das Prinzip der Dualität". 
Threads sind ein erweitertes Prinzip des bekannten Multitasking und werden innerhalb eines Programmes oft dazu genutzt, verschiedene Aufträge gleichzeitig abzuarbeiten. LossyEx erklärt euch hier deren Nutzung.
|-
! [[Tutorial Software-Synthesizer]]
{{Level_4}}
| [[Bild:Noexist.jpg|right]] "Software-Synthesizer" 
Computerspiele bestehen nicht nur aus Grafik. Dieses Tutorial widmet sich einem ganz anderen Bereich der Spieleprogrammierung: Der Erzeugung von synthetischen Sounds und Musik.
|}

== Rendertechniken ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial Octree]]
{{Level_1}}
| [[Bild:Tutorial Octree preview.jpg|right]] "Octrees" 
Octrees sind eine einfach zu implementierende, aber sehr effiziente Möglichkeit um besonders Outdoor-Szenen abhängig vom Betrachterblickfeld stark zu beschleunigen. In diesem Tutorial zeigt Shadow euch eine komplette Implementation eines Octrees inklusive ausgiebigem Quellcode.
|-
! [[Tutorial Frustum Culling]]
{{Level_1}}
| [[Bild:Tutorial Frustum Culling.jpg|right]] "Frustum Culling" 
Frustum Culling ist eine einfache Möglichkeit die Rendergeschwindigkeit zu erhöhen, da man damit schon vor dem Senden der Daten an die Grafikkarten feststellen kann, welche Objekte sich im Blickfeld des Spielers befinden und welche nicht.
|}

== Sonstiges ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial GLScene]]
{{Level_1}}
| [[Bild:Tutorial GLScene preview.jpg|right]] "Einführung in GLScene" 
GLScene ist eine zu erstaunlicher Größe angewachsene Komponentensammlung, die quasi einen OpenGL-Wrapper darstellt und euch dank Delphis VCL dadurch recht einfach OpenGL-Programme erstellen lässt. LaBoda gibt euch zu dieser Komponentensammlung in diesem Tutorial deshalb eine kleine Einführung.
|}

Tutorial

2006-08-19T12:14:15Z

Infinite: /* Hinweise */

Auf dieser Seite findet ihr alle Tutorials die DelphiGL.com zu bieten hat. Falls ihr zu einem Thema kein Tutorial findet könnt ihr noch einen Blick auf die [[Techniken und Algorithmen]] werfen. Diese enthalten weitere Artikel zu bestimmten Techniken.

=Hinweise=
Bitte tragt selbst '''keine''' eigenen Tutorials ohne Absprache mit [[Benutzer:Flash (Kevin Fleischer)|Flash]] bzw. [[Benutzer:Phobeus|Phobeus]] hier ein. Tutorials werden prinzipiell vom DGL-Team gegengelesen, ''bevor'' sie veröffentlicht werden.

Wer mit dem Gedanken spielt, ein Tutorial für DGL zu schreiben, sollte sich bereits bei der Themenwahl mit dem DGL-Team absprechen. DGL ist sehr an neuen Tutorials interessiert. Nur sollte man beachten, dass nichts doppelt geschrieben wird, bzw. dass nicht 2 Mann zur selben Zeit das selbe Thema beackern.

==Hinweis für alle Programmieranfänger==
Falls ihr OpenGL nutzen wollt aber noch keinerlei Programmiererfahrung habt, so solltet ihr zuerst eine Programmiersprache lernen.

DGL kann folgende Tutorials empfehlen:

{|{{Prettytable_B1}} width="100%"
!Link
!Sprache
!Beschreibung
|-
|[http://dsdt.info/tutorials/ Delphitutorials bei DSDT.info]
|{{Deutsch}}
|'''D'''elphi '''S'''ource der '''D'''elphi '''T'''reff entstand durch den Zusammenschluss von Delphi-Source und dem Delphi-Treff. Diese Community verfügt über eine ausgezeichnete Sammlung von Tutorials zum Thema "Delphiprogrammierung". Es werden nicht nur die Grundlagen erklärt sondern nahezu alle Bereiche der Programmierung mit Delphi. Außerdem verfügt diese Community über ein Forum welches mit seiner ''Bastelecke'' auch für Anfänger geeignet ist.
|-
|}

=Tutorials=
{{Hinweis|Alle Tutorials sind der [[:Kategorie:Tutorial]] zugeordnet.}}

<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Schwierigkeitsgrad
!Bedeutung
|-
|{{Level_1}}
|Jeder Schritt wird ausführlich erklärt. Absolut Einsteigertauglich.
|-
|{{Level_2}}
|Verständnis der Grundprinzipien wird vorraus gesetzt. Die Materie bleibt aber einfach.
|-
|{{Level_3}}
|Ihr wisst um was es geht. Es wird erwartet, dass ihr selbst das Thema weiterdenkt.
|-
|{{Level_4}}
|Das Tutorial bietet euch einen Einstieg. Es wird erwartet, dass ihr euch selbst noch eingehender mit den beschriebenen Techniken befasst. Für Fragen steht unser Forum zur Verfügung.
|-
|{{Level_5}}
|Um das Tutorial zu verstehen werden Kenntnisse auf dem entsprechenden Gebiet vorrausgesetzt, welche über Grundwissen hinausgehen. Es wird erwartet, dass ihr euch eingehender mit dem Thema auseinandersetzt und auch andere Quellen leßt/gelesen habt. Für Fragen steht unser Forum zur Verfügung.
|}
</div>

== Einsteiger-Tutorials ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
{{Hinweis|Die Einsteiger-Tutorials wurden auf SDL umgestellt. Dadurch wurde das Laden von Texturen erleichtert, vor allem aber ermöglicht SDL plattformunabhängig zu programmieren. Ihr benötigt deshalb die ''SDL.pas''. Diese Datei und alle anderen benötigten Dateien findet ihr im '''[[DGLSDK]]'''}}
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial quickstart|Tutorial Quickstart]]
{{Level_1}}
|[[Bild:Tutorial_Lektion1.gif|right]] "Quickstart: OpenGL & Delphi" 
Für alle, die einen schnellen Einstieg in die OpenGL Programmierung mit Delphi suchen, hat Flash hier einen Einstieg geschaffen. Neben dem erstellen eines eigenen OpenGL-Templates hat er für alle, die Großes mit OpenGL vorhaben, am Ende noch einige Hinweise bereitgestellt.

''Es wird empfohlen dieses Tutorial als erstes zu lesen da hier eine erste Codebasis geschaffen wird. Die Hintergründe werden dann ausführlich in den Lektionen behandelt.''
|-
![[Tutorial lektion1|Tutorial Lektion 1]]
{{Level_1}}
|[[Bild:Tutorial_Lektion1.gif|right]] "Nicht zu weit aus dem Fenster lehnen" 
Dieses Tutorial von Magellan ist für alle Neueinsteiger gedacht. Hier werden Grundlagen von "Was ist OpenGL" bis zu "Wie initialisiere ich OpenGL?" besprochen.
|-
![[Tutorial lektion2|Tutorial Lektion 2]]
{{Level_1}}
|[[Bild:Tutorial_Lektion2.jpg|right]] "Entdeckung einer neuen Welt" 
Unter dieser Überschrift empängt euch Phobeus zu eurem ersten OpenGL Tutorial welches sich mit der Anwendung der OpenGL-API befasst.
|-
![[Tutorial lektion3|Tutorial Lektion 3]]
{{Level_1}}
|[[Bild:Tutorial_Lektion3.gif|right]] "Eine Welt des Grauens?" 
Hinter diesem Titel verbirgt sich ein Einsteigertutorial zum Thema Matrizen in OpenGL. Wiederum führt euch Phobeus durch den Stoff.
|-
![[Tutorial lektion4|Tutorial Lektion 4]]
{{Level_2}}
|[[Bild:Tutorial_Lektion4.png|right]] "Texturen, Tapeten und Ihre Tücken" 
Wie bekomme ich ein Bild auf meine Primitiven? Wer sich diese Frage bei den vorigen Tutorials gestellt hat, der bekommt hier nun von Phobeus die Antworten.
|-
![[Tutorial lektion5|Tutorial Lektion 5]]
{{Level_2}}
|[[Bild:Tutorial_Lektion5.jpg|right]] "Artenvielfalten und Ihre Folgen" 
In diesem Tutorial geht Phobeus auf weitere Zeichentechniken und Methoden zur Verbesserung der Performance unter OpenGL ein.
|-
![[Tutorial lektion7|Tutorial Lektion 7]]
{{Level_2}}
|[[Bild:Tutorial_Lektion7.png|right]] "Verblendet!" 
Wenn man halbdurchsichtige Fensterscheiben, Lightmaps oder etwas ähnliches in sein Projekt einbauen will, dann kommt man um Blending nicht herum. Wie man das ganze Nutzen kann ist in diesem Tutorial von Phobeus erklärt.
|-
![[Tutorial lektion8|Tutorial Lektion 8]]
{{Level_2}}
|[[Bild:Tutorial_Lektion8.gif|right]] "Das Wesen von hell und dunkel - Licht" 
Ohne Beleuchtung sieht selbst jede 3D-Umgebung platt aus. In diesem Tutorial wird primär der richtige Gebrauch des OpenGL-Lichtes beschrieben. Darüberhinaus wird noch die Berechnung von Normalen erklärt.
|-
![[Tutorial 2D]]
{{Level_2}}
|[[Bild:Tutorial_2D.jpg|right]] "2D mit OpenGL" 
OpenGL ist zwar primär eine 3D-API, eignet sich aber, nicht zuletzt dank seiner leistungsstarken Hardwarebeschleunigung und der damit verbundenen Features, auch sehr gut für reine 2D-Anwendungen. Dieses Tutorial von Sascha Willems geht sehr ausführlich auf die Nutzung von OpenGL für 2D-Anwendungen ein.
|-
![[Tutorial Matrix2]]
{{Level_1}}
|[[Bild:Tutorial_Matrix2.png|right]] "Matrix2 - Matrizen und Matrixmanipulationen" 
Das Thema Matrizen stellt OpenGL-Einsteiger regelmäßig vor "unlösbare" Aufgaben: 
''Wieso dreht sich der Würfel so komisch, und nicht um sich selbst?'' 
''Wieso verschiebt OpenGL die Kugel denn dahin, und nicht dorthin?'' 
Dieses Tutorial von Flash befasst sich mit den 3 Matrixtypen, die es in OpenGL gibt und erklärt was die Befehle '''glScale, glRotate und glTranslate''' wirklich machen.
|-
![[Tutorial SDL Einstieg]]
{{Level_2}}
|[[Bild:Tutorial_Lektion1.gif|right]] "SDL-Einsteiger-Tutorial" 
Crossplattform-Programmierung ist das Zauberwort, welches in den letzten Jahren - dank verstärkter Präsenz von Linux - immer wieder in den Programmierforen des Internets auftaucht. Für Grafikprogrammier ist [[SDL]] hier das Mittel der Wahl. Bekannte Titel wie "Quake III" und "Civilisation - Call to Power" bauen bereits auf diese Bibiothek für ihre Linux-Ports. Phobeus zeigt euch in diesem ersten SDL-Tutorial was SDL ist und wie man es benutzt.
|-
|}
</div>

== Grundlagen-Tutorials ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Abseits eckiger Welten]]
{{Level_2}}
|[[Bild:Tutorial_Abseits_eckiger_Welten.gif|right]] "Abseits eckiger Welten" 
3D-Welten bestehen seit eh und je aus Dreiecken, was sie oft recht eckig erscheinen lässt. In diesem Tutorial lernt ihr allerdings wie man mit Hilfe von Evaluatoren in OpenGL auch Rundungen erzeugen kann.
|-
![[Tutorial Renderpass]]
{{Level_1}}
|[[Bild:Tutorial_Renderpass.jpg|right]] "Renderpass - Die Welt daneben" 
OpenGL bietet nicht nur die Möglichkeit seine Szene direkt auf den Bildschirm zu rendern, sondern auch diese in eine Textur zu rendern um diese dann auf ein Objekt zu kleben. Dadurch ergeben sich diverse neue Möglichkeiten, wie z.B. Spiegel, Portale oder nachträgliche Manipulation der Textur. Wie ihr eure Szene in eine Textur bekommt, erfahrt ihr hier.
|-
![[Tutorial Selection]]
{{Level_2}}
|[[Bild:Tutorial_Selection.gif|right]] "Objectselektion A" 
Die Selektion von Objekten braucht man spätestens dann, wenn man ein komfortable Interaktion mit der Spielwelt erstellen will. Mit diesem Tutorial von DCW_MrT ist die Thematik kein Problem mehr.
|-
! [[Tutorial Objektselektion]]
{{Level_2}}
| [[Bild:Tutorial_Selection_tut03.jpg|right]] "Objektselektion B" 
Wie simpel der Objektselektionsmodus von OpenGL zu benutzen ist, wird in diesem Tutorial von Sascha Willems vermittelt. Dazu gibt es den Source-Code und eine fertig kompilierte Anwendung.
|-
![[Tutorial TexFilter]]
{{Level_1}}
|[[Bild:Tutorial_TexFilter.jpg|right]] "Texturfilterung - Texturen-Feintuning" 
Texturen sind seit langem ein wichtiger Bestandteil im Bereich der Echtzeitgrafik. OpenGL bietet auf diesem Gebiet auch diverse Möglichkeiten Texturen auch filtern zu lassen. Welche das sind und wie sie sich auswirken, könnt ihr in diesem Tutorial von Delphic nachlesen.
|-
![[Tutorial Kamera1]]
{{Level_2}}
|[[Bild:Tutorial_Kamera1.gif|right]] "Dreht sich das Universum um uns? und andere philosophische Fragen" 
In diesem Tutorial von Delphic geht es um die Kamera. Wie eine Kameraklasse gebaut sein könnte und was sie macht wird hier erklärt.
|-
|}
</div>

== Effekte ==
<div align="center">
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Nebel]]
{{Level_2}}
|[[Bild:Tutorial_Nebel.jpg|right]] "DGL Fogging Tutorial". 
Erstaunlich einfach lässt sich mit OpenGL Nebel darstellen. Wie einfach, zeigt euch Lithander in diesem Tutorial.
|-
![[Tutorial Partikel1]]
{{Level_2}}
|[[Bild:Tutorial_Partikel1.gif|right]] "Partikel-Tutorial I". 
Eine Partikel-Engine sollte in (fast) jeder Engine enthalten sein. Anhand dieses Tutorials von Lithander könnt ihr den Grundstein dazu legen.
|-
![[Tutorial BumpMap]]
{{Level_3}}
|[[Bild:Tutorial_BumpMap.png|right]] "Bumpmapping - Plastisches 2D". 
Bumpmapping ist eine immer stärker genutzte Technik, um polygonarme Oberflächen ohne Tesselation mit vorgegaukelten Details - abhängig vom Lichteinfall - zu versehen. In diesem Tutorial zeigt euch HomerS, wie man Bumpmapping über die NVIDIA-spezifischen Combiner realisiert.
|-
![[Tutorial Bumpmaps mit Blender]]
{{Level_1}}
|[[Bild:Tutorial_BumbBlend_Preview.png|right]]
Mit dem kostenlosen 3D-Program Blender können einfache Bumpmaps erstellt werden. Wie das geht, erfahrt ihr in diesem Tutorial von Flo.

{{Hinweis|Das Programm "Blender" bekommt ihr kostenlos auf [http://blender3d.org blender3d.org]}}

|-
![[Tutorial MultiTexturing]]
{{Level_2}}
|[[Bild:Multitex05.jpg|right]] "Multitexturing". 
Wie man mehrere Texturen auf ein Polygon bringen kann, erklärt auch Sascha Willems in diesem Tutorial zum Thema Multitexturing. Multitexturing ist seit OpenGL1.3 Teil des GL-Kerns und kann für z.B. für Lightmapping bzw. Detailmapping verwendet werden.
|-
![[Tutorial StencilSpiegel]]
{{Level_3}}
|[[Bild:Tutorial_StencilSpiegel.jpg|right]] "Spiegelungen mit dem Stencil-Buffer". 
Eine Echtzeit-Spiegelung ist einer der schönsten Effekte einer 3D-Welt und trägt viel zum Realismus bei. Eine Möglichkeit Spiegelungen über den Stencilpuffer zu realisieren, wird in diesem Tutorial von Sascha Willems erklärt.
|-
![[Tutorial StereoSehen]]
{{Level_3}}
|[[Bild:Tutorial_StereoSehen.gif|right]]Auch wenn moderne Grafikkarten durch eine immer besser werdende Darstellung dem Benutzer versuchen das Betreten einer virtuellen 3D-Welt vorzugaukeln, so schafft es doch auch das beste Doom3-Monster nur bis zur Glasröhre zu erschrecken, rutscht dann aber quietschend davon ab. Was also tun, wenn man einen Schritt weiter gehen und dem Anwender wirkliches 3D bieten möchte? Wer eine 3D-Brille hat, wird mit diesem Tutorial von Nico Mechaelis eine Möglichkeit finden, die dritte Dimension am Computer zur erschließen.
|-
![[Tutorial Alphamasking]]
{{Level_2}}
|[[Bild:Tutorial_Alphamasking_tut04.jpg|right]]In diesem kleinen aber feinen Tutorial erklärt Sascha Willems, wie man Alphamasking dazu verwenden kann, eine Szene optisch aufzuwerten und gleichzeitig Performance zu sparen.
|}
</div>

==Extensions==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Cubemap]]
{{Level_3}}
|[[Bild:Tutorial_Cubemap_mini.jpg|right]] "GL_ARB_Texture_Cubemap". 
In diesem Tutorial erklärt Sascha Willems die Grundfunktionen der '''GL_ARB_Texture_Cubemap'''-Extension und zeigt auch weiterführende Techniken auf.
|-
![[Tutorial Vertexbufferobject]]
{{Level_3}}
|[[Bild:Tutorial Vertexbufferobject preview.jpg|right]] "GL_ARB_Vertex_Buffer_Object". 
Wie man mit dieser Extension Vertexdaten schnell im Grafikkarten- und Hauptspeicher ablegt und darauf zugreift, erklärt Sascha Willems in diesem Tutorial.
|-
![[Tutorial Vertexprogramme]]
{{Level_3}}
|[[Bild:Tutorial_VP_preview.jpg|right]] "GL_ARB_Vertex_Program". 
In diesem umfangreichen Tutorial werden alle wichtigen Bereiche der Programmierung mit der GL_ARB_Vertex_Program-Extension abgedeckt. Man kann es als umfassende deutsche Referenz zu diesem Thema sehen, da auch alle wichtigen Funktionen aufgelistet werden und es auch sonst an nichts fehlt.
|-
![[Tutorial NVOcclusionQuery]]
{{Level_3}}
|[[Bild:Tutorial_NVO_preview.jpg|right]] "NV_Occlusion_Query". 
Lard Middendorf geht in diesem Tutorial auf die Verwendung der NV_Occlusion_Query-Extension ein.
|-
![[Tutorial Pixelbuffer]]
{{Level_3}}
|[[Bild:Tutorial_Pixelbuffer_preview.jpg|right]] "WGL_ARB_Pixel_Buffer". 
Sascha Willems erklärt hier leicht verständlich den Umgang mit der Pixelbuffer-Extension. Als Additum wird auch noch auf die Nutzung dieser Extension für Shadowmapping eingegangen.
|}

== Shader ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial glsl|Tutorial glSlang]]
{{Level_4}}
|[[Bild:Tutorial_glsl1.png|right]] "Einführung in GLSL". 
Nach langem Ringen und Handeln hat es das ARB letztendlich doch geschafft, eine einheitliche Shaderhochsprache für OpenGL zu veröffentlichen, nämlich ''glSlang''. Mit glSlang können nun auch unter OpenGL Vertex- und Fragment-Shader in einer lesbaren, C-ähnlichen Hochsprache geschrieben werden, was deren Entwicklung stark vereinfacht. Diese Einführung von Sascha Willems ist weniger ein Tutorial, als ein kompletter Überblick über glSlang. Hier erfährt der Leser nicht nur etwas über die Benutzung von Shadern im Programm, sondern auch alles über die Sprachelemente, inklusive diverser Beispiele.
|-
![[Tutorial glsl2|Tutorial glSlang 2]]
{{Level_4}}
|[[Bild:Tutorial_na.jpg|right]] "GLSL-Ergänzungen und Beispiele". 
Dieses Tutorial von La_Boda ist eine direkte Fortsetzung des GLSL-Tutorials. Es behandelt verstärkt die Praxis und liefert anhand von einigen Beispielen eine bessere Sicht auf die bereits gelernte Theorie.
|-
|}

== KI ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial pathfinding|Tutorial Pathfinding]]
{{Level_2}}
|[[Bild:Tutorial_pathfinding.png|right]] "Pathfinding 1". 
In diesem Tutorial zeigt euch Flo wie man recht simpel eine Wegfindungsroutine implementiert. Besonders wenn man sowas ohne großen Lernaufwand in sein Spiel einbinden möchte, sollte man einen Blick riskieren.
|-
![[Tutorial pathfinding2|Tutorial Pathfinding 2]]
{{Level_3}}
|[[Bild:Tutorial_pathfinding2.png|right]] "Pathfinding 2". 
Gerade bei aktuelleren Programmen reicht es meist nicht aus, wenn man seine Einheiten nur in 8 Himmelsrichtungen bewegen kann. Frase stellt in diesem Tutorial vor, wie man eine Wegfindungsroutine implementieren kann, wie diese in einem heutigen RTS vorkommen kann.
|-
|}

== Terrain und Landschaften ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Terrain1]]
{{Level_4}}
|[[Bild:Tutorial_Terrain1.gif|right]] "Aussenlandschaften mit System - Heightmaps". 
Anhand der Graustufenwerte einer Bitmap-Datei kann man relativ einfach eine imposante Landschaft erstellen. Wie das ganze funktioniert erklärt euch Nico Michaelis in diesem Tutorial. Außerdem wird noch die Implementation von Skyboxen erklärt.
|-
![[Tutorial Terrain2|Tutorial Terrain 2]]
{{Level_4}}
|[[Bild:Tutorial_Terrain2.gif|right]] "Heightmap-Texturen". 
Da das Terrain aus dem vorigen Tutorial noch recht eintönig grau aussieht und das natürlich geändert werden soll, erklärt euch Nico, wie man schmucke Schatten und Texturen für die Heightmap generieren kann.
|-
![[Tutorial Terrain3|Tutorial Terrain 3]]
{{Level_5}}
|[[Bild:Tutorial_Terrain3.gif|right]] "Terrain im Detail". 
Da größere Landschaften aufgrund der hohen Polygonanzahl sehr aufwändig zu rendern sind erklärt euch Nico hier, wie man entfernte Dreiecke "zusammenlegen" kann, um Rechenleistung zu sparen.
|-
![[Tutorial Skyboxen]]
{{Level_2}}
|[[Bild:Tutorial_Skybox_Vorschau.jpg|right]] "Skyboxen". 
In diesem Tutorial erklärt Sascha Willems kurz und bündig den Umgang mit Skyboxen, mit denen man Landschaften schnell sehr stark optisch aufwerten kann. Es wird sowohl auf die Erstellung der Skybox-Texturen mit dem Programm Terragen als auch die Implementation der Skybox in OpenGL eingegangen.
|-
|}

== Spieletutorials und Softwareentwicklung==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Bomberman1|Tutorial Bomberman 1]]
{{Level_3}}
|[[Bild:Tutorial_Bomberman1.jpg|right]] "Bomberman1 - Codebasis und Editor". 
Im ersten Teil dieser kleinen Tutorialserie zum Thema Spieleprogrammierung kümmern wir uns neben der Erstellung unseres Basiscodes auch um einen fertigen Editor. Nach der Durcharbeitung dieses Tutorials von Sascha Willems sollte der Leser alle Grundprinzipien zur Programmierung eines Spiels verstanden haben.
|-
![[Tutorial Bomberman2|Tutorial Bomberman 2]]
{{Level_3}}
|[[Bild:Tutorial_Bomberman2.jpg|right]] "Bomberman2 - Der 3D-Bombermanklon (Grundversion)". 
Im zweiten Teil gehts ans Eingemachte, nämlich einen fertigen Bombermanklon. In Sascha Willems Tutorial werdet ihr zusätzlich zu den bereits erworbenen Prinzipien diverse Techniken die in so ziemlich jedem Spiel Verwendung finden erlernen.
|-
![[Tutorial Softwareentwicklung1|Tutorial Softwareentwicklung 1]]
{{Level_3}}
|[[Bild:Tutorial_SWE1.jpg|right]] "Softwareentwicklung1 - Objektorientierte Softwareentwicklung mit UML". 
Im ersten Teil dieser Tutorialserie zum Thema Softwareentwicklung erklärt euch Flash, wie man an ein Projekt herangeht und herausfindet was eigentlich zu tun ist. Es geht dabei um Analyse der Anforderungen und die Modellierung sogenannter Use Cases. Die hier vorgestellten Arbeiten sind Grundlage um später Klassen zu finden auf denen dann der Code aufgebaut wird.
|-
![[Tutorial Softwareentwicklung2|Tutorial Softwareentwicklung 2]]
{{Level_3}}
|[[Bild:Tutorial_SWE2.jpg|right]] "Softwareentwicklung2 - Objektorientierte Softwareentwicklung mit UML". 
Im zweiten und umfangreichsten Teil der Serie steht das Thema "Klassen" im Zentrum. Flash erklärt euch wie man aus den Use Cases Klassen ableitet und welche unterschiedlichen Einsatzgebiete Klassen innerhalbd er Software haben können.
|-
|}

== Mathematisches ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Lineare Algebra]]
{{Level_2}}
|[[Bild:Tutorial_lineare_Algebra_Preview.jpg|right]] "Vektorrechnung". 
In vielen Tutorials tauchen eine Menge Begriffe aus der linearen Algebra und analytischen Geometrie auf. Wer bei Begriffen wie Vektoren, Skalar-Produkt, Vektorkreuzprodukt, etc. ein wenig Auffrischung und Implementationshinweise braucht, ist mit diesem Tutorial von EternalLearner an der richtigen Stelle.
|-
![[Tutorial Nachsitzen]]{{Level_1}}
|[[Bild:Tutorial_Nachsitzen_preview.png|right]] "3d-Mathematik". 
Wer die mathematischen Grundlagen wie Sinus, Cosinus und Matrizen aus der Schule schon wieder vergessen oder noch vor sich liegen hat, der kann mit Hilfe dieses Tutorials von Nico Michaelis dieses Wissen erlernen bzw. auffrischen.
|-
![[Tutorial Objekt gedreht und dennoch nach vorne bewegt]]
{{Level_2}}
|[[Bild:Tutorial_Objekt_gedreht_und_dennoch_nach_vorne_bewegt_preview.gif|right]] "Objekt gedreht und dennoch nach vorne bewegt". 
SchodMC erklärt in diesem Tutorial wie man ein Objekt drehen und dabei trotzdem vorwärts bewegen kann. Quer fahrende Autos sind zwar praktisch zum Einparken Aber doch eher selten ;-)
|-
![[Tutorial Objekt immer um eigene Achse drehen]]
{{Level_2}}
|[[Bild:Tutorial_Objekt_immer_um_die_eigene_Achse_drehen_preview.gif|right]] "Objekt immer um eigene Achse drehen". 
Wenn ihr euer Objekt nun noch um die eigene Achse drehen wollt, seid ihr mit diesem Tutorial von SchodMC an der richtigen Adresse
|-
|}

== Grafik und Modellierung ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Modellierung eines Low-Poly Menschen Teil 1]]
{{Level_4}}
|[[Bild:Tutorial_Low-Poly-Mensch1_preview.jpg|right]] "Modellierung eines Low-Poly-Menschen". 
Die Modellierung von organischen "Objekten" gehört mit zu den kompliziertesten Aufgaben, die es beim Modelling gibt. Wie man einen Menschen mit aus möglichst wenigen Polygonen mit dem Programm 3D Studio Max erstellen kann wird in diesem Tutorial von Sascha Willems erklärt.
|-
![[Tutorial Modellierung eines Low-Poly Menschen Teil 2]]
{{Level_4}}
|[[Bild:Tutorial_Low-Poly-Mensch2_preview.jpg|right]] "Kleider machen Leute (UVW-Mapping)". 
Nun spendiert Sascha Willems seinem Menschen aus dem 1. Tutorial eine schmucke Uniform, so dass er sich endlich in der Öffentlichkeit blicken lassen kann.
|-
|}

== Skripte ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
![[Tutorial Scripting mit JvInterpreterProgram]]
{{Level_2}}
|[[Bild:Tutorial_JvInterpreter_preview.png|right]] "Skripting mithilfe der Jedi-Code-Library". 
SchodMC erklärt hier wie man mit relativ wenig Aufwand Skripte in eigene Programme integrieren kann.
|-
![[Tutorial Scriptsprachen Teil 1]]
{{Level_5}}
|[[Bild:Tutorial_Skriptsprachen1_preview.gif|right]] "Scriptsprachen Teil 1 - Einführung". 
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Nico Michaelis genau das richtige.

Der erste Teil widmet sich der Lexikalischen Analyse und dem Parsen des Quellcodes
|-
![[Tutorial Scriptsprachen Teil 2]]
{{Level_5}}
|[[Bild:Tutorial_Skriptsprachen2_preview.gif|right]] "Scriptsprachen Teil 2 - Virtuelle Computer und Code Erzeugung". 
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Nico Michaelis genau das richtige.

Der zweite Teil beschreibt den Bau einer VM und der Codeerzeugung
|-
|}

== Delphi allgemein ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial Debugging]]
{{Level_2}}
| [[Bild:Tutorial Debugging.gif|right]] "Debugger benutzen und andere praktische Tipps" 
In diesem Tutorial werdet von Nico mit der Nutzung des Delphi-Debuggers eingeführt. Auch werden Wege zur Vermeidung von Fehlern aufgezeigt. Genauso findet Ihr aber auch in diesem Tutorial Hinweise, zu häufig begangenen Fehlern und deren Ursachen.
|-
! [[Tutorial Komponentenentwicklung]]
{{Level_2}}
| [[Bild:Tutorial Komponentenentwicklung.png|right]] "Komponentenentwicklung" 
In diesem Tutorial werdet ihr ein wenig tiefer in die Entwicklung von Komponenten unter Delphi eingeführt. Es wird Grundwissen auf diesem Gebiet vorausgesetzt.
|-
![[Tutorial Multithreading]]
{{Level_3}}
|[[Bild:Tutorial_Multithreading.gif|right]] "Das Prinzip der Dualität". 
Threads sind ein erweitertes Prinzip des bekannten Multitasking und werden innerhalb eines Programmes oft dazu genutzt, verschiedene Aufträge gleichzeitig abzuarbeiten. LossyEx erklärt euch hier deren Nutzung.
|-
! [[Tutorial Software-Synthesizer]]
{{Level_4}}
| [[Bild:Noexist.jpg|right]] "Software-Synthesizer" 
Computerspiele bestehen nicht nur aus Grafik. Dieses Tutorial widmet sich einem ganz anderen Bereich der Spieleprogrammierung: Der Erzeugung von synthetischen Sounds und Musik.
|}

== Rendertechniken ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial Octree]]
{{Level_1}}
| [[Bild:Tutorial Octree preview.jpg|right]] "Octrees" 
Octrees sind eine einfach zu implementierende, aber sehr effiziente Möglichkeit um besonders Outdoor-Szenen abhängig vom Betrachterblickfeld stark zu beschleunigen. In diesem Tutorial zeigt Shadow euch eine komplette Implementation eines Octrees inklusive ausgiebigem Quellcode.
|-
! [[Tutorial Frustum Culling]]
{{Level_1}}
| [[Bild:Tutorial Frustum Culling.jpg|right]] "Frustum Culling" 
Frustum Culling ist eine einfache Möglichkeit die Rendergeschwindigkeit zu erhöhen, da man damit schon vor dem Senden der Daten an die Grafikkarten feststellen kann, welche Objekte sich im Blickfeld des Spielers befinden und welche nicht.
|}

== Sonstiges ==
{|{{Prettytable_B1}} width="100%"
!width="15%"|Link
!width="85%"|Beschreibung
|-
! [[Tutorial GLScene]]
{{Level_1}}
| [[Bild:Tutorial GLScene preview.jpg|right]] "Einführung in GLScene" 
GLScene ist eine zu erstaunlicher Größe angewachsene Komponentensammlung, die quasi einen OpenGL-Wrapper darstellt und euch dank Delphis VCL dadurch recht einfach OpenGL-Programme erstellen lässt. LaBoda gibt euch zu dieser Komponentensammlung in diesem Tutorial deshalb eine kleine Einführung.
|}