DGL Wiki - Benutzerbeiträge [de]

glDrawElements

2017-11-08T11:46:19Z

End: /* Parameter */

= glDrawElements =

== Name ==
'''glDrawElements''' - Rendert Primitiven aus einem Datenarray heraus.

== Delphi-Spezifikation ==
procedure '''glDrawElements'''(''mode'' : glEnum; ''count'' : glSizei; ''_type'' : glEnum;
'''const''' ''indices'' : PGLvoid);

== Parameter ==

{| border="1" rules="all"
! ''mode''
| Gibt an welcher [[Primitiv]]en-Type gerendert werden soll. Hier sind die symbolische Konstanten '''GL_POINTS, GL_LINE_STRIP, GL_LINE_LOOP, GL_LINES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_TRIANGLES, GL_QUAD_STRIP, GL_QUADS''' und '''GL_POLYGON''' erlaubt.
|-
! ''count''
| Anzahl der zu rendernden Elemente.
|-
! ''type''
| Gibt den Typ der Werte in ''indices'' an. Muss entweder '''GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT''' oder '''GL_UNSIGNED_INT''' sein.
|-
! ''indices''
| Zeiger hinter dem die Indizes hinterlegt sind. Wird ein Buffer Object verwendet, gibt dieser Parameter das Offset im Buffer in Bytes an.
|}

== Beschreibung ==
'''glDrawElements''' beschreibt mehrere geometrische Primitiven mit nur sehr wenigen Unteraufrufen. Anstatt also für einzelne [[Eckpunkt]]e, [[Normalen]], [[Texturkoordinate]]n, Kantenflags oder Farbwerte einen eigenen GL-Befehl aufzurufen, kann man hier für Eckpunkte, Normalen, usw. eigene Arrays angeben und nutzen, um mit '''glDrawElements''' eine Sequenz von Primitiven mit nur einem Befehl zu rendern.

Wenn '''glDrawElements''' aufgerufen wird, nimmt es ''count'' Elemente aus den aktivierten Arrays, deren Positionen in ''indices'' gespeichert sind, um eine Abfolge geometrischer [[Primitive]]n zu erstellen. ''mode'' gibt dabei an, welche Art von [[Primitive]] konstruiert werden soll und wie diese Arrayelemente [[Primitive]]n darstellen. Wenn mehr als ein Array aktiviert wurde, werden diese auch genutzt (Vertexarray, Normalenarray, Farbarray, Texturkoordinatenarray, etc.) Wenn '''GL_VERTEX_ARRAY''' nicht aktiviert ist, werden allerdings keine geometrischen [[Primitive]]n erstellt.

Vertexattribute, die durch '''glDrawElements''' verändert werden, haben nach dem Rücksprung von '''glDrawElements''' undefinierte Werte. Wenn z.B. '''GL_COLOR_ARRAY''' aktiviert wurde, ist der aktuell gesetze Farbwert nach der Ausführung von '''glDrawElements''' undefiniert. Unveränderte Attribute behalten allerdings ihren angegebenen Status.

Der Effekt von '''glDrawElements''' ist derselbe wie
<source lang="pascal"> glBegin(''mode'');
for i := 0 to ''count'' - 1 do begin
glArrayElement(''indices''[i]);
end;
glEnd();</source>

=== Beispiele ===
'''Beispiel 1'''
oneIndices : ARRAY[0..6] OF GLubyte = (0, 1, 2, 3, 4, 5, 6);
twoIndices : ARRAY[0..5] OF GLubyte = (7, 1, 8, 9, 10, 11);
...
glDrawElements(GL_LINE_STRIP, 7, GL_UNSIGNED_BYTE, @oneIndices);
glDrawElements(GL_LINE_STRIP, 6, GL_UNSIGNED_BYTE, @twoIndices);
 
'''Beispiel 2'''
 
Ein Array mit Farbwerten und ein Array mit Vertices werden eingebunden, aktiviert und mit einem 16-Bit (entspricht Word) Indexarray über '''glDrawElements''' gezeichnet:
glEnableClientState(GL_COLOR_ARRAY);
glEnableClientState(GL_VERTEX_ARRAY);

glColorPointer(4,GL_UNSIGNED_BYTE,0,@Colors[0]);
glVertexPointer(3,GL_FLOAT,0,@Positions[0]);

glDrawElements(GL_LINE_STRIP, Count, GL_UNSIGNED_SHORT, @Indices[0]);

glDisableClientState(GL_COLOR_ARRAY);
glDisableClientState(GL_VERTEX_ARRAY);
 

== Hinweise ==
'''glDrawElements''' ist erst ab GL Version 1.1 oder höher nutzbar.

'''glDrawElements''' wird in [[Displaylisten]] eingebunden, wenn die Funktion also in eine Displayliste kompiliert wird, werden die benötigten Arrayzeiger (welche das sind, wird durch die Arrayzeiger und aktivierten States beschrieben) in die Displayliste kompiliert. Dies geschieht, da die Arrayzeiger und aktivierten States clientseitige States sind, und die Displayliste daher nur bei ihrer Erstellung beeinflussen, nicht jedoch bei ihrer Ausführung.

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird generiert, wenn ''mode'' keinen gültigen Wert enthält.

'''GL_INVALID_VALUE''' wird, generiert wenn ''count'' negativ ist.

'''GL_INVALID_OPERATION''' wird generiert, wenn '''glDrawElements''' in einem [[glBegin]]-[[glEnd]] Block aufgerufen wird.

== Siehe auch ==
[[glArrayElement]], [[glEnableClientState]], [[glDisableClientState]], [[glBegin|glBegin / glEnd]], [[glColorPointer]], [[glDrawArrays]], [[glDrawRangeElements]], [[glEdgeFlagPointer]], [[glFogCoordPointer]], [[glGetPointerv]], [[glGetString]], [[glIndexPointer]], [[glInterleavedArrays]], [[glMultiDrawArrays]], [[glMultiDrawElements]], [[glNormalPointer]], [[glSecondaryColorPointer]], [[glTexCoordPointer]], [[glVertexPointer]]

[[Kategorie:GL|DrawElements]]
[[Kategorie:GL1.1|DrawElements]]
[[Kategorie:GL3|DrawElements]]

DGL Treffen/2017/Organisation

2017-05-22T23:29:35Z

End: pfannkuchen

Wie bereits im Forum angedroht, planen wir momentan ein DGL-Treffen in Schweden im Juli 2017. Hierfür geht es an einen See in Ryd.

;Thema: "Going Wild" ;-)

Weitere Infos und detaillierte Besprechungen finden in [https://delphigl.com/forum/viewtopic.php?f=4&t=11569 diesem Forenthread] statt.

==Wo?==
S25105
Södra Rimshult 2,
Ryd

[http://www.novasol.de/p/S25105?PE=8&K=0&SD=01-07-2017&DUR=14&ED=15-07-2017&wt.si_n=NormalSearchBookingFlow#overview-tab Novasol Link]

Latitude:56.41619, Longitude:14.7563549.

==Wann?==
*Anreise: Sa. 01.07.2017
*Abreise: Sa. 15.07.2017

==Was kostet das?==
Ein Preis von 500€-700€ wird angestrebt. Letztendlich hängt der Preis davon ab, wieviel verzerrt und unternommen wird. Anreise erfolgt gemeinsam über Gruppen. Die Anreise bis zu einem gemeinsamen Treffpunkt muss selbstständig organisiert werden.
Die Verpflegung erfolgt üblicherweise über eine Umlage und wir holen uns gemeinsam etwas.

Die Abrechnung erfolgt einige Wochen nach Ende. Wer einen längeren Zahlungshorizont braucht, sollte dies bitte vorher bei Phobeus melden.
Sollte jemand aus Kostengründen nicht teilnehmen können, kann er sich per Mail an Phobeus wenden.

==Wer kommt mit?==
Zumindest nicht mehr, wer sich nicht bisher angemeldet hat. Es sind 8 Betten im Haus und diese sind bereits alle belegt. Bitte beim nächsten Mal rechtzeitig melden und alle mit Bedarf können mitkommen ;)

ARG = Anreisegruppe ;)

[[Datei:DGL_Treffen_2017_Feldkarte.jpg|200px|thumb|right|Feldkarte für die Anfahrt]]

{|{{Prettytable_B1}}
!Teilnehmer
!Tage
(14=max)
!Anreise
!Kommentar
|-
|Phobeus
|14
|PKW
|(ARG Nord: 1 Plätze im PKW frei ab Hamburg.)
|-
|i0n0s
|14
|PKW
|(ARG SÜD: 1 Platz im PKW frei ab Gießen.)
|-
|Pixelschubser
|14
| -
|(Anreise über ARG Nord)
|-
|Flash
|14
|PKW
| ARG Ost: 2-3 Plätze im Wagen (?) frei ab Chemnitz
|-
|TAK2004
|14
| -
| Anreise über ARG Ost?
|-
|Frase
|14
| -
| Anreise über ARG Ost
|-
|End
|14
| -
| Anreise über ARG Süd oder ARG Nord
|-
| ''offen''
|
| -
|
|-
| ''offen''
|
| -
|
|-
| ''offen''
|
| -
|
|-
|}

==Wie kommt man hin?==
Die Anreisedetails stehen noch nicht fest. Mögliche Anreise einen Tag vorher und Übernachtung in Hamburg bei Phobeus ist möglich. Von dort aus geht es Richtung Rostock, wo der nächste Treffpunkt für die Überfahrt mit der Fähre ist. Von da aus geht es dann mit dem Auto bis zum Ziel

==Was muss man persönlich mitbringen?==
* ggf. Reisekasse für eigene Einkäufe (Schweden hat keinen Euro!)
* Bettwäsche und Handtücher
* Wechsel-Kleidung
* Reisedokumente (Führerschein, Personalausweis, Versicherungs- und Geldkarten)
* Reiseapotheke
* Hygieneartikel
* Badesachen (inkl. Sonnencreme, Mückencreme)
* Sonstiges (was zu lesen, Schreibzeug etc.)

==Was müssen wir gemeinsammitbringen?==
* Klopapier
* Netzwerkkabel (!!!!)
* Steckdosenleisten (!!!!!)
* Küchenequipement (Gewürze, Dosenöffner/Korkenzieher/Flaschenöffner, Kaffeefilter, Geschirrtücher, Wischtücher, Küchenrolle, Spülmittel)
* Elektronik (1 Router, Laptop, Netzwerkkabel, Fotoapparat)

==Was gibts zu erleben?==
*DGLer in echt ;)
*Spiel und Spannung
*Eine große weiße Leinwand zum bewundern (?)
*Ausgebildete Barkeeper
*Baden und Grillen
*Mini-LAN
*Virtuelle Realitäten (?)
*Live Projektvorstellung
*Wildnis pur! (To be discussed, ob draußen oder drinnen)

==Was gibts zu essen?==

Wir kochen und essen gemeinschaftlich. So kommt jeder an die Reihe und sollte entsprechend etwas parat haben. Jeder Koch verfügt über eine beliebige Anzahl an Hilfssklaven. Urbanen Legenden zufolge sollen schlechte Köche früher häufiger mal über Bord gegangen sein. Zudem verhindern satte Beuche Aufstände bereits im Keim!

Hauptmahlzeiten
{|{{Prettytable_B1}}
!Koch
!Speise
!Benötigte Zutaten
|}

Zwischenmahlzeiten / Snacks
{|{{Prettytable_B1}}
!Koch
!Speise
!Benötigte Zutaten
|}

==Einkaufsliste==

Alt aus Dänemark und nur als Orientierung drin:
----Frühstück-----
*100 Eier
*3kg Bacon
*14kg Müsli
*40l H-Milch
*100 Aufback-Brötchen (ohne Kühlung!)
*8 Aufback-Baguettes (ohne Kühlung!)
*8kg Käse & Wurst
*8 Marmeladen
*4 Butter
*60l Orangensaft
*20 Packungen Quark
*300gr Speck
----Obst------
*10kg Äpfel
*2kg Birnen
*2kg Pfirsiche,
*2 große Wassermelonen
*4 Honigmelonen (Zergeneier ^^)
*2kg Kiwis
*5kg Tomaten
*2kg Paprika
*4 Gurken
*2kg Zwiebeln
*2-3 Salate (Haltbarkeit :()
*6kg Kartoffeln
----Abgepacktes----
*4 Dosen Mais
*2 Dosen Thunfisch
*1kg TK-Spinat
*8 Pack Schafskäse
*4kg Pizzakäse
*2kg Gouda
*5 Dosen Tomaten
*5 Dosen Bohnen
*3kg Mehl (550)
*3 Pack Frischhefe
*Rinderbrühe
*3 Packungen Sauerkraut
*1 Glas eingelegte Gurken
----Knapperkram---
*30 diverse Chipstüten
*6kg Nussmischungen
----Cocktails-----
*1 Flasche Havana Club
*2 Flaschen Wodka
*4l Ananassaft
*4l Grapefruitsaft
*8l Marakuja Saft
*Zuckersirup
----Sonstiges----
*Toilettenpapier (1 Großpack)
*Küchenpapier
*Müllbeutel >30l
*Waschmittel
*Backpapier
*1 Pack Zucker
*Salz
*Körniges Salz
*Pfeffer
*2l Olivenöl
*1l Essig
*Grillkohle
*Grillanzünder & Feuerzeug
*Alufolie
----Fleisch------
*2kg Fleisch zum Grillen
*2kg Kassler
*1kg geräucherte Mettenden
*2kg Hähnchenbrust
*48 Hotdogwürstchen
*24 Hotdogbrötchen
*Remouladensoße
*Diverse Grillsoßen
*Geröstete Zwiebeln
*Ketchup
*Senf
-----Onigiri----
*Sushireis
*Sushi-Essig
*Nori
----Ends patentierte Pfannkuchen----
1x Pfannkuchen fuer alle =
*10 Eier
*1kg Mehl
*1 Liter Milch
*1 Mixer
*1 bis 2kg Zucker
*eine Prise Salz

Wahlweise kann Mehl durch Zucker jeder Sorte oder Muesli substituiert werden

glGetShaderInfoLog

2013-12-04T18:22:33Z

End: var hinzugefügt.

= glGetShaderInfoLog =

== Name ==
'''glGetShaderInfoLog''' - Gibt das Information-Log eines Shaderobjekts aus

 
== Delphi-Spezifikation ==

procedure '''glGetShaderInfoLog'''(''shader'' : GLuint; ''maxLength'' : GLsizei; var ''length'' : GLInt; ''infoLog'' : PGLchar)

== Parameter ==

{| border="1" rules="all"
! ''shader''
| Gibt das Shaderobjekt an, dessen Information-Log abgefragt werden soll.
|-
! ''maxLength''
| Gibt die Größe des Zeichen-Puffers für das Speichern des erhaltenen Information-Logs an.
|-
! ''length''
| Gibt die Länge des Strings (ohne die Null-Terminierung) an, der nach ''infoLog'' ausgegeben wird.
|-
! ''infoLog''
| Gibt ein Zeichen-Array an, das verwendet wird, um das Information-Log auszugeben.
|}

== Beschreibung ==
'''glGetShaderInfoLog''' gibt das Information-Log für das spezifizierte Shaderobjekt aus. Das Information-Log eines Shaderobjekts wird verändert, wenn das Shaderobjekt gelinkt oder validiert wird. Der ausgegebene String ist null-terminiert.

'''glGetShaderInfoLog''' legt in ''infoLog'' maximal so viele Zeichen des Information-Log ab, wie durch ''maxLength'' angegeben wurde. Die Anzahl der ausgegebenen Zeichen - ausschließlich der Null-Terminierung - wird durch ''length'' angegeben. Wenn die Länge des ausgegenen Strings nicht von Interesse ist, kann '''nil''' als ''length''-Argument verwendet werden. Die Größe des Puffers, der zum Speichern des zurückgelieferten Information-Log verwendet wird, kann durch einen Aufruf von [[glGetShader]] mit dem Argument '''GL_INFO_LOG_LENGTH''', herausgefunden werden.

Das Information-Log für ein Shaderobjekt ist entweder ein leerer String oder ein String, der Informationen über die letzte Link- oder Validierungs-Operation enthält. Das Log kann Diagnose-Nachrichten, Warnungen und andere Informationen enthalten. Wenn ein Shaderobjekt erzeugt wird, ist sein Informations-Log nicht unbedingt ein String mit der Länge 0, beispielsweise können gewisse OpenGL-Implementationen die Ausgabe "no errors." mit length 11 ausgeben. Deshalb sollte man vor einem Aufruf von '''glGetShaderInfoLog''' [[glGetShader]] mit dem Argument '''GL_COMPILE_STATUS''' abfragen.

 

== Hinweise ==
'''glGetShaderInfoLog''' ist nur in OpenGL-Versionen ab mindestens 2.0 verfügbar.

Das Information-Log für ein Shaderobjekt ist der wichtigste Weg der OpenGL-Implementation, Informationen über das Linken und Validieren mitzuteilen. Das Information-Log kann während dem Entwicklungsprozess hilfreich für Programmierer sein, auch wenn diese Operationen erfolgreich verlaufen. Man sollte aber nicht erwarten, dass verschiedene OpenGL-Implementationen (vor allem von verschiedenen Herstellern) identische Information-Logs liefern.

== Fehlermeldungen ==
'''GL_INVALID_VALUE''' wird generiert, wenn ''shader'' kein von OpenGL erzeugter Wert ist.

'''GL_INVALID_OPERATION''' wird generiert, wenn ''shader'' kein Shaderobjekt ist.

'''GL_INVALID_VALUE''' wird generiert, wenn ''maxLength'' kleiner 0 ist.

'''GL_INVALID_OPERATION''' wird generiert, wenn '''glGetShaderInfoLog''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGetShader]] mit Token [[glGetShader#GL_INFO_LOG_LENGTH|GL_INFO_LOG_LENGTH]]

[[glIsShader]]

== Siehe auch ==
[[glCompileShader]], [[glGetShaderInfoLog]], [[glLinkProgram]], [[glValidateProgram]]

[[Kategorie:GL|GetProgram]]

SDL DisplayFormatAlpha

2013-09-07T10:03:01Z

End: Versionskennzeichnung.

= SDL_DisplayFormat =

== Name ==
'''SDL_DisplayFormat''' - Konvertiert eine Surface ins Anzeigeformat. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_DisplayFormat'''(''surface'' : PSDL_Surface) : PSDL_Surface

== Parameter ==

{| border="1" rules="all"
! ''surface''
| Die Surface die kopiert und konvertiert werden soll
|}

== Beschreibung ==
Die übergebene Surface wird in eine neue Surface kopiert, die das aktuell verwendete Pixelformat des Videopuffers verwendet.

An dieser Stelle können auch die Vorteile von Hardware Colorkey und Alpha-Blit-Beschleunigung genutzt werden.

Diese Funktion kann auch dazu benutzt werden, um eine Farbe in einen Alphakanal umzuwandeln, wenn der SDL_SRCCOLORKEY-Flag in der Surface gesetzt ist. Dann wird auf der generierten Surface an der stelle, wo die Farbe zutrifft Alpha=0 sein (transparent), ansonsten Alpha=1 (voll sichtbar).

== Rückgabewert ==
Wenn die Konvertierung erfolgreich ist, wird der Pointer auf die neue Surface zurückgeliefert, sonst (wenn z.B. der Speicher überläuft), wird '''nil''' zurückgegeben.

== Siehe auch ==
[[SDL_ConvertSurface]], [[SDL_DisplayFormat]], [[SDL_SetAlpha]], [[SDL_SetColorKey]], [[SDL_Surface]]

[[Kategorie:SDL|DisplayFormat]]

SDL DisplayFormat

2013-09-07T10:02:47Z

End: Versionskennzeichnung.

= SDL_DisplayFormat =

== Name ==
'''SDL_DisplayFormat''' - Konvertiert eine Surface ins Anzeigeformat. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_DisplayFormat'''(''surface'' : PSDL_Surface) : PSDL_Surface

== Parameter ==

{| border="1" rules="all"
! ''surface''
| Die Surface die kopiert und konvertiert werden soll
|}

== Beschreibung ==
Die übergebene Surface wird in eine neue Surface kopiert, die das aktuell verwendete Pixelformat des Videopuffers verwendet.

An dieser Stelle können auch die Vorteile von Hardware Colorkey und Alpha-Blit-Beschleunigung genutzt werden.

Wenn der Alphakanal verwendet werden soll, muss die Funktion [[SDL_DisplayFormatAlpha]] verwendet werden.

== Rückgabewert ==
Wenn die Konvertierung erfolgreich ist, wird der Pointer auf die neue Surface zurückgeliefert, sonst (wenn z.B. der Speicher überläuft), wird {{INLINE_CODE|nil}} zurückgegeben.

== Siehe auch ==
[[SDL_ConvertSurface]], [[SDL_DisplayFormatAlpha]], [[SDL_SetAlpha]], [[SDL_SetColorKey]], [[SDL_Surface]]

[[Kategorie:SDL|DisplayFormat]]

SDL CreateRGBSurfaceFrom

2013-09-07T10:01:02Z

End: Versionskennzeichnung.

= SDL_CreateRGBSurfaceFrom =

== Name ==
'''SDL_CreateRGBSurfaceFrom''' - Erstellt eine neue [[SDL_Surface]] aus den gegebenen Pixeldaten. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_CreateRGBSurfaceFrom'''(''pixels'': Pointer; ''width'', ''heigth'', ''depth'': Integer;
''RMask'', ''GMask'', ''BMask'', ''AMask'': Uint32): PSDL_Surface

== Parameter ==

{| border="1" rules="all"
! ''pixels''
| Vorhandene Pixeldaten
|-
! ''width, heigth''
| Grösse der Surface
|-
! ''depth''
| Anzahl der Bits pro Pixel (siehe [[SDL_Surface]])
|-
! ''RMask'', ''GMask'', ''BMask'', ''AMask''
| Benötigt für 24 und 32 Bit Surfaces.
| Beschreibt im welchen 'Teil' des Pixels sich z.b. Rot befindet.
|}

== Beschreibung ==
Erstellt eine [[SDL_Surface]] im Speicher aus dem im ''pixels'' übergebenen Pixeldaten
(darf erst nach [[SDL_SetVideoMode]] aufgerufen werden).

== Hinweise ==
Die Pixeldaten müssen den übergebenen Parametern entsprechen.
Sie werden '''nicht''' in die [[SDL_Surface]]-Struktur kopiert, weshalb das Freigeben dieser Daten erst nach [[SDL_FreeSurface]] erfolgen darf.

== Rückgabewert ==
'''SDL_CreateRGBSurfaceFrom''' gibt '''nil''' zurück, wenn ein Fehler aufgetreten ist.

== Siehe auch ==
[[SDL_CreateRGBSurface]], [[SDL_FreeSurface]]

[[Kategorie:SDL|CreateRGBSurfaceFrom]]

SDL CreateRGBSurface

2013-09-07T10:00:48Z

End: Versionskennzeichnung.

= SDL_CreateRGBSurface =

== Name ==
'''SDL_CreateRGBSurface''' - Erstellt eine leere [[SDL_Surface]]. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_CreateRGBSurface'''(''flags'' : Uint32; ''width'', ''heigth'', ''depth'': Integer;
''RMask'', ''GMask'', ''BMask'', ''AMask'': Uint32): PSDL_Surface

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Zu setzende Flags
|-
! ''width, heigth''
| Grösse der Surface
|-
! ''depth''
| Anzahl der Bits pro Pixel (siehe [[SDL_Surface]])
|-
! ''RMask'', ''GMask'', ''BMask'', ''AMask''
| Benötigt für 24 und 32 Bit Surfaces.
| Beschreibt im welchen 'Teil' des Pixels sich z.b. Rot befindet.
|}

== Beschreibung ==
Erstellt eine leere [[SDL_Surface]] im Speicher (darf erst nach [[SDL_SetVideoMode]] aufgerufen werden).

== Hinweise ==
Wenn bitsPerPixel 8 ist, wird eine leere (Farb)Palette in [[SDL_PixelFormat]] benutzt, ansonsten wird ein 'packed-pixel' [[SDL_PixelFormat]] erstellt, da die [RGBA]Masken benutzt.
 
Wenn ein Alphakanal angeben ist (wenn Amask ungleich 0 ist), wird die '''SDL_SRCALPHA''' flag automatisch gesetzt.
Man kann sie mit Hilfe eines Aufrufes von [[SDL_SetAlpha]] nach der Surface-Erstellung entfernen.
 
Manchmal kann das Setzten der Alpha Maske komische Ergebnisse verursachen. Dies kann man umgehen indem man den Amask Parameter auf 0 setzt, aber die '''SDL_SRCALPHA''' flag setzt und danach [[SDL_SetAlpha]] mit dem '''SDL_SRCALPHA''' flag benutzt.

== Rückgabewert ==
'''SDL_CreateRGBSurface''' gibt '''nil''' zurück, wenn ein Fehler aufgetreten ist.

== Beispiel ==
<source lang="pascal">//Erstellen einer 32-Bit surface wie OpenGL sie für Texturen erwartet
var
surface: PSDL_Surface;
rmask, gmask, bmask, amask: Uint32;

//SDL interpretiert jeden Pixel als 32-Bit Wert.
//deshalb muss unsere Maske auf der Byte Ordnung des Computers basieren
if SDL_BYTEORDER = SDL_BIG_ENDIAN then
begin
rmask:=$ff000000;
gmask:=$00ff0000;
bmask:=$0000ff00;
amask:=$000000ff;
end
else
begin
rmask:=$000000ff;
gmask:=$0000ff00;
bmask:=$00ff0000;
amask:=$ff000000;
end;

surface:=SDL_CreateRGBSurface(SDL_SWSURFACE, width, height, 32,rmask, gmask, bmask, amask);
if (surface=nil) then
begin
writeln('CreateRGBSurface fehlgeschlagen');
exit;
end</source>

== Siehe auch ==
[[SDL_CreateRGBSurfaceFrom]], [[SDL_FreeSurface]], [[SDL_SetVideoMode]], [[SDL_LockSurface]], [[SDL_PixelFormat]], [[SDL_Surface]], [[SDL_SetAlpha]], [[SDL_SetColorKey]]

[[Kategorie:SDL|CreateRGBSurface]]

SDL Surface

2013-09-07T10:00:21Z

End: Hinweis auf deprecation.

= SDL_Surface =

== Name ==
'''SDL_Surface''' - Struktur der graphischen Oberfläche

== Delphi-Spezifikation ==
type
'''TSDL_Surface'''=record
''flags'' : Uint32; //nur Lesezugriff
''format'' : PSDL_Pixelformat; //nur Lesezugriff
''w'', ''h'' : Integer; //nur Lesezugriff
''pitch'' : Uint16; //nur Lesezugriff
''pixels'' : Pointer; //Lese- und Schreibzugriff
''clip_rect'' : SDL_Rect; //nur Lesezugriff
''refcount'' : Integer; //meistens nur Lesezugriff
end;

//es existieren weitere private Felder die nicht aufgeführt sind

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Gesetzte Flags
|-
! ''format''
| Pixelformat (siehe [[SDL_PixelFormat]])
|-
! ''w'', ''h''
| Breite und Höhe der Surface
|-
! ''pitch''
| Länge einer Surface-Scanline in Bytes
|-
! ''clip_rect''
| Surface Clipping Rechteck
|-
! ''refcount''
| Referenzzähler - wird beim Freigeben der Surface verwendet
|}

== Beschreibung ==
Eine '''SDL_Surface''' repräsentiert bis SDL-Version 2.0 eine Gebiet des 'graphischen' Speichers, Speicher in dem gezeichnet werden kann.

Ab Version 2.0 werden hierfür TSDL_Window und TSDL_Texture benutzt.

Der Video Framebuffer wird als '''SDL_Surface''' von [[SDL_SetVideoMode]] und [[SDL_GetVideoSurface]] zurückgegeben.

Die Felder ''w'' und ''h'' sind Werte die die Breite und Höhe der Surface in Pixeln wiedergeben.

Das Feld ''pixels'' ist ein Pointer auf die aktuelle Pixeldaten.
Siehe [[SDL_PixelFormat#Beispiel|SDL_PixelFormat]].

Das Feld ''clip_rect'' ist das clipping rectangle wie es in [[SDL_SetClipRect]] gesetzt wurde.

Das Feld ''flags'' unterstütz die folgenden per '''or''' verknüpften Werte:

{| border="1" rules="all"
!SDL_SWSURFACE
|Das Surface wird im Systemspeicher gespeichert
|-
!SDL_HWSURFACE
|Das Surface wird im Grafikspeicher gespeichert
|-
!SDL_ASYNCBLIT
|Das Surface benutzt asynchrone [[blit]]s, wenn möglich
|-
!SDL_ANYFORMAT
|Erlaub jegliche Pixelformate (Display Surface)
|-
!SDL_HWPALETTE
|Das Surface hat eine exklusive Palette
|-
!SDL_DOUBLEBUF
|Das Surface ist doublebuffered (Display Surface)
|-
!SDL_FULLSCREEN
|Das Surface nutzt eine Vollbildanzeige (Display Surface)
|-
!SDL_NOFRAME
|Das Fenster hat deine Titelleiste oder Framedekoration. Bei '''SDL_FULLSCREEN''' ist es automatisch gesetzt.
|-
!SDL_OPENGL
|Das Surface hat einen OpenGL-Kontext (Display Surface)
|-
!SDL_OPENGLBLIT
|Das Surface unterstützt OpenGL blitting (Display Surface). HINWEIS: Dieses Flag wird aus Kompatibilitätsgründen weitergeführt und wird nicht für neuen Quelltext empfohlen.
|-
!SDL_RESIZABLE
|Das Surface kann in seiner Größe verändert werden (Display Surface)
|-
!SDL_HWACCEL
|Das Surface blit benutzt Hardwarebeschleunigung
|-
!SDL_SRCCOLORKEY
|Surface benutzt colorkey blitting
|-
!SDL_RLEACCEL
|Colorkey blitting wird durch RLE beschleunigt
|-
!SDL_SRCALPHA
|Surface blit benutzt Alpha-Blending
|-
!SDL_PREALLOC
|Das Surface benutzt bereitgestellten Speicher
|}

== Hinweise ==
Um auf die Pixeldaten zuzugreifen kann es nötig sein die Surface zu sperren (siehe [[SDL_LockSurface]]).

''refcount'' gibt an wieviele Zeiger auf die Surface gesetzt wurden.
Wenn dieser Wert 1 ist, wird die Surface mit [[SDL_FreeSurface]] freigegeben, andernfalls nur der Wert erniedrigt.

'''SDL_RESIZABLE''': Unter Windows führt das Grössenverändern zum Verlust des OpenGL-Kontext.
 

== Siehe auch ==
[[SDL_PixelFormat]]

[[Kategorie:SDL|Surface]]

SDL CreateCursor

2013-09-07T09:58:10Z

End: Versionskennzeichnung.

= SDL_CreateCursor =

== Name ==
'''SDL_CreateCursor''' - Erstellt einen Pointer auf einen Cursor, der später verwendet werden kann. Ab Version 1.0.

== Delphi-Spezifikation ==
procedure '''SDL_CreateCursor'''(''data'', ''mask'' : PUInt8; ''w'', ''h'', ''hot_x'', ''hot_y'' : integer) : PSDL_Cursor

== Parameter ==

{| border="1" rules="all"
! ''data''
| Ein Pointer auf ein im Speicher befindliches Byte-Array, wo die Cursor-Daten gespeichert sind (siehe unten)
|-
! ''mask''
| Ein Pointer auf ein im Speicher befindliches Byte-Array, wo die Cursor-Daten gespeichert sind (siehe unten)
|-
! ''w''
| Die Breite des Cursors
|-
! ''h''
| Die Höhe des Cursors
|-
! ''hot_x'', ''hot_y''
| Der Klickpunkt des Cursors von oben-links (0,0)
|}

== Beschreibung ==
Der Befehl gibt einen Pointer auf einen Cursor zurück, der aus den Byte-Arrays erstellt wird.

Die Byte-Arrays werden bitweise interpretiert:
{| {{Prettytable_B1}}
! Databit
! Maskbit
! Pixelfarbe
|-
| 1
| 1
| Schwarz
|-
| 0
| 1
| Weiss
|-
| 0
| 0
| Transparent
|-
| 1
| 0
| Wenn möglich invertiert, ansonsten Schwarz
|}

== Hinweise ==
Der Cursor muss ein Vielfaches von 8 breit sein.

Ein Cursor, der mit dieser Methode erstellt wurde, muss mit [[SDL_FreeCursor]] wieder freigegeben werden.

== Rückgabewert ==
Der Pointer auf den Cursor oder {{INLINE_CODE|nil}} wenn ein Fehler aufgetreten ist.

== Siehe auch ==
[[SDL_FreeCursor]], [[SDL_SetCursor]], [[SDL_ShowCursor]]

[[Kategorie:SDL|CreateCursor]]

SDL ConvertSurface

2013-09-07T09:57:48Z

End: Versionskennzeichnung.

= SDL ConvertSurface =

== Name ==
'''SDL_ConvertSurface''' - Konvertiert eine Surface zum Format einer anderen [[SDL_Surface|Surface]]. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_ConvertSurface'''(''src'': PSDL_Surface; ''fmt'': PSDL_PixelFormat; ''flags'': UInt32): PSDL_Surface;

== Parameter ==

{| border="1" rules="all"
! ''src''
| Die Quell-Surface von der kopiert wird
|-
! ''fmt''
| Das Pixel-Format, in welches konvertiert werden soll
|-
! ''flags''
| Das flags-Parameter wird an [[SDL_CreateRGBSurface]] übergeben und hat auch die entsprechende Syntax
|}

== Beschreibung ==
Erzeugt eine neue Surface mit dem angegebenen Format (fmt) und kopiert und konvertiert die übergebene Surface (src) zu der neu erstellten. Schlägt die Funktion fehl, wird nil zurückgeliefert. Diese Funktion ist außerdem nützlich, um eine Surface zu kopieren.

Diese Funktion wird intern von [[SDL_DisplayFormat]] genutzt.

== Hinweise ==
Die Funktion kann nur nach [[SDL_Init]] aufgerufen werden.

== Rückgabewert ==
Zurückgeliefert wird eine neue Surface mit dem angegebenen Pixelformat (fmt), die den Inhalt der Quell-Surface enthält (src).

== Siehe auch ==
[[SDL_CreateRGBSurface]], [[SDL_DisplayFormat]], [[SDL_PixelFormat]], [[SDL_Surface]]

[[Kategorie:SDL|ConvertSurface]]

SDL BlitSurface

2013-09-07T09:57:25Z

End: Versionskennzeichnung.

= SDL_BlitSurface =

== Name ==
'''SDL_BlitSurface''' - Führt einen schnellen Kopiervorgang zwischen Surfaces durch. Ab Version 1.

== Delphi-Spezifikation ==
function '''SDL_BlitSurface'''(''src'' : PSDL_Surface; ''srcrect'' : PSDL_Rect;
''dst'' : PSDL_Surface; ''dstrect'' : PSDL_Rect) : integer

== Parameter ==

{| border="1" rules="all"
! ''src''
| Quellsurface, von der kopiert wird
|-
! ''srcrect''
| siehe unten
|-
! ''dst''
| Zielsurface, auf die kopiert wird
|-
! ''dstrect''
| siehe unten
|}

== Beschreibung ==
SDL_BlitSurface führt einen schnellen Kopiervorgang von der Quellsurface auf die Zielsurface. Dabei wird w und h von ''srcrect'' für die Höhe und Breite und x und y von ''dstrect'' für die obere rechte Ecke des Kopierbereichs verwendet.

Wenn ''srcrect'' gleich {{INLINE_CODE|nil}} ist, dann wird die komplette Quellsurface kopiert. Wenn ''dstrect'' gleich {{INLINE_CODE|nil}} ist, dann sind die Koordinaten (0,0), also die obere linke Ecke der Zielsurface.

Der endgültige Kopierbereich wird, nachdem jegliches Clipping durchgeführt wurde, in ''dstrect'' gespeichert. (''srcrect'' wird nicht verändert)

Das Ergebnis der Blit-Funktion variiert nach der SDL_SRCALPHA Option (Siehe [[SDL_SetAlpha]] für eine Erklärung der Beeinflussung)

== Hinweise ==
Bitte beachten, dass diese Funktion keine Streckung oder Stauchung durchführen kann.
Außerdem sollte sie (wie die meisten SDL-Surfacefunktionen) '''nicht''' zusammen mit OpenGL verwendet werden!

SDL_BlitSurface sollte nicht mit einem gelocktem Surface durchgeführt werden.

== Rückgabewert ==
Die Funktion gibt 0 zurück, wenn kein Fehler aufgetreten ist, ansonsten -1.

Wenn die Surface im Videospeicher liegt und die Funktion -2 zurückgibt, dann ist der Zugriff auf den Videospeicher verloren gegangen.

== Siehe auch ==
[[SDL_FillRect]], [[SDL_Rect]], [[SDL_SetAlpha]], [[SDL_SetColorKey]], [[SDL_Surface]]

[[Kategorie:SDL|BlitSurface]]

SDL GetError

2013-08-29T18:44:01Z

End: Kategorie hinzugefügt

= SDL_GetError =

== Name ==
'''SDL_GetError''' - Liefert einen String zurück der den letzten aufgetretenen Fehler näher beschreibt. Ab Version 1.0.

== Delphi-Spezifikation ==
function '''SDL_GetError''': PChar;

== Beschreibung ==
'''SDL_GetError''' liefert einen String zurück der den letzten aufgetretenen Fehler näher beschreibt. Besonders bei der Initalisierung sollte überprüft werden, ob angeforderte Ressourcen auch zur Verfügung stehen. Wird statt eines Ergebnisses ein NIL-Wert zurückgegeben, empfiehlt es sich mit '''SDL_GetError''' den aufgetretenen Fehler auszugeben. Dies erleichtert in der Praxis sehr häufig die Diagnose eines Problems.

== Beispiel ==
Wir versuchen künstlich einen Fehler hervorzurufen indem wir als gewünschte Bildschirmauflösung negative Werte angeben. Die daraus resultierende Ausgabe lautet: ''Invalid width or height''
<source lang="pascal">[...]
surface := SDL_SetVideoMode(-800, -600, -32, videoflags);
if not assigned(surface) then
begin
WriteLn(SDL_GetError);
Quit_App;
end;
[...]</source>

== Siehe auch ==
[[glGetError]]

[[Kategorie:SDL|SDL2|GetError]]

Tutorial glsl

2013-08-29T13:53:22Z

End: Ein paar Rechtschreibfehler korrigiert ;)

=Einleitung=
Hallo und willkommen bei meiner "Einführung" in GLSL (kurz für "Open'''GL''' '''S'''hading '''L'''anguage"), der offiziellen Hochlevel-Shadersprache von OpenGL. In diesem umfangreichen Dokument werde ich versuchen, sowohl auf die Nutzung (sprich das Laden und Anhängen von Shadern im Quellcode), als auch auf die Programmierung von Shadern selbst einzugehen, inklusive aller Sprachelemente der OpenGL Shadersprache. Es wird also auch recht viele Informationen zu der C-ähnlichen Programmstruktur und den von GLSL angebotenen Variablen und Attributen gehen. Am Ende dieser Einführung sollten alle die, die sich für das Thema interessieren, in der Lage sein, zumindest einfache Shader zu schreiben und auch in ihren Programmen zu nutzen. Außerdem soll dieses Dokument gleichzeitig als ein deutsches "Pendant" zu den von Khronoes veröffentlichten Shaderspezifikationen, und damit als alltägliches Nachschlagewerk, dienen.

==Vorkenntnisse==
Wie auch schon mein ARB_VP-Tutorial richtet sich auch diese Einführung aufgrund ihrer Thematik eher an die fortgeschritteneren GL-Programmierer und neben sehr guten GL-Kenntnissen sollten sich alle, die sich daran versuchen wollen, mit den technischen Hintergründen der GL, wie z.B. dem Aufbau der Renderpipeline auskennen. Weiterhin sind C-Kenntnisse absolut erforderlich, da die Shader ja in einer an ANSI-C angelehnten Syntax geschrieben werden. Auch Begriffsdefinitionen zu Vertex oder Fragment werden zum Verständis dieser Einführung benötigt. Wer also noch am Anfang seiner GL-Karriere steht, dem wird dieses Dokument nicht viel nützen. Ganz nebenbei solltet ihr auch noch eine gehörige Portion Zeit (am besten nen kompletten Nachmittag) mitbringen, denn die folgende Kost ist nicht nur umfangreich, sondern auch manchmal recht schwer verdaulich.

=Was ist GLSL?=
Wie Eingangs kurz angesprochen handelt es sich bei GLSL um eine Shadersprache, also um eine Hochsprache, in der man die programmierbaren Teile aktueller Grafikbeschleuniger nach eigenem Belieben programmieren kann. Sie stellt quasi den Nachfolger zu den in Assembler geschriebenen Vertex- und Fragmentprogrammen ([[GL_ARB_vertex_program]]/[[GL_ARB_fragment_program]]) dar und basiert auf ANSI C, erweitert um Vektor- und Matrixtypen sowie einige C++-Mechanismen.

Die in GLSL geschriebenen Programme nennen sich, angepasst an die Terminologie von RenderMan und DirectX, [[Shader]] (im Gegensatz zu "Programme" bei ARB_VP/FP) und werden entweder auf Eckpunkte (VertexShader), Fragmente (FragmentShader) angewendet, oder (neuerdings, ab Shadermodell 4.0) auch genutzt um Geometrie zu erstellen (Geometryshader). Andere Teile der Renderpipeline (z.B. die Rasterisierung) können momentan noch nicht durch Shader beeinflusst werden, was allerdings in Zukunft noch kommen kann.

==Voraussetzungen==

GLSL wurde 2005 mit OpenGL 1.5 eingeführt. Während es in Sachen Treiber- und Hardwareunterstützung anfänglich noch dürftig aussah, wird man inzwischen keine Grafikkarte mehr kaufen können die nicht zumindest Vertex- und Fragmentshader beherscht. Geometrieshader hingegen sind relativ neu und wurden erst mit Shadermodell 4.0 eingeführt, hier ist es also unter Umständen noch möglich dass selbst aktuelle Treiber/Karten keine Geometryshader beherrschen.

Natürlich benötigt man auch einen passenden OpenGL-Header der die für GLSL nötigen Funktionen exportiert. Ich verweise dazu auf unseren eigenen OpenGL-Header [[DGLOpenGL.pas]], der permanent auf dem aktuellsten Stand gehalten wird und auch Support für Geometrieshader mitbringt.

==Extensions==

Die GL-Shadersprache "besteht" in ihrer aktuellen Version aus folgenden Extensions, fürs Verständnis wäre es nicht schlecht, wenn ihr euch zumindest die Einleitungen dazu durchlest :
* [[GL_ARB_shader_objects]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shader_objects.txt Originalspezifikation])
: Definiert die API-Aufrufe, die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.
* [[GL_ARB_vertex_shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt Originalspezifikation])
: Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.
* [[GL_ARB_fragment_shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt Originalspezifikation])
: Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.
* [[GL_ARB_shading_language_100]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shading_language_100.txt Originalspezifikation])
: Gibt die unterstützte Version von glSlang an, momentan 1.00.

'''Hinweis''' : Seit OpenGL 2.0 ist GLSL Teil des Kerns. Wenn die Karte also OpenGL 2.0 unterstützt, dann unterstützt sie auch (zumindest in Software) Vertex- und Fragmentshader.

==Sprachversionen==

Neben der OpenGL-Version und dem vorhandenen Shadermodell (das eher an DirectX ausgerichtet ist), bietet auch GLSL verschiedene Versionen, die entsprechend erweiterte Funktionalität bieten.

Auslesen kann man die verfürgbare GLSL-Version wie folgt:

glGetString(GL_SHADING_LANGUAGE_VERSION)

Erst ab Version 1.4. kann man davon ausgehen dass GLSL alle Features des Shadermodells 4.0 liefert, ab 1.3 grob gesagt Shadermodell 3.0 (bei GLSL lässt sich das leider nicht so leicht unterteilen).

Außerdem kann man seinem Shader eine Versionsnummer verpassen. Sollte der Shadercompiler (also Treiber bzw. Hardware) diese Version nicht unterstützen, gibt dieser eine Fehlermeldung heraus:

#version 1.50

''(Hinweis: Muss am Anfang des Shaders stehen)''

==Objekte==

Im Zuge der Vereinheitlichung der GL wird immer häufiger in Objekte gekapselt, deren API dann auch aneinander angelehnt ist. Ziel ist, dabei die Programmierung der GL uniform zu machen, so dass z.B. zwischen dem Erstellen und Verwalten eines Vertex-Buffer-Objektes oder eines Shader-Objektes kaum ein Unterschied besteht (demnächst kommen dann auch Pixel-Buffer-Objekte dazu). Mit glSlang wurden dann im Zuge dieser Aktion zwei neue Objekte eingeführt, deren Definition ihr euch unbedingt einprägen solltet:

* '''Programmobjekt'''
:Ein Objekt, an das die Shader später angebunden werden. Bietet Funktionalität zum Linken der Shader und prüft dabei die Kompatibilität zwischen Vertex- und Fragmentshader.

* '''Shaderobjekt'''
:Dieses Objekt verwaltet den Quellcodestring eines Shaders und ist entweder vom Typ '''GL_VERTEX_SHADER''', '''GL_FRAGMENT_SHADER_ARB''' oder '''GL_GEOMETRY_SHADER'''.

==Ressourcen==

Die Shadersprache ist keinesfalls final und es wurden bereits diverse Ausdrücke für zukünftige Verwendung reserviert, denn ein Ziel bei ihrer Entwicklung war es, sie so zukunftsorientiert zu gestalten, dass auch Grafikkarten der nächsten und übernächsten Generation voll ausgenutzt werden können. Damit einher geht die Tatsache, dass sich die Spezifikationen in Zukunft ändern/erweitern werden, weshalb man da immer einen Blick hineinwerfen sollte. Die Anlaufstelle dafür ist die [http://www.opengl.org/documentation/specs/ Spezifikationenliste auf OpenGL.org].

=GLSL im Programm=
Bevor wir uns mit der Syntax von glSlang beschäftigen, zeige ich euch erstmal, wie ihr Shader in euer Programm einbindet und nutzt. Warum das zuerst? Ganz einfach deshalb, weil ihr dann das, was ihr im glSlang-Syntaxteil lernt, direkt in eurer Testanwendung verwenden könnt. Hoffe diese Entscheidung klingt logisch und findet Anklang.

Zuerst benötigen wir natürlich unsere Objekte. Zum einen ein ''Programmobjekt'', an das unsere Shader gebunden werden, und zwei ''Shaderobjekte'', die den Quellcode unseres Vertex bzw. Fragment Shaders aufnehmen. Dazu wurde eigens der neue "Datentyp" {{INLINE_CODE|glHandle}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandle;
VertexShaderObject : GLhandle;
FragmentShaderObject : GLhandle;

Nach dieser Deklaration können wir dann damit beginnen unsere Objekte zu erstellen. Den Anfang macht das Programmobjekt :

ProgramObject := glCreateProgram;

Die Funktion [[glCreateProgram]] erstellt uns oben ein leeres Programmobjekt und gibt ein gültiges Handle darauf zurück.

Weiter gehts mit der Erstellung unseres Vertex bzw. Fragment Shaders :

VertexShaderObject := glCreateShader(GL_VERTEX_SHADER);
FragmentShaderObject := glCreateShader(GL_FRAGMENT_SHADER);

[[glCreateShader]] dient zur Generierung eines leeren Shaderobjektes. Momentan unterstützt diese Funktion VertexShader und FragmentShader.

Nachdem wir nun also zwei gültige Shaderobjekte haben, wollen wir diese auch mit entsprechendem Quellcode versorgen :

glShaderSource(VertexShaderObject, 1, @ShaderText, @ShaderLength);
glShaderSource(FragmentShaderObject, 1, @ShaderText, @ShaderLength);

Via [[glShaderSource]] setzen wir den Quellcode eines Shaderobjektes ''komplett'' neu. Zum Laden des Quellcodes bietet sich unter Delphi übrigens eine TStringList geradezu an. Es sollte beachtet werden, dass der Quellcode zu diesem Zeitpunkt ''nicht geparst'' wird, also keine Fehleruntersuchung stattfindet.

Der Quellcode wurde jetzt also an unsere Shaderobjekte gebunden und sollte dann natürlich auch noch kompiliert werden :

glCompileShader(VertexShaderObject);
glCompileShader(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShader]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der Shadercompiler (je nach Treiber) recht detaillierte Infos aus. Wie man an diese Infos kommt könnt ihr gleich nachlesen.

Wenn unsere Shader dann kompiliert werden konnten, ist es Zeit, diese an unser anfangs erstelltes Programmobjekt anzuhängen :

glAttachShader(ProgramObject, VertexShaderObject);
glAttachShader(ProgramObject, FragmentShaderObject);

Nachdem die Shaderobjekte nun an das Programmobjekt angehängt wurden, werden diese nicht mehr benötigt und ihre Resourcen können freigegeben werden :

glDeleteShader(VertexShaderObject);
glDeleteShader(FragmentShaderObject);

Am Schluß müssen wir dann noch unsere ans Programmobjekt gebundenen Shader linken :

glLinkProgram(ProgramObject);

Während [[glCompileShader]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgram]] die angehangenen Shader zu einem ausführbaren Shader gelinkt. Folgende Bedingungen führen zu einem '''Linkerfehler''':

* Die Zahl der von der Implementation unterstützten Attributvariablen wurde überschritten
* Der Speicherplatz für Uniformvariablen wurde überschritten
* Die Zahl der von der Implementation angebotenen Sampler wurde überschritten
* Die main-Funktion fehlt
* Die Liste der Varying-Variablen des Vertexshaders stimmt nicht mit der des Fragmentshaders überein
* Funktions- oder Variablenname nicht gefunden
* Eine gemeinsame Globale ist mit unterschiedlichen Werten oder Typen initialisiert worden
* Zwei Sampler unterschiedlichen Typs zeigen auf die selbe Textureneinheit
* Ein oder mehrere angehangene(r) Shader wurden nicht erfolgreich kompiliert

Die Nutzung von glSlang im eigenen Programm ist wie oben erkennbar also nicht wirklich schwer und innerhalb kurzer Zeit realisiert. Natürlich ist es auch möglich z.B. nur einen VertexShader oder nur einen FragmentShader an ein Programmobjekt zu binden.

Noch eine kleine Notiz zum Löschen der Shader mittel [[glDeleteShader]] : Da Shader(objekte) einen Referenzzähler besitzen und erst gelöscht werden wenn diese nirgendwo mehr benötigt werden, ist es nicht falsch diese vor dem Linkvorgang zu löschen. Allerdings spielt es letztendlich keine Rolle ob die Löschanweisung vorher der nachher ausgeführt wird.

==Fehlererkennung==
Natürlich wird es ohne Fehlerausgabe recht schwer, etwaige Probleme in einem Vertex- oder Fragmentshader zu finden. Doch auch in diesem Bereich wurde glSlang recht gut durchdacht und es wurden zwei Funktionen eingeführt, welche im Zusammenspiel die Fehlersuche recht einfach machen, nämlich [[glGetShaderInfoLog]] und [[glGetShader]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH}}. Erstere Funktion liefert uns einen Logstring, während uns letztere Funktion dessen Länge angibt. Der Logstring wird verändert, sobald ein Shader kompiliert oder ein Programm gelinkt wird.

Um die Ausgabe dieses Logs so einfach wie möglich zu machen, bietet es sich an beide in einer einfach Funktion unterzubringen :

<source lang="pascal">function glSlang_GetInfoLog(pShader: GLHandleARB): String;
var
blen, slen: GLInt;
InfoLog: PGLCharARB;

begin
glGetShaderiv(pShader, GL_INFO_LOG_LENGTH , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen * SizeOf(GLCharARB));
glGetShaderInfoLog(pShader, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</source>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetShaderiv}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetShaderInfoLog}} in {{INLINE_CODE|InfoLog}} ausgeben und liefern diesen als Ergebnis zurück.

Wie bereits gesagt wird nur nach dem Kompilieren eines Shaders bzw. dem Linken eines Programmobjektes ein Infolog erstellt. Es bietet sich dadurch an, direkt danach einen solchen Aufruf zu machen :

glCompileShader(VertexShaderObject);
ShowMessage(glSlang_GetInfoLog(VertexShaderObject));

Wenn unser Vertex Shader komplett fehlerfrei kompiliert werden konnte, dann sehen wir als Ergebnis nur einen leeren Dialog. Ist dies nicht der Fall, so werden wir vom Treiber mit recht detaillierten Fehlerinformationen "belohnt", z.B. so :

[[Bild:GLSL_error_vshader.jpg]]

Auch das Infolog nach dem Linken des Programmobjektes dürfte, selbst wenn keine Fehler vorkommen, recht interessant sein, das sieht dann nämlich so aus :

[[Bild:GLSL info programobject.jpg]]

Wie zu sehen, wird uns nach dem erfolgreichen Linken auch gesagt, ob und welcher Shader in Hardware bzw. Software läuft. Für Debuggingzwecke sicherlich eine mehr als brauchbare Information.

==Shader benutzen==
Um den Shader auch für die nächsten Polygone zu benutzen oder Uniformparameter übergeben zu können, ruft man die Funktion
glUseProgram(ProgramObject);
um alle Shader zu deaktivieren, ruft man dieselbe Funktion mit dem Parameter 0.

==Parameterübergabe==
Uniformparameter (mehr dazu später) stellen die Schnittstelle zwischen eurem Programm und dem Shader dar, werden also genutzt um Daten aus dem Programm heraus an einen Shader zu übergeben. Zur Übergabe dieser Parameter bietet OpenGL diverse Funktionen, die alle Abkömmlinge von [[glUniform]] sind. Während mit {{INLINE_CODE|glUniform4f}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fv}} ganze Matrizen schnell und einfach übergeben. Außerdem gibt es nun die Möglichkeit Uniformparameter direkt über ihren Namen, statt wie unter ARB_FP/VP über einen festen Index zu adressieren. Die Funktion [[glGetUniformLocationARB]] gibt anhand des übergebenen Parameternamens dessen Position zurück. Man kann also ganz einfach über den Namen drauf zugreifen :

glUniform3f(glGetUniformLocation(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1i(glGetUniformLocation(ProgramObject, PGLCharARB('texSamplerTMU3')), 3);

Wichtig ist hier, das man je nach Parametertyp auch die passende Anzahl von Argumenten übergibt. Also für einen 4-Komponenten Floatvektor {{INLINE_CODE|glUniform4fARB}} und für einen einfachen Integerwert (z.B. Textureinheit für einen Sampler) glUnifrom1iARB. Auch nicht vergessen dürft ihr, das die Namen der Parameter genauso wie im Shader geschrieben werden müssen, also Groß- und Kleinschreibung beachtet werden muß.

=Die Shadersprache=

Nachdem wir uns mit der Einbindung der glSlang-Shader in unser Programm beschäftigt haben, wollen wir uns in den folgenden Kapiteln um die Sprachelemente von glSlang kümmern. Wie schon gesagt basiert glSlang auf ANSI-C, wurde allerdings um speziell auf den Zielbereich angepasste Vektor- und Matrixtypen und einige C++-Features wie das freie deklarieren von Variablen an jeder Stelle und das Funktionsüberladen auf Basis des Argumenttyps erweitert. Wer sich ein wenig mit C/C++ auskennt sollte also in der nun folgenden Materie keine Probleme bekommen.

'''Obligatorische Hinweise für verwöhnte Delphi-Nutzer : '''
*Wie von C/C++ her gewohnt, spielt auch in glSlang die Groß- und Kleinschreibung eine wichtige Rolle, also bitte achtet darauf. gl_Position ist eine komplett andere Variable als z.B. gl_position.
*Es findet keine automatische Typenkonvertierung statt. Das bedeutet also das float MyFloat = 1 ungültig ist und es in dem Falle float MyFloat = 1.0 heissen muss. Typecasts müssen also immer manuell stattfinden, z.B. MyFloat = float(MyInt).

'''Kleine Programmstrukturkunde für C-Unkundige :''' 
Da sicherlich einige Delpher nie richtig was mit C gemacht haben, zeige ich mal anhand eines kleinen Beispieles (das auf keinen Fall nen brauchbaren Shader darstellt) den grundlegenden Aufbau eines glSlang-Shaders, der natürlich dem Aufbau eines C-Programmes stark ähnelt :
<source lang="glsl">
uniform vec4 VariableA;
float VariableB;
vec3 VariableC;
const float KonstanteA = 256.0;

float MyFunction(vec4 ArgumentA)
{
float FunktionsVariableA = float(5.0);

return float(ArgumentA * (FunktionsVariableA + KonstanteA));
}

// Ich bin ein Kommentar
/* Und ich auch */
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Sieht doch recht bekannt aus, unser Programmaufbau. Delphi und C haben ja so einige Grundlagen gleich, darunter auch der ungefähre Programmaufbau. Ausserhalb jeglicher Funktionen legen wir am Programmanfang unsere Variablen, Konstanten und Attribute fest, die dann ''global'' nutzbar sind, also in jeder Funktion.

Darunter deklarieren wir dann eine kleine Funktion. Wie auch bei den Variablendeklarationen wird hier der Rückgabetyp nicht wie bei Pascal nach dem Funktionsnamen untergebracht, sondern davor. Innerhalb der Funktion können dann wieder Variablen deklariert werden, die dann allerdings ''lokal'', also nur in dieser Funktion nutzbar sind. Vorteil dieser Deklaration ist die Tatsache, dass je nach Grafikkarte nur bestimmt viele globale Variablen deklariert werden können. Wenn möglich sollte man also mit lokalen Vorlieb nehmen. Unsere Funktion gibt dann natürlich noch via return einen Wert zurück, ''was gemacht werden muss'', sofern man diese nicht als void deklariert hat (entspräche dann einer Prozedur in Pascal). Wird dies nicht getan, so spuckt der Compiler einen Fehler aus.

Auch wichtig sind natürlich Kommentare. Erste Variante (Doppelslash) ist auch in der Pascalwelt verfügbar und kommentiert eine einzelne Zeile aus. Die Variante darunter kann man für Kommentarblöcke nutzen (/* .. */) und entspricht den Kommentaren in geschweiften Klammern in Delphi.

Danach kommt dann die '''wichtigste Funktion''' des Shaders, nämlich '''main''', die in keinem Shader fehlen darf. Sie stellt quasi den Programmkörper dar und ist oft auch die einzige Funktion in einem Shader. Sie erhält weder ein Argument, noch gibt sie einen Wert zurück.

Soviel also zum grundlegenden Aufbau eines Shader. Hoffe das jetzt alle die in C nicht so bewandert sind damit klar kommen, und dann bald ihre ersten glSlang-Shader schreiben können.

==Datentypen==

Obwohl einige Datentypen aus C übernommen wurden, sieht man der Typenliste an, das diese speziell auf den 3D-Bereich zugeschnitten wurde. Variablen müssen vor ihrer Nutzung eindeutig deklariert sein, Typecasting erfolgt über Konstruktoren (dazu später mehr). Folgende Datentypen stehen sowohl im Vertex- als auch Fragmentshader zur Verfügung :

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|void
|Für Funktionen die keinen Wert zurückgeben
|-
|bool
|Konditionaler Typ, entweder true (wahr) oder false (falsch)
|-
|int
|Vorzeichenbehafteter vorzeichenbehafteter Integerwert
|-
|uint
|Vorzeichenbehafteter vorzeichenloser Integerwert
|-
|float
|Fließkommaskalar mit Singlegenauigkeit (32 Bit)
|-
|vec2
|2-Komponenten Fließkommavektor
|-
|vec3
|3-Komponenten Fließkommavektor
|-
|vec4
|4-Komponenten Fließkommavektor
|-
|bvec2
|2-Komponenten Booleanvektor
|-
|bvec3
|3-Komponenten Booleanvektor
|-
|bvec4
|4-Komponenten Booleanvektor
|-
|ivec2
|2-Komponenten vorzeichenbehafteter Integervektor
|-
|ivec3
|3-Komponenten vorzeichenbehafteter Integervektor
|-
|ivec4
|4-Komponenten vorzeichenbehafteter Integervektor
|-
|uvec2
|2-Komponenten vorzeichenloser Integervektor
|-
|uvec3
|3-Komponenten vorzeichenloser Integervektor
|-
|uvec4
|4-Komponenten vorzeichenloser Integervektor
|-
|mat2
|2x2 Fließkommamatrix
|-
|mat3
|3x3 Fließkommamatrix
|-
|mat4
|4x4 Fließkommamatrix
|-
|matMxN
|Matrix mit M Spalten und N Zeilen
|}

Die sampler-Typen stellen eine besondere Klasse zum Zugriff auf Texturen dar, und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler2DRect
|Zugriff auf Texturen die nicht 2^n * 2^n entsprechen ("non power-of-two", NPOT)
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|samplerCubeShadow
|Zugriff auf Tiefentextur in einer Cubemap (z.b. für omni-diretionale Lichtquellen)
|-
|sampler2DRectShadow
|Zugriff auf 2D-NPOT-Tiefentextur
|-

|sampler1DArray
|Zugriff auf ein array aus 1D-Texturen
|-
|sampler2DArray
|Zugriff auf ein array aus 2D-Texturen
|-
|sampler1DArrayShadow
|Zugriff auf ein array aus 1D-Tiefentexturen
|-
|sampler2DArrayShadow
|Zugriff auf ein array aus 2D-Tiefentexturen
|-
|samplerBuffer
|Zugriff auf eine Puffertextur (1D-Texutr zum Speichern von Pufferobjekten)
|-
|sampler2DMS
|Zugriff auf eine 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|sampler2DMSArray
|Zugriff auf einarray aus 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|}

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<source lang="glsl">
float temp[3];
</source>
beginnt also bei Index 0 und endet bei Index 2. Im Gegensatz zu C lassen sich Arrays in glSlang allerdings ''nicht bei der Initialisierung vorbelegen''. Wenn ein Array als Parameter einer Funktion deklariert wird, so darf dieses keine Dimensionierung erhalten.

===Strukturen===

Neu ggü. ARB_FP/VP ist nun auch die Möglichkeit, Strukturen in einem Shader zu deklarieren. Vor allem die Übersicht komplexerer Shader kann dadurch stark verbessert werden. Strukturen werden wie gewohnt mit dem Schlüsselwort {{INLINE_CODE|struct}} eingeleitet und können dann zur Typisierung von Variablen genutzt werden. Folgendes Beispiel dürfte die Nutzung verdeutlichen :
<source lang="glsl">
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</source>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<source lang="glsl">
light LightSource[3];
</source>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<source lang="glsl">
LightSource[i].position = vec3(1.0, 1.0, 5.0);
</source>

==Typenqualifzierer==

Zusätzlich zur Typendeklaration kann eine Variable noch einen Typenqualifizerer vorangestellt bekommen, der an den Anfang der Deklaration gehört.

* '''const'''
: Festgelegte (nur lesen) Konstante bzw. nur lesbarer Funktionsparameter.

* '''uniform'''
: Ein den ganzen Shader über gleichbleibender Wert, der eine Schnittstelle zwischen dem Shader und der OpenGL-Anwendung darstellt. Ein Uniformwert wird in der Hauptanwendung an den entsprechenden Shader übergeben und kann dort dann genutzt werden.

* '''attribute'''
: Nur lesbare Werte die eine Verbindung zwischen dem Shader und der OpenGL-VertexAPI darstellen (z.B. VertexParameter eines VertexArrays). Natürlich nur in einem Vertex Shader nutzbar.

* '''varying'''
: Stellt die Verbindung zwischen einem Vertex- und einem FragmentShader dar. Werden im VertexShader geschrieben und dann perspektivisch korrekt über die Primitive interpoliert, um dann im Fragment Shader gelesen werden zu können. Nutzbar sind hier nur die Typen float, vec2, vec3, vec4, mat2, mat3 und mat4, Strukturen und andere Datentypen können nicht varying sein. Die Namen einer varying-Variable müssen sowohl im VertexShader als auch im FragmentShader gleich sein.

* '''in'''
: Für Variablen die an eine Funktion übergeben und dort ausgelesen werden.

* '''out'''
: Für Variablen die von einer Funktion nach außen zurückgegeben werden.

* '''inout'''
: Für Variablen die sowohl an eine Funktion übergeben als auch von dieser zurückgegeben werden.

Um obige Auflistung nicht leer im Raum stehen zu lassen zeige ich ein paar Beispiele die hoffentlich zum Verständnis beitragen :

===Beispiel A===
Vertexnormale soll an einen FragmenShader (interpoliert) übergeben werden :

:Im VertexShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</source>
:Im FragmentShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</source>

===Beispiel B===
Uniformparameter zur nachträglichen Farbänderung der Szene wird im Programm übergeben :

:Im VertexShader :
<source lang="glsl">
uniform vec4 GlobalColor;
...
gl_FrontColor = GlobalColor * gl_Color;
</source>
:Im Programm :

glUniform4fARB(glSlang_GetUniLoc(ProgramObject, 'GlobalColor'), Col[0], Col[1], Col[2], Col[3]);

===Beispiel C===
Konstante zur festen Farbänderung :

:Im VertexShader :
<source lang="glsl">
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</source>
==Konstruktoren==

Um in einem Shader ''Vektoren'' oder ''Matrizen'' mit Werten zu belegen, gibt es sogenannte Konstruktoren (nicht zu verwechseln mit z.B. Klassenkonstruktoren unter Delphi), die im Endeffekt nichts anderes als Funktionen zur Vorbelegung von Vektoren oder Matrizen darstellen. Dabei trägt der Konstruktor den selben Namen wie die Typendeklaration, also lässt sich eine Variable vom Typ {{INLINE_CODE|vec4}} mit dem Konstruktor {{INLINE_CODE|vec4(float, float, float, float)}} initialisieren.

Allerdings hat man sich recht viel Mühe bei dieser Konstruktorgeschichte gemacht, so dass man einen vec4 nicht unbedingt mit einem {{INLINE_CODE|vec4}}-Konstruktor vorbelegen muss, sondern es vielseitige Möglichkeiten gibt. Um dies zu verdeutlichen gibts ein paar Beispiele :
<source lang="glsl">
vec4 Color = vec4(1.0, 0.0, 0.0, 0.0);
vec4 Color = vec4(MyVec3, 1.0);
vec4 Color = vec4(MyVec2_A, MyVec2_B);

vec3 LVec = vec3(MyVec4);
vec2 Tmp = vec2(MyVec3);
</source>

Trotz der recht wenigen Beispiele sollte schnell erkennbar sein, das man hier wirklich sehr viele Kombinationsmöglichkeiten hat, die dann gültig sind ''wenn man mindestens auf die benötigte Anzahl der Argumente kommt''. Im vorletzten Beispiel wird z.B. ein 3-Komponentenvektor aus einem 4-Komponentenvektor initialisiert. Das erzeugt keinen Fehler, sondern führt dazu das {{INLINE_CODE|vec3.x, vec3.y, vec3.z}} aus MyVec4 übernommen werden und MyVec4.w einfach ignoriert wird.

Das Umkehrbeispiel, also
<source lang="glsl">
vec4 Color = vec4(MyVec3)
</source>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<source lang="glsl">
vec4 Color = vec4(MyVec3, 0.0)
</source>
heissen.

Obiges gilt natürlich auch für ''Matrixkonstruktoren'', hier sind z.B. folgende Konstuktoren denkbar, obwohl eigentlich alle Möglichkeiten nutzbar sind, ''solange die benötigte Zahl an Argumenten erreicht wird'' :
<source lang="glsl">
mat4 MyMatrix = mat4(MyVec4, MyVec4, MyVec4, MyVec4);
mat2 MyMatrix = mat4(1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
0.0, 0.0, 0.0, 1.0);
</source>

==Vektor- und Matrixkomponenten==

Was natürlich in keiner Shadersprache fehlen darf, ist der leichte Zugriff auf die einzelnen Komponenten eines Vektors. glSlang bietet, je nach Anwendungsgebiet gleich drei Namensets für den Zugriff auf die Komponenten eines solchen Vektors, welches Set man nutzen will bleibt natürlich frei und ist unabhängig von der Deklaration eines Vektors. Man sollte nur darauf achten, beim gleichzeitigen Zugriff auf mehrere Komponenten im gleichen Namenset zu verbleiben :

* {x, y, z, w}
:Für den Zugriff auf Vektoren die Punkte, Normale oder sonstige Vertexdaten repräsentieren.

* {r, g, b, a}
:Für den Zugriff auf Vektoren die Farbwerte repräsentieren.

* {s, t, p, q}
:Für den Zugriff auf Vektoren die Texturkoordinaten repräsentieren.

Ein paar Beispiele zur Unterstreichung des oben gesagten :
<source lang="glsl">
v4.rgba = vec4(1.0, 0.0, 0.0, 0.0); // gültig
v4.rgzw = vec4(1.0, 1.0, 1.0, 2.0); // Ungültig, da verschiedenen Namensets
v2.rgb = vec3(1.0, 2.0, 1.0); // Ungültig, da vec2 nur r+g besitzt
v2.xx = vec2(5.0, 3.0); // Ungültig, da 2 mal gleiche Komponente
</source>

Auch der Zugriff auf die Komponenten einer Matrix geht leicht von der Hand. Namensets wie bei den Vektoren gibt es hier natürlich keine, aber folgende Beispiele sollen den Zugriff aufzeigen :
<source lang="glsl">
MyMat4[2] = vec4(1.0); // Setzt die 3.Zeile der Matrix komplett auf 1.0
MyMat4[3][3] = 3.5; // Setzt das Element unren rechts auf 3.5
</source>

Ein Zugriff auf Matrixelemente ausserhalb ihrer Dimension (also z.B. MyMat4[4][4]) liefert unvorhersehabre Ergebnise, also sollte man auf diese Fälle prüfen.

==Vektor- und Matrixoperationen==

Wie von C gewohnt sind in glSlang so ziemlich alle Operatoren die man auf Matrizen oder Vektoren anwenden kann überladen, so das man nicht umständlich über selbstgeschriebene Funktionen kombinieren muss. Darüber hinaus ist es in den meisten Fällen auch möglich ohne Konvertierung Fließkommawerte mit kompletten Matrizen oder Vektoren zu kombinieren. Folgende Beispiele zeigen einige der vielfältigen Kombinationsmöglichkeiten auf :
<source lang="glsl">
vec3 dest;
vec3 source;
float factor;

vec3 dest = source + factor;

// Ist gleich
dest.x = source.x + factor;
dest.y = source.y + factor;
dest.z = source.z + factor;
</source>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<source lang="glsl">
vec3 dest;
vec3 source;
mat3 MyMat;

dest = source * MyMat;

// Ist gleich
dest.x = dot(source, MyMat[0]);
dest.y = dot(source, MyMat[1]);
dest.z = dot(source, MyMat[2]);
</source>

Auch hier sind die Möglichkeiten fast unbeschränkt und zeigen wieder wie flexibel glSlang ausgelegt ist.

==Operatoren==

glSlang bietet (momentan) folgende Operatoren, die Liste ist nach ihrer Gewichtung sortiert (Anfang = höchste). Alle ''reservierten'' Operatoren werden erst in kommender Hardware/glSlang-Versionen nutzbar sein :

<div align="center">
{|{{Prettytable_B1}}
!Operatorklasse
!Operatoren
!Assoziation
|-
|Gruppering
|()
| -
|-
|Arrayindizierung Funktionsaufrufe und Konstruktoren Strukturfeldwahl und Swizzle Postinkrement und -dekrement 
|[] () . ++ --
|Links n. Rechts
|-
|Prefixinkrement- und dekrement Einheitlich (~ reserviert)
| ++ -- + - ~ !
|Rechts n. Links
|-
|Mulitplikation (% reserviert)
|* / %
|Links n. Rechts
|-
|Additiv
| + -
|Links n. Rechts
|-
|Bitweises Verschieben (reserviert)
|<< >>
|Links n. Rechts
|-
|Relation
|< > <= >=
|Links n. Rechts
|-
|Vergleich
|== !=
|Links n. Rechts
|-
|Bitweises AND (reserviert)
|&
|Links n. Rechts
|-
|Bitweises XOR (reserviert)
|^
|Links n. Rechts
|-
|Bitweises OR (reserviert)
| <nowiki>|</nowiki>
|Links n. Rechts
|-
|Logisches AND
|&&
|Links n. Rechts
|-
|Logisches XOR
|^^
|Links n. Rechts
|-
|Logisches OR
| <nowiki>||</nowiki>
|Links n. Rechts
|-
|Auswahl
|?:
|Rechts n. Links
|-
|Zuweisung Arithmetrische Zuweisung (Modulis, Shift und bitweise Op. reserviert)
|<nowiki>=</nowiki> <nowiki>+= -= *= /= %=</nowiki> <nowiki><<= >>= &= ^= |=</nowiki>
|Rechts n. Links
|-
|Aufzählung
|,
|Links n. Rechts
|-
|}
</div>

==Funktionen==

Ein großer Vorteil von Hochsprachen ist u.A. die Möglichkeit oft genutzte Codeteile in Funktionen (bzw. auch Prozeduren unter Pascal) zu verpacken um so Flexibilität als auch Übersichtlichkeit zu steigern. Wer schonmal was in C geschrieben hat, der wird sich jetzt sicherlich kein Kopfzerbrechen machen müssen. Funktionen werden in glSlang genauso nach folgendem Prinzip deklariert :
<source lang="glsl">
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</source>

Funktionen die ''nichts zurückgeben'' müssen mit dem RückgabeTyp {{INLINE_CODE|void}} deklariert werden, außerdem entfällt dann logischerweise das {{INLINE_CODE|return}}. Falls die Funktion eines ihrere Argumente nach außen übergeben soll, muss dieses Argument mit dem Typenqualifizierer out (Siehe Kapitel 4.2) versehen werden. ''Arrays'' können nur als Eingabeargumente übergeben werden und dürfen nich dimensioniert als Argument verwendet werden, sondern müssen mit leeren Klammern argumentiert werden.
Ein paar Beispiele :
<source lang="glsl">
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</source>

Diese Funktion gibt ''nichts'' zurück, aber gibt EingabeWert*MyConstValue im Ausgabeargument AusgabeWert nach außen.
<source lang="glsl">
float MeineFunktion(float EingabeWert)
{
return EingabeWert*MyConstValue;
}
</source>

Bietet genau die selbe Funktionalität wie das Beispiel darüber. Allerdings wird hier der berechnete Wert als Ergebnis der Funktion zurückgeliefert.
<source lang="glsl">
float VektorSumme(float v[])
{
return v[0]+v[1]+v[2]+v[3];
}
</source>

Wie bereits gesagt darf ein Array als Argument keine Dimensionierung enthalten. Wenn man der Funktion also ein Array übergibt, sollte man vorher drauf achten das es entsprechend der in der Funktion genutzten Indizes dimensioniert wurde.

==if-Anweisung==

Selektion über eine if-Anweisung darf auch in keiner Hochsprache fehlen. Genauso wie in C oder Delphi erwartet auch hier die If-Anweisung einen boolschen Ausdruck (Wahr oder Falsch) und wird dann ausgeführt (wahr) bzw. verzweigt auf ein (wenn vorhanden) else (falsch). Verschachtelung ist wie erwartet auch möglich.

'''Hinweis : '''
Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten im Fragmentshader kein Early-Out, was zur Folge hat das bei einer If-Anweisung immer alle Zweige ausgeführt werden. Am Ende wird dann aber nur ein Ergebnis geschrieben, die anderen verworfen. Auf solchen Karten bringen If-Anweisungen also im Normalfall keine Geschwindigkeitssteigerung, sondern oft eher das Gegenteil.
Neuere SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall, da hier dynamische Verzweigungen und auch Early-Out von der Hardware implementiert werden.

==Schleifen==

Auch Schleifen, ein wichtiges Konzept jeder Hochsprache haben ihren Weg in glSlang gefunden. Unterstützt werden folgende Schleifentypen :

* '''for'''-Schleife
<source lang="glsl">
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck)
{
statement
}
</source>

* '''while'''-Schleife
<source lang="glsl">
while (Durchlaufbedingung)
{
statement
}
</source>

* '''do'''-while-Schleife
<source lang="glsl">
do
{
statement
}
while (Durchlaufbedingung)
</source>

'''Hinweis :''' Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten Schleifen nicht in Hardware. Schleifen werden dann beim Kompilieren vom Treiber entrollt, wodurch natürlich Shader mit weitaus mehr Instruktionen als erwartet generiert werden. Von daher sollte man auf solchen Karten möglichst auf Schleifen verzichten, oder diese nur recht kurz halten. Bei SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall.

=Eingebaute Variablen, Attribute und Konstanten=
Nachdem wir uns nun lange genug mit den minderinterssanten Elementen der glSlang-Syntax beschäftigt haben, gehts jetzt endlich an die wirklich interessanten Dinge. Wie schon ARB_VP/ARB_FP bringt auch glSlang jede Menge eingabauter Variablen, Attribute und Konstanten mit, deren Aliase sie recht leicht identifizierbar machen (ganz im Gegensatz zum Indexgewusel bei den DX-Shadern).

==Variablen im Vertex Shader==
Exklusiv im Vertex Shader stehen die folgenden Variablen zur Verfügung :

* vec4 gl_Position muss geschrieben werden
:Dieser Variable '''muss''' im Vertexshader ein Wert zugewiesen werden, wird dies nicht getan ist das Ergebnis (sprich die Position des Vertex) undefiniert. Vorgesehen ist diese Variable für die ''homogene Position des Vertex'' und wird u.a. zum Clipping und Culling verwendet. Sie darf natürlich auch (mehrfach) geschrieben und ausgelesen werden.

* float gl_PointSize kann geschrieben werden
:Diese Variable wurde dazu vorgesehen um dort im VertexShader die Punktgröße in Pixeln hineinzuschreiben.

* vec4 gl_ClipVertex kann geschrieben werden
:Falls genutzt, sollten hier die Vertexkoordinaten die im Zusammenhang mit benutzerdefinierten Clippingplanes genutzt werden abgelegt werden. Wichtig ist, das gl_ClipVertex im selben Koordinatenraum wie die Clippingplane definiert ist.

==Attribute im Vertex Shader==

Folgende Attribute stehen nur im Vertex Shader zur Verfügung und '''können nur gelesen werden''' :

* vec4 gl_Color
: Farbwert des Vertex.
* vec4 gl_SecondaryColor
:Sekundärer Farbwert des Vertex.
* vec4 gl_Normal
:Normale des Vertex.
* vec4 gl_Vertex
:Koordinaten des Vertex;
* vec4 gl_MultiTexCoord0..7
:Texturkoordinaten auf Textureinheit 0..7.
* float gl_FogCoord
:Nebelkoordinate des Vertex.

==Variablen im Fragment Shader==

Im Fragment Shader sind folgende Variablen exklusiv nutzbar :

* vec4 gl_FragColor
: Speichert den Farbwert des Fragmentes, der von folgenden Funktionen der festen Pipeline genutzt wird. Wird dieser Variable nichts zugewiesen, so ist ihr Inhalt undefiniert und darauf aufbauende Ergebnisse ebenfalls.

* vec4 gl_FragData[0..15]
: Ersetzt gl_FragColor bei der Verwendung von multiplen Rendertargets.

* float gl_FragDepth
: Durch schreiben dieser Variable kann man den von der festen Funktionspipeline ermittelten Tiefenwert überspringen, der mit {{INLINE_CODE|gl_FragCoord.z}} ausgelesen werden kann. Wird dieser Wert nicht geschrieben, nutzen folgende Funktionen der Pipeline den vorher fest berechneten Wert.

* vec4 gl_FragCoord nur lesen
: In dieser Variable ist die Position des Fragmentes relativ zur Fensterposition im Format x,y,z,1/w abgelegt, wobei z den von der festen Funktionspipeline berechneten Tiefenwert enthält.

* bool gl_FrontFacing nur lesen
: Gibt an ob das Fragment zu einer nach vorne zeigenden Primitive gehört (=true).

Im Bezug auf {{INLINE_CODE|gl_FragColor}} und {{INLINE_CODE|gl_FragDepth}} sei noch anzumerken das diese ''nicht'' in den Wertebereich 0..1 gebracht werden müssen, da dies später durch die feste Funktionspipeline automatisch gemacht wird.

==Eingebaute Varyings==

Wie bereits in Kapitel 4.2 erwähnt, stellen Varyings eine Schnittstelle zwischen dem Vertex und dem Fragment Shader dar. Sie werden im Vertex Shader geschrieben und können dann im Fragment Shader ausgelesen werden, ohne das die folgenden Varyings dafür explizit deklariert werden müssen :

* vec4 gl_FrontColor
: Farbe der Vorderseite des Vertex.

* vec4 gl_BackColor
: Farbe der Rückseite des Vertex.

* vec4 gl_FrontSecondaryColor
: Sekundäre Farbe der Vorderseite des Vertex.

* vec4 gl_BackSecondaryColor
: Sekundäre Farbe der Rückseite des Vertex.

* vec4 gl_TexCoord[x]
: Texturkoordinaten des Vertex auf Textureinheit x, wobei x die von der Hardware zur Verfügung gestellte Zahl der Textureinheiten-1 nicht überschreiten darf.

* float gl_FogFragCoord
: Nebelkoordinate des Fragmentes.

Die Varyings {{INLINE_CODE|gl_FrontColor, gl_FrontSecondaryColor, gl_BackColor}} und {{INLINE_CODE|gl_BackSecondaryColor}} können im FragmentShader nur unter den Aliases gl_Color bzw. gl_SecondaryColor gelesen werden. Welcher Wert des Vertex Shaders im Fragment Shader dort eingesetzt wird ist abhängig davon ob das Fragment zu einer nach vorne oder nach hinten zeigenden Primitive gehört.

==Eingebaute Konstanten==
Auch diverse Konstanten wurden definiert um darauf schnell im Shader zugreifen zu können. In den Klammern stehen die von einer GL-Implementation als Mindestanforderung anzubietenden Werte. Alle Konstanten sind sowohl im Vertex als auch im Fragment Shader abrufbar :

: OpenGL 1.0/1.2 :
* int gl_MaxLights (8)
* int gl_MaxClipPlanes (6)
* int gl_MaxTextureUnits (2)

: ARB_Fragment_Program :
* int gl_MaxTextureCoordsARB (2)

: Vertex_Shader :
* int gl_MaxVertexAttributesGL2 (16)
* int gl_MaxVertexUniformFloatsGL2 (512)
* int gl_MaxVaryingFloatsGL2 (32)
* int gl_MaxVertexTextureUnitsGL2 (1)

: Fragment_Shader :
* int gl_MaxFragmentTextureUnitsGL2 (2)
* int gl_MaxFragmentUniformFloatsGL2 (64)

==Eingebaute Uniformvariablen==

Um den Zugriff auf OpenGL-Staten zu vereinfachen wurden in glSlang diverse Uniformvariablen zur direkten Verwendung im Shader eingebaut. Wie gewohnt wurden auch hier sinnvolle Namen verwendet, so dass eine tiefere Erklärung unnötig sein dürfte :

* mat4 gl_ModelViewMatrix
* mat4 gl_ProjectionMatrix
* mat4 gl_ModelViewProjectionMatrix
* mat3 gl_NormalMatrix
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die invertierten und anschließend transponierten oberen 3x3 Werte der {{INLINE_CODE|gl_ModelViewMatrix}}.
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]

* float gl_NormalScale
: Gibt den unter OpenGL festgelegten Faktor zur Skalierung der Normalen zurück.

* struct gl_DepthRangeParameters
<source lang="glsl">
struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;
</source>
: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
<source lang="glsl">
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</source>
*struct gl_MaterialParameters
<source lang="glsl">
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</source>
*struct gl_LightSourceParameters
<source lang="glsl">
struct gl_LightSourceParameters
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
vec4 position;
vec4 halfVector;
vec3 spotDirection;
float spotExponent;
float spotCutoff;
float spotCosCutoff;
float constantAttenuation;
float linearAttenuation;
float quadraticAttenuation;
};
gl_LightSourceParameters gl_LightSource[gl_MaxLights];
</source>
*struct gl_LightModelParameters
<source lang="glsl">
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</source>
*struct gl_LightModelProducts
<source lang="glsl">
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</source>
*struct gl_LightProducts
<source lang="glsl">
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</source>
* vec4 gl_TextureEnvColor[gl_MaxFragmentTextureUnitsGL2]
* vec4 gl_EyePlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneQ[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneQ[gl_MaxTextureCoordsARB]

*struct gl_FogParameters
<source lang="glsl">
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</source>
Diese recht umfangreiche GL-Stateliste sollte eigentlich jeden Bedarf decken und momentan gibts kaum einen OpenGL-Status den man so nicht in einem Shader abfragen bzw. nutzen kann.

=Eingebaute Funktionen=
glSlang ist mit diversen Skalar- und Vektorfunktionen ausgestattet, die teilweise (idealerweise) sogar direkt in der Hardware ausgeführt werden, weshalb einer fertigen Funktion ggü. gleichwertigen eigenen Berechnungen immer der Vorzug zu geben ist.
{{Hinweis| ''genType'' kann vom Type float, vec2, vec3 oder vec4 sein, ''mat'' vom Typ mat2, mat3 oder mat4.}}

==Trigonometrie und Winkel==
Alle übergebenen Winkel sollten, soweit nicht anders vermerkt, in Radien angegeben werden.

* genType radians (genType degrees)
: Wandelt von Grad nach Radien.
* genType degrees (genType radians)
: Wandelt von Radien nach Grad.
* genType sin (genType x)
: Gibt den Sinus von x zurück, wobei x in Radien angegeben wird.
* genType cos (genType x)
: Gibt den Kosinus von x zurück, wobei x in Radien angegeben wird.
* genType tan (genType x)
: Gibt den Tangens von x zurück, wobei x in Radien angegeben wird.
* genType asin (genType x)
: Liefert den Arcsinus von x zurück, also den Winkel dessen Sinus x ergeben würde.
* genType acos (genType x)
: Liefert den Arckosinus von x zurück, also den Winkel dessen Cosinus x ergeben würde.
* genType atan (genType y, genType x)
: Liefert den Winkel zurück, dessen Tangens x/y ergeben würde.
* genType atan (genType y_over_x)
: Liefert den Winkel zurück, dessen Tangens x über y ergeben würde.

==Hyperbolisch==
* genType sinh (genType x)
: Gibt den Sinus Hyperbolicus von x zurück. (return = (exp(x) - exp(-x)) * 0.5; )
* genType cosh (genType x)
: Gibt den Kosinus Hyperbolicus von x zurück. (return = (exp(x) + exp(-x)) * 0.5; )
* genType tanh (genType x)
: Gibt den Tangens Hyperbolicus von x zurück. (return = (exp(x) - exp(-x)) / (exp(x) + exp(-x)); )
* genType asinh (genType angle)
: Gibt den Areasinus Hyperbolicus von x zurück. (return = log(x + sqrt(x * x + 1.0)); )
* genType acosh (genType angle)
: Gibt den Areakosinus Hyperbolicus von x zurück. (return = log(x + sqrt(x * x - 1.0)); )
* genType atanh (genType x)
: Gibt den Areatangens Hyperbolicus von x zurück. (return = log((1.0 + x) / (1.0 - x)) * 0.5; )

==Exponentiell==
* genType pow (genType x, genType y)
: Gibt x hoch y zurück.
* genType exp (genType x)
: Gibt e(Eulerischezahl ≈ 2.7182) hoch x zurück.
* genType log (genType x)
: Gibt den Logarithmus zur Basis e(Eulerischezahl ≈ 2.7182) von x zurück.
* genType exp2 (genType x)
: Gibt 2 hoch x zurück.
* genType log2 (genType x)
: Gibt den Logarithmus zur Basis 2 von x zurück.
* genType sqrt (genType x)
: Gibt die Wurzel von x zurück.
* genType inversesqrt (genType x)
: Gibt die umgekehrte Wurzel von x zurück.

==Standardfunktionen==
* genType abs (genType x)
: Liefert den absoluten Wert von x zurück.
* genType sign (genType x)
: Gibt -1.0 zurück, wenn x < 0.0, 0.0 wenn x = 0.0 und 1.0 wenn x > 0.0.
* genType roundeven(genType x)
: Rundet auf den nächsten Integerwert und gibt diesen zuück. Bei ".5" Werten wird zur nächsten geraden Zahl gerundet.
* genType round(genType x)
: Rundet auf den nächsten Integerwert und gibt diesen zuück. ".5" Werte werden je nach Implementation anders behandelt.
* genType trunc(genType x)
: Rundet auf den nächsten Integerwert dessen Absoluterwert nicht größer ist als der Absolutewert von x
* genType floor (genType x)
: Gibt denn größten Integerwert zurück, der kleiner oder gleich x ist.
* genType ceil (genType x)
: Gibt den kleinsten Integerwert zurück, der größer oder gleich x ist.
* genType fract (genType x)
: Gibt den Nachkommateil von x zurück.
* genType mod (genType x, float y)
* genType mod (genType x, genType y)
: Gibt den Modulus zurück. (result = x - y * floor(x / y))
* genType min (genType x, genType y)
* genType min (genType x, float y)
: Liefert y zurück wenn y < x, ansonsten x.
* genType max (genType x, genType y)
* genType max (genType x, float y)
: Liefert y zurück wenn x < y, ansonsten x.
* genType clamp (genType x, genType minVal, genType maxVal)
* genType clamp (genType x, float minVal, float maxVal)
: Zwängt x in den Bereich minVal ... maxVal . (return = min(minVal, max(maxVal, x)))
* genType mix (genType x, genType y, genType a)
* genType mix (genType x, genType y, float a)
: Liefert den linearen Blend zwischen x und y zurück. (result = x * (1 - a) + y * a)
* genType step (genType edge, genType x)
* genType step (float edge, genType x)
: Liefert 0.0 zurück, wenn x < edge, ansonsten 1.0.
* genType smoothstep (genType edge0, genType edge1, genType x)
* genType smoothstep (float edge0, float edge1, genType x)
: Liefert 0.0 zurück, wenn x <= edge0 und 1.0 wenn x >= edge1. Dazwischen wird eine weiche Hermite Interpolation durchgeführt.
::float t = clamp((x - edge0) / (edge1 - edge0), 0.0, 1.0);
::result = t * t * (3.0 - 2.0 * t)

==Geometrie==
* float length (genType x)
: Gibt die Länge des Vektors x (= sqrt(x[0]² + x[1]² + ... + x[n]²) zurück.
* float distance (genType p0, genType p1)
: Gibt die Distanz zwischen den zwei Vektoren p0 un p1 (= length(p0-p1)) zurück.
* float dot (genType x, genType y)
: Gibt das Punktprodukt von x und y zurück (=x[0]*y[0] + x[1]*y[1] + ... + x[n]*y[n]).
* vec3 cross (vec3 x, vec3 y)
: Gibt das Kreuzprodukt von x und y zurück.
* genType normalize (genType x)
: Normalisiert den Vektor x auf die Länge 1.
* vec4 ftransform()
: Nur im Vertex Shader. Die Funktion stellt sicher, das das eingehende Vertex haargenau so transformiert wird wie in der festen Funktionspipeline. gl_Position = ftransform() wird dann also gebraucht, wenn in mehreren Durchgängen sowohl im Shader als auch in der festen Pipeline gerendert wird, um sicherzustellen das in beiden Fällen die gleiche Vertexposition herauskommt.
* genType faceforward (genType N, genType I, genType Nref)
: Gibt einen nach vorne zeigenden Vektor N zurück. (If dot(NRef, I) < 0 return N else return -N)
* genType reflect (genType l, genType N)
: Gibt den an der Flächenausrichtung N reflektierten Vektor I zurück. (result = l - 2.0 * dot(N,I) * N; )
* genType refract (genType l, genType N, float eta)
: Gibt den an der Flächenausrichtung N mit dem Brechungsindex eta gebrochenen Vektor l zurück.
::gentype k = 1.0 - eta * eta * (1.0 - dot(N, l) * dot(N, l))
::if (k < 0.0)
:::result = 0.0
::else
:::result = eta * l - (eta * dot(N, l) * sqrt(k)) * N

==Matrixfunktionen==
* mat matrixCompMult (mat x, mat y)
: Multipliziert Matrix X mit Matrix Y komponentenweise. Um eine normale lineare Matrixmultiplikation durchzuführen, sollte der "*"-Operator genutzt werden.
* mat transpose (mat m)
: Gibt die transponierte Matrix von m zurück.
* mat invert (mat m)
: Gibt die invertierte Matrix von m zurück. Also die Matrix, die mit m multipliziert die Normalmatrix ergeben würde.
* mat outerProduct(vec c, vec r)
: Gibt eine eine Matrix als Ergebnis der linearen (return[m, n] = c[m] * r[n])-Operation zurück.

==Vektorvergleiche==
Die meisten Vektorvergleichsfunktionen liefern als Ergebnis einen boolvektor zurück, da die Vergleiche per Komponente stattfinden. Wenn man also x = vec4(1.0, 3.0, 0.0, 0.0) mit y = vec4(2.0, 1.5, 1.5, 0.0) via lessThan(x, y) vergleicht, erhält man als Ergebnis bvec(true, false, true, false).

* bvec lessThan (vec x, vec y)
* bvec lessThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x < y zurück.
* bvec lessThanEqual (vec x, vec y)
* bvec lessThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x <= y zurück.
* bvec greaterThan (vec x, vec y)
* bvec greaterThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x > y zurück.
* bvec greaterThanEqual (vec x, vec y)
* bvec greaterThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x >= y zurück.
* bvec equal (vec x, vec y)
* bvec equal (ivec x, ivec y)
* bvec equal (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x == y zurück.
* bvec notEqual (vec x, vec y)
* bvec notEqual (ivec x, ivec y)
* bvec notEqual (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x != y zurück.
* bool any (bvec x)
: Liefert true zurück, wenn mindestens eine der Komponenten von x true ist.
* bool all (bvec x)
: Liefert true zurück, wenn alle Komponenten von x true sind.
* bvec not (bvec x)
: Liefert die logische Negation von x zurück.

==Texturenzugriffe==

Diese wichtige Funktionskategorie dient dazu, Werte aus einer an eine Textureinheit gebundenen Textur zu ermitteln. Die Texturenzugriffe können sowohl im Vertex (!) als auch im Fragment Shader ausgeführt werden, wobei der optionale Parameter bias im Vertex Shader ignoriert wird. Allerdings gibt es zusätzlich Funktionen die auf "Lod" enden und nur im Vertex Shader genutzt werden dürfen um eben dieses Manko zu umgehen. Funktionen mit dem Suffix "Proj" geben einen projizierten Texturenwert zurück.

: '''1D-Texturen :'''
* vec4 texture1D (sampler1D sampler, float coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec2 coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture1DLod (sampler1D sampler, float coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec2 coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec4 coord, float lod)

: '''2D-Texturen :'''
* vec4 texture2D (sampler2D sampler, vec2 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

: '''3D-Texturen :'''
* vec4 texture3D (sampler3D sampler, vec3 coord [, float bias])
* vec4 texture3DProj (sampler3D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture3DLod (sampler3D sampler, vec3 coord, float lod)
* vec4 texture3DProjLod (sampler3D sampler, vec4 coord, float lod)

: '''Cubemap :'''
* vec4 textureCube (samplerCube sampler, vec3 coord [, float bias])
: Nur im Vertex Shader :
*vec4 textureCubeLod (samplerCube sampler, vec3 coord, float lod)

: '''Tiefentextur (Shadowmap) :'''
* vec4 shadow1D (sampler1DShadow sampler, vec3 coord [, float bias])
* vec4 shadow2D (sampler2DShadow sampler, vec3 coord [, float bias])
* vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord [, float bias])
* vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 shadow1DLod (sampler1DShadow sampler, vec3 coord, float lod)
* vec4 shadow2DLod (sampler2DShadow sampler, vec3 coord, float lod)
* vec4 shadow1DProjLod (sampler1DShadow sampler, vec4 coord, float lod)
* vec4 shadow2DProjLod (sampler2DShadow sampler, vec4 coord, float lod)

: '''Texturegröße :'''
Mit den textureSize-Befehlen kann die Größe einer Textur bestimmt werden, wobei lod das Mipmaplevel angibt:
*int textureSize(sampler1D sampler, int lod)
*ivec2 textureSize(sampler2D sampler, int lod)
*ivec3 textureSize(sampler3D sampler, int lod)
*ivec2 textureSize(samplerCube sampler, int lod)
*int textureSize(sampler1DShadow sampler, int lod)
*ivec2 textureSize(sampler2DShadow sampler, int lod)

Wie bereits eingangs gesagt ist dieses Kapitel ein sehr wichtiges, denn eine 3D-Szene ohne Texturen ist heute kaum denkbar. Darüber hinaus lassen sich durch Texturenzugriffe recht viele interessante Sachen machen, z.B. ein einfacher Blurfilter oder das freie überblenden bestimmter Texturenteile. Deshalb führe ich hier kurz ein paar Beispiele an, welche die Nutzung dieser Funktionen verdeutlichen sollen :

===Beispiel A===
Eine Textur gebunden die einfach ausgegeben werden soll

''Im Vertex Shader'' :
<source lang="glsl">
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>
Der Vertex Shader ist recht minimal. Neben der homogenen Vertexposition leiten wir hier nur die im OpenGL-Programm angegebenen Texturkoordinaten weiter. ''Dies ist aber unbedingt nötig!'' Ohne die letzte Zeile hätten wir im Fragment Shader keine gültigen Texturkoordinaten auf TMU0, was in einer Fehldarstellung enden würde.

''im Fragment Shader'' :
<source lang="glsl">
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</source>
Zuerst deklarieren wir hier einen 2D-Texturensampler, wichtig : '''Texturensampler müssen IMMER als uniform deklariert werden!''' In der Hauptfunktion weisen wir dann einfach den über die Funktion texture2D aus unserer gebundenen Textur ausgelesenen Farbwert, anhand der vom Vertex Shader übergebenen Texturkoordinaten, zu.
{{Vorlage:Hinweis|Der Uniform-Integer für den Sampler referenziert '''nicht''' den Namen (die ID) des Texturobjektes, sondern die Nummer der Texturunit.}}

===Beispiel B===
Zwei Texturen, jeweils auf TMU0 und TMU1. Fragmentfarbe soll eine Multiplikation der beiden Texturen darstellen.

In diesem Beispielfall (der recht häufig vorkommt) müssen wir im Programm festlegen, ''welcher Sampler welche Textureinheit adressiert'', genau deshalb müssen die Texturensampler auch als uniform deklariert werden. Die Standardtextureneinheit eines Samplers ist TMU0, was in unserem Falle natürlich nicht brauchbar ist. Also müssen wir unserem zweiten Textursampler im Programm mitteilen das er seine Daten aus TMU1 beziehen soll :

glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);

Dies ist also unbedingt zu machen, sobald ein Texturensampler eine Textureinheit > GL_TEXTURE_0 adressieren will. Die Textureneinheit des Samplers lässt sich also nicht im Shader selbst festlegen. Der Fragment Shader ist nun allerdings schnell hergeleitet (Vertex Shader verändert sich nicht, da TMU1 die Texturkoordinaten auch von TMU0 bezieht) :

im Fragment Shader :
<source lang="glsl">
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

void main(void)
{
gl_FragColor = texture2D(texSamplerTMU0, vec2(gl_TexCoord[0])) *
texture2D(texSamplerTMU1, vec2(gl_TexCoord[0]));
}
</source>

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich [[GLSL noise|Noisefunktionen]] nutzen, mit deren Hilfe sich eine gewisse "Zufälligkeit" simulieren lässt (wirklich zufällige Werte sind es natürlich nicht). Ein zurückgegebener Wert liegt dabei immer im Bereich [-1..1] und ist immer bei gleichem Eigabewert auch immer gleich. Die Verwendung empfiehlt sich derzeit allerdings eher nicht, da nur die 3DLabs Treiber die Funktionen unterstützen und eine Noisetextur wahrscheinlich performanter ist.

* float noise1 (genType x)
* vec2 noise2 (genType x)
* vec3 noise3 (genType x)
* vec4 noise4 (genType x)

==Discard==
Eigentlich keine Funktion, sondern eine Abbruchbedingung '''nur im Fragment Shader'''. Das Schlüsselwort {{INLINE_CODE|discard}} verwirft das aktuell bearbeitete Fragment und beendet gleichzeitig den Shader. Es kann z.B. genutzt werden um Alphamasking manuell durchzuführen.
Man sollte dabei jedoch beachten dass ein Großteil der aktuellen Hardware kein "early-out" (frühes Beenden) im Fragmentshader unterstützt. Wenn dort also ein {{INLINE_CODE|discard}} auftaucht, wird trotzdem auch der Code danach ausgeführt und einfach verworfen. Einen Geschwindigkeitsvorteil durch diesen Befehl wird man also erst auf neueren Karten feststellen, die dieses Faeature auch so unterstützen wie es angedacht war.

=Beispielshader=
Wen bis hierhin nicht der Mut verlassen hat, und wer aufmerksam gelesen hat, dürfte jetzt also zumindest in der Lage sein kleinere Shader in glSlang zu schreiben und diese auch im Programm zu nutzen. Ich habe im Themenbereich "glSlang" versucht alle Bereiche der Shadersprache selbst anzusprechen und hoffe das auch brauchbar rübergebracht zu haben. Um oben erlerntes (hoffe ich doch mal) nochmal zu vertiefen werde ich jetzt (wie ich das bereits bei meinem ARB_VP-Tutorial getan habe) einen simplen Beispielshader (Vertex und Fragment Shader) auseinanderpflücken um so u.a. auch die Programmstruktur für alle die in C nicht so bewandert sind zu erörtern.

==Der Vertex Shader==
<source lang="glsl">
uniform vec4 GlobalColor;

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color * GlobalColor;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Wie gesagt recht simpel. Angefangen wird mit der Deklaration einer globalen Uniformvariable namens {{INLINE_CODE|GlobalColor}}. Wie wir uns erinnern gibt der Typenqualifizierer uniform an, das wir den Wert dieser Variable (ein 4-Komponentenvektor, da Farbwerte aus R,G,B und A bestehen) in unserem Programm an den Shader übermitteln.

Danach gehts ohne Umwege direkt in unsere Hauptfunktion, da wir im Vertex Shader keine anderen Funktionen benötigen. Dort berechnen wir zuerst die homogene Position unseres Vertex, die sich aus der eingehenden Vertexposition multipliziert mit der Modelansichtsmatrix ergibt. Wie schonmal gesagt '''muss diesem Wert etwas zugewiesen werden''', da sonst alle darauf aufbauenden Funktionen unvorhersehbare Ergebnisse liefern.
Außerdem wollen wir die Frontfarbe unseres Vertex jedesmal mit der im Programm übergebenen GlobalColor multiplizieren, so dass wir den Farbwert der gesamten Szene aus unserem Programm heraus manipulieren können. Zu guterletzt geben wir dann noch unsere aus der festen Funktionspipeline erhaltenen Texturkoordinaten auf Textureinheit 0 weiter. Wenn im Fragmentshader Texturkoordinaten verwendet werden, '''muss das getan werden'''.

==Der Fragment Shader==
<source lang="glsl">
uniform sampler2D Texture0;
uniform sampler2D Texture1;
uniform sampler2D Texture2;
uniform sampler2D Texture3;

void main(void)
{
vec2 TexCoord = vec2( gl_TexCoord[0] );
vec4 RGB = texture2D( Texture0, TexCoord );

gl_FragColor = texture2D(Texture1, TexCoord) * RGB.r +
texture2D(Texture2, TexCoord) * RGB.g +
texture2D(Texture3, TexCoord) * RGB.b;
}
</source>

Auch hier passiert nicht wirklich viel Großartiges. Wir deklarieren beim Shaderanfang zuerst vier Texturensampler, da wir insgesamt vier verschiedene Texturen im Shader auslesen wollen, eine Verlaufstextur und drei Oberflächentexturen. Auch hier sei wieder gesagt das man Sampler '''immer als uniform deklarieren muss'''. In der Hauptfunktion deklarieren wir dann einen Farbvektor, der auch direkt einen Farbwert aus Textureinheit 0 zugewiesen bekommt. Auf Textureinheit 0 haben wir ihm Hauptprogramm eine Verlaufstextur gebunden, die angibt wie die drei folgenden Texturen ineinander geblendet werden.
Danach schreiben wir dann den Farbwert des Fragmentes, der '''im Fragment Shader ausgegeben werden muss'''. Der besteht wie einfach zu erkennen aus Farbwert von Textureinheit 1 * Rotwert von Textureinheit 0 + Farbwert von Textureinheit 2 * Grünwert von Textureinheit 0 + Farbwert von Textureinheit 3 * Blauwert von Textureinheit 0. So ist z.B. an Stellen an denen in der Verlaufstextur reines blau liegt nur die dritte Textur sichtbar.

So viel also zu unserem kleinen Beispielshader. Er ist weder besonders toll noch besonders sinnvoll, sollte aber auch eher dazu dienen euch glSlang ein wenig zu veranschaulichen, was mir hoffentlich gelungen ist.

Wenn ihr in den vorangegangenen Kapiteln zumindest ein wenig aufgepasst habt, dann könnt ihr euch vor eurem inneren Auge hoffentlich vortstellen was der Shader macht : Er blendet drei Texturen weich anhand der Verlaufstextur ineinander über. Sowas kann man z.B. für ein Terrain nutzen, um dieses anhand einer Farbtextur zu texturieren. Für alle, die damit Probleme haben hier zwei Bilder die den Shader veranschaulichen. Links die Verlaufstextur, die angibt wo welche Textur wie stark gewichtet wird und rechts dann das Ergebnis :

<div align="center"> [[BILD:GLSL_sample_shader_a.jpg]] [[BILD:GLSL_sample_shader_b.jpg]]</div>

=Post Mortem=
Das wars also, meine "Einführung" in die OpenGL Shader Sprache. Ich hoffe es hat euch nicht gelangweilt und auch die von mir zur Verfügung gestellten Informationen haben euch hoffentlich ausgereicht. Mit der Veröffentlichung dieser Einführung geht übrigens auch die Eröffnung eines Shaderforums hier auf der DGL einher, in der ihr dann also fleissig Fragen zum Thema stellen oder eure Shader präsentieren könnt. In diesem Post Mortem gehe ich jetzt noch kurz auf die Zukunft von glSlang ein und zeige ein paar Screenshots (damit die Augen entspannen können), bevor ihr euch dann selbst in die Shaderwelt stürzen könnt.

=Beispiele=

Anbei ein paar exemplarische Screenshots. Da man mit GLSL aber alle möglichen Effekte berechnen kann (u.a. auch 1:1 die feste Funktionspipeline) ist es hier unmöglich einen Überblick aller möglichen Techniken zu geben.

[[Datei:tut_glsl_eigenershader_01.png]] [[Datei:tut_glsl_eigenershader_02.png]] [[Datei:tut_glsl_eigenershader_03.png]]

Wie im ersten (und dritten) Screenshot zu sehen ist es natürlich auch möglich mehrere Techniken innerhalb einer Szene zu nutzen. Hier sind letztendlich bis auf Hardwarelimitationen keine Grenzen gesetzt.

=Die Zukunft=
Als dieses Tutorial geschrieben wurde, war noch nicht ganz abzusehen dass bzw. ob sich GLSL auch durchsetzen würde. ARB-Shader und NVidias cG waren damals die Platzhirsche, aber inzwischen werden ARB-Shader nicht mehr genutzt (und auch schon länger nicht mehr weiterentwickelt) und auch NVidia setzt primär auf GLSL. GLSL wird permanent weiterenwtickelt und Hersteller können dank des flexiblen Extensionsystems auch in GLSL eigene Extensions offenlegen um die aktuellsten Features (wie z.b. den Tesselator auf aktuellen ATI-Karten) nutzen zu können. GLSL gilt inzwischen auch offizielle die Shadersprache für OpenGL und wird permanent an die neusten technischen Entwicklungen im Grafikkartenbereich angepasst.

Wer also unter OpenGL etwas mit Shadern machen möchte, kommt an GLSL nicht vorbei!

Also viel Spaß beim Experimentieren und Shaderschreiben! Und nicht vergessen : Wir wollen sehen was ihr so treibt,

Euer
:Sascha Willems

{{TUTORIAL_NAVIGATION|-|[[Tutorial_glsl2]]}}
[[Kategorie:Tutorial|GLSL]]

SDL WasInit

2013-08-24T12:36:02Z

End: Versionsangaben hinzugefügt.

= SDL_WasInit =

== Name ==
'''SDL_WasInit''' - Überprüft ob Teilsysteme von SDL initialisiert wurden. Ab Version 1.0.

== Delphi-Spezifikation ==

function '''SDL_WasInit'''(''flags'' : Uint32): Uint32

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Enthält die zu initialisierenden Teile von SDL
|}

Wobei dies die Teilsysteme von SDL sind:

{| border="1" rules="all"
!SDL_INIT_TIMER
|Initialisiert das Zeit Managment.
|-
!SDL_INIT_AUDIO
|Initialisiert das Audio Subsystem.
|-
!SDL_INIT_VIDEO
|Initialisiert das Fenster Managment.
|-
!SDL_INIT_CDROM
|Initialisiert das CD-ROM Subsystem.
|-
!SDL_INIT_JOYSTICK
|Initialisiert das Joystick Subsystem.
|-
!SDL_INIT_EVERYTHING
|Initialisiert alle Subsysteme.
|-
!SDL_INIT_NOPARACHUTE
|Verhindert das SDL fatale Signale fängt.
|-
!SDL_INIT_EVENTTHREAD
|Startet den Event Manager in einem speraten Thread.
|}

== Beschreibung ==
'''SDL_WasInit''' dient zur Überprüfung ob Teilsysteme von [[SDL]] schon initalisiert wurden.

== Hinweise ==
Die ''flags'' sollten [[bitweise Kombination|bitweise]] mit '''or''' verknüpft werden.
Bsp: '''SDL_INIT_VIDEO or SDL_INIT_AUDIO'''

== Rückgabewert ==
'''SDL_WasInit''' gibt die initialisierten Teilsysteme bitweise per '''or''' verknüpft zurück.

== Beispiel ==

<source lang="pascal">
var subsystem_init: Uint32;
begin
subsystem_init:=SDL_WasInit(SDL_INIT_EVERYTHING);
if (subsystem_init and SDL_INIT_VIDEO)<>0 then
writeln('Video is initialized.')
else
writeln('Video is not initialized.');
end;</source>

<source lang="pascal"> //Überprüfung auf ein spezifisches Teilsystem
begin
if SDL_WasInit(SDL_INIT_VIDEO)<>0 then
writeln('Video is initialized.')
else
writeln('Video is not initialized.');
end;</source>

<source lang="pascal"> //Überprüfung auf zwei Teilsystemen
var subsytem_mask: Uint32;
begin
subsystem_mask:=SDL_INIT_VIDEO or SDL_INIT_AUDIO;

if (SDL_WasInit(subsystem_mask)=subsystem_mask) then
writeln('Video and Audio initialized.')
else
writeln('Video and Audio not initialized.');
end;</source>

== Siehe auch ==
[[SDL_Init]], [[SDL_InitSubSystem]]

[[Kategorie:SDL|WasInit]]

SDL QuitSubSystem

2013-08-24T12:34:20Z

End: Versionsangaben hinzugefügt.

= SDL_QuitSubSystem =

== Name ==
'''SDL_QuitSubSystem''' - Beendet ein Subsystem. Ab Version 1.0.

== Delphi-Spezifikation ==
procedure '''SDL_QuitSubSystem'''(''flags'' : Uint32)

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Enthält die Teilsysteme, siehe [[SDL_Init]]
|}

== Beschreibung ==
'''SDL_QuitSubSystem''' beendet einzelne Teilsysteme von SDL, die bereits initialisiert wurden.

== Siehe auch ==
[[SDL_Quit]], [[SDL_Init]], [[SDL_InitSubSystem]]

[[Kategorie:SDL|QuitSubSystem]]

SDL Quit

2013-08-24T12:32:50Z

End: Versionsangaben hinzugefügt.

= SDL_Quit =

== Name ==
'''SDL_Quit''' - Beendet die Nutzung von SDL. Ab Version 1.0.

== Delphi-Spezifikation ==
procedure '''SDL_Quit''';

== Beschreibung ==
'''SDL_Quit''' fährt alle SDL-Subsysteme herunter und gibt die verwendeten Ressourcen wieder frei. Es sollte immer dann aufgerufen
werden, wenn die Anwendung beendet. Bitte beachtet, dass '''SDL_Quit''' nur die SDL-Subsysteme beendet und nicht die Anwendung selbst.

== Siehe auch ==
[[SDL_Init]], [[SDL_QuitSubSystem]]

[[Kategorie:SDL|Quit]]

SDL LoadObject

2013-08-24T12:32:19Z

End: Versionsangaben hinzugefügt.

= SDL_LoadObject =

== Name ==
'''SDL_LoadObject''' - Liefert einen Pointer zu einer Bibliothek zurück. Unter Windows sind dies DLLs, unter Linux werden damit Shared Libraries angesprochen. Ab Version 1.0.

== Delphi-Spezifikation ==

function ''SDL_LoadObject''('''const''' ''sofile'' : PChar): Pointer

== Parameter ==

{| border="1" rules="all"
! ''sofile''
| Nullterminierter String, der den Namen des Shared Objekts enthält.
|}

== Beschreibung ==
'''SDL_LoadObject''' ermittelt einen Pointer zu einer Bibliothek. Dieser Pointer, auch als Handle bezeichnet, wird in den Funktionen [[SDL_LoadFunction]] und [[SDL_UnloadObject]] verwendet.

== Hinweis ==
Unter Linux ist die Groß-/Kleinschreibung des Namens der Shared Library zu beachten.

Beim Entladen des Shared Objects werden alle abgefragten Funktionspointer ungültig.

Wenn die Art und Anzahl der Parameter der Funktion beim Aufruf nicht übereinstimmen, wird die Anwendung mysteriös crashen.

== Rückgabewert ==
Ein Zeiger auf die geladene Library. Falls ein Fehler aufgetreten ist, ist der Rückgabewert 0.

== Siehe auch ==
[[SDL_LoadFunction]], [[SDL_UnloadObject]]

[[Kategorie:SDL|Allgemein]]

SDL InitSubSystem

2013-08-24T12:26:48Z

End: Versionsangaben hinzugefügt.

= SDL_InitSubSystem =

== Name ==
'''SDL_InitSubSystem''' - Initialisiert weitere Teilsysteme von SDL. Ab Version 1.0.

== Delphi-Spezifikation ==

function '''SDL_INITSUBSYSTEM'''(''flags'' : Uint32): Integer

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Enthält die zu initialisierenden Teile von SDL
|}

Wobei dies die Teilsysteme von SDL sind:

{| border="1" rules="all"
!SDL_INIT_TIMER
|Initialisiert das Zeit Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_AUDIO
|Initialisiert das Audio Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_VIDEO
|Initialisiert das Fenster Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_CDROM
|Initialisiert das CD-ROM Subsystem.
|1.2 / 1.3
|-
!SDL_INIT_JOYSTICK
|Initialisiert das Joystick Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVERYTHING
|Initialisiert alle Subsysteme.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_NOPARACHUTE
|Verhindert das SDL fatale Signale fängt.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVENTTHREAD
|Startet den Event Manager in einem speraten Thread.
|1.2 / 1.3 / 2.0
|}

== Beschreibung ==
Mit '''SDL_InitSubSystem''' kann man noch nicht initialisierte Teilsysteme von SDL initialisieren.

== Hinweise ==
Die ''flags'' sollten [[bitweise Kombination|bitweise]] mit '''or''' verknüpft werden.
Bsp: '''SDL_INIT_VIDEO or SDL_INIT_AUDIO'''

== Rückgabewert ==
'''SDL_InitSubSystem''' gibt 0 bei Erfolg zurück, -1 bei einem Fehler.
Eine Fehlermeldung bekommt man über [[SDL_GetError]].

== Siehe auch ==
[[SDL_Init]], [[SDL_WasInit]], [[SDL_QuitSubSystem]]

[[Kategorie:SDL|InitSubSystem]]

SDL GetError

2013-08-24T12:22:46Z

End: Versionsangaben hinzugefügt.

SDL Init

2013-08-24T12:21:42Z

End: Eine weitere Versionsangabe.

= SDL_Init =

== Name ==
'''SDL_Init''' - Initialisiert SDL

Ab Version 1.0.

== Delphi-Spezifikation ==

function '''SDL_INIT'''(''flags'' : Uint32): Integer

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Enthält die zu initialisierenden Teile von SDL
|}

Wobei dies die Teilsysteme von SDL sind:

{| border="1" rules="all"
!SDL_INIT_TIMER
|Initialisiert das Zeit Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_AUDIO
|Initialisiert das Audio Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_VIDEO
|Initialisiert das Fenster Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_CDROM
|Initialisiert das CD-ROM Subsystem.
|1.2 / 1.3
|-
!SDL_INIT_JOYSTICK
|Initialisiert das Joystick Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVERYTHING
|Initialisiert alle Subsysteme.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_NOPARACHUTE
|Verhindert das SDL fatale Signale fängt.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVENTTHREAD
|Startet den Event Manager in einem speraten Thread.
|1.2 / 1.3 / 2.0
|}

== Beschreibung ==
'''SDL_Init''' initialisiert die gewünschten Teilsysteme von SDL und muss vor allen anderen SDL-Funktionen aufgerufen werden.

== Hinweise ==
Die ''flags'' sollten [[bitweise Kombination|bitweise]] mit '''or''' verknüpft werden.
Bsp: '''SDL_INIT_VIDEO or SDL_INIT_AUDIO'''

== Rückgabewert ==
'''SDL_Init''' gibt 0 bei Erfolg zurück, -1 bei einem Fehler.
Eine Fehlermeldung bekommt man über [[SDL_GetError]].

== Beispiel ==
<source lang="pascal">[...]
if (SDL_Init(SDL_INIT_VIDEO or SDL_INIT_TIMER) < 0 ) then
begin
WriteLn('Error during SDL init:'+SDL_GetError);
Quit_App;
end;
[...]</source>

==Siehe auch ==
[[SDL_Quit]], [[SDL_InitSubSystem]], [[SDL_GetError]]

[[Kategorie:SDL|Init]]

SDL Init

2013-08-24T12:20:06Z

End: Versionsangaben hinzugefügt.

= SDL_Init =

== Name ==
'''SDL_Init''' - Initialisiert SDL

== Delphi-Spezifikation ==

function '''SDL_INIT'''(''flags'' : Uint32): Integer

== Parameter ==

{| border="1" rules="all"
! ''flags''
| Enthält die zu initialisierenden Teile von SDL
|}

Wobei dies die Teilsysteme von SDL sind:

{| border="1" rules="all"
!SDL_INIT_TIMER
|Initialisiert das Zeit Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_AUDIO
|Initialisiert das Audio Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_VIDEO
|Initialisiert das Fenster Managment.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_CDROM
|Initialisiert das CD-ROM Subsystem.
|1.2 / 1.3
|-
!SDL_INIT_JOYSTICK
|Initialisiert das Joystick Subsystem.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVERYTHING
|Initialisiert alle Subsysteme.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_NOPARACHUTE
|Verhindert das SDL fatale Signale fängt.
|1.2 / 1.3 / 2.0
|-
!SDL_INIT_EVENTTHREAD
|Startet den Event Manager in einem speraten Thread.
|1.2 / 1.3 / 2.0
|}

== Beschreibung ==
'''SDL_Init''' initialisiert die gewünschten Teilsysteme von SDL und muss vor allen anderen SDL-Funktionen aufgerufen werden.

== Hinweise ==
Die ''flags'' sollten [[bitweise Kombination|bitweise]] mit '''or''' verknüpft werden.
Bsp: '''SDL_INIT_VIDEO or SDL_INIT_AUDIO'''

== Rückgabewert ==
'''SDL_Init''' gibt 0 bei Erfolg zurück, -1 bei einem Fehler.
Eine Fehlermeldung bekommt man über [[SDL_GetError]].

== Beispiel ==
<source lang="pascal">[...]
if (SDL_Init(SDL_INIT_VIDEO or SDL_INIT_TIMER) < 0 ) then
begin
WriteLn('Error during SDL init:'+SDL_GetError);
Quit_App;
end;
[...]</source>

==Siehe auch ==
[[SDL_Quit]], [[SDL_InitSubSystem]], [[SDL_GetError]]

[[Kategorie:SDL|Init]]

Tutorial ColorPicking Shader

2013-03-02T09:34:56Z

End: Das Pixel-Array des Mauszeigers ist jetzt WIRKLICH 9 Pixel groß und es werden WIRKLICH nur 9 Pixel eingelesen.

=Objektselektion mit Color Picking=

==Einleitung==

Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bot bisher leider
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu
bewogen hat, diese Methode in OpenGL3 zu entfernen.

Ein Wort zur angestrebten Zielgruppe:
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine
performante, für große Projekte taugliche und vor allem zukunftssichere Methode
zu präsentieren. Für Einsteiger mit weniger großen Ambitionen empfiehlt sich aber vorerst eher die [[Tutorial ColorPicking|shaderlose Variante]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welche mit einfacheren Mitteln auskommt.

In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:

<table>
<tr>
<td align="center">Vorteile</td>
<td align="center">Nachteile</td>
</tr>
<tr>
<td valign="top">
* Geschwindigkeit
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".

* Speichereffizienz
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).

* Flexibilität
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:

* Simplizität
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).
</td>

<td valign="top">
* Reproduzierbarkeit
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.

* Redundanz zum Physikcode
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.

* Hardwareanforderungen
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.
</td>
</tr>
</table>

==Theorie==

Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches
Objekt in welcher Farbe gezeichnet wurde.
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer
werden, wenn ihr den Beispielcode verfolgt.

==Implementierung==

===Organisation===

Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem
Beispiel sieht das Ganze so aus:
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.

===Der Shader===

Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und
schlechter zu lesen ist.

Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und
anschließend wieder ausgeschaltet werden:

<source lang="glsl">
// Vertexshader

void main(void)
{
gl_Position = ftransform();
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett
ignoriert wird.

<source lang="glsl">
// Fragmentshader

uniform vec4 color;
uniform float use_alpha_tex;
uniform sampler2D sampler;

void main(void)
{
if (use_alpha_tex == 1.0)
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)
discard;

gl_FragColor = color;
}
</source>

Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,
was auch im Framebuffer erscheinen wird.

"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal
verwendet werden.
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2
liegt. Es handelt sich also nur um einen handgemachten Alphatest.

Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.

Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu
lassen.

Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer
Einheitsfarbe eingefärbt werden soll.

===Die Renderschleife===

Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.

<source lang="pascal">
procedure Render;
const
fac: single = 1/255;
var
i: longword;
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich
</source>

Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.

Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0
Karten funktioniert auch Integer, ist aber sehr unperformant).
Das nächste Häppchen:

<source lang="pascal">
begin
glClear(GL_COLOR_BUFFER_BIT);

// Das Erste Model soll texturiert werden
glEnable(GL_TEXTURE_2D);
glUniform1f(SelShader.use_alpha_tex, 1.0);

for i := 1 to high(Objekte) do
begin
if i = 2 then begin // Ab dem zweiten nicht mehr
glDisable(GL_TEXTURE_2D);
glUniform1f(SelShader.use_alpha_tex, 0.0);
end;
</source>

Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:

<source lang="pascal">
// Den Index in eine Farbe umrechnen und im Shader setzen
{$ifdef ENDIAN_BIG}
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);
{$else}
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);
{$endif}

// Zeichnen
glLoadIdentity;
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);
glCallList(Objekte[i].displayliste);
end;
end;
</source>

Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet
werden, wäre er aktiviert.

Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau
umgekehrt.

Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik
verdeutlicht dies:

[[Datei:Endian.png|center]]

Natürlich wird bei so einer einfachen Methode die Reihenfolge der
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da
wir die gefärbten Bilder allerdings sowieso nicht zu Gesicht bekommen, ist es
egal.
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss
so :3

Wenn ihr den {{ArchivLink|file=tut_colorpicking_src|text=restlichen Code}} analysiert werdet ihr feststellen, dass SwapBuffers
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das
Bild nicht angezeigt).

Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt
und ihn nicht wiederholt:
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen
zum untersten Bit von Links nach Rechts. Damit bedeutet ein SHL unabhängig von
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in
Richtung des am meisten signifikanten Bits).

===Der Selektionscode===

Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der
Selektion genau gemacht wird.
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.

Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert
nichts und der Fehler bleibt uns bis zur Veröffentlichung erhalten).

<source lang="pascal">
function Select(x, y: integer): longword;
var
PixelData: array [0..8] of longword;
count, i: longword;
begin
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)
y := WINDOW_Y-y;
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);
if y > 0 then if y < WINDOW_Y then dec(y) else dec(y,2);
</source>

Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen
3x3-Box ist.

<source lang="pascal">
glUseProgram(SelShader.prog);
glClearColor(0.0, 0.0, 0.0, 0.0);
glEnable(GL_SCISSOR_TEST);
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer

Render;
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.

glUseProgram(0);
glClearColor(0.1, 0.1, 0.1, 1.0);
glDisable(GL_SCISSOR_TEST);
</source>

Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall
786.432 Pixel in den Framebuffer schreiben?
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als
Freibrief für den Uber-Shader aus if-Abfragen.

Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder
seine vorherige Ordnung.

Jetzt kommt endlich der wirklich interessante Teil.

<source lang="pascal">
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);

count := 0;

for i := 0 to 8 do
begin
if PixelData[4] = PixelData[i] then inc(count);

if count > 3 then
begin
{$ifdef ENDIAN_BIG}
result := (PixelData[4] shr 8)
{$else}
result := PixelData[4] and $FFFFFF;
{$endif}
exit;
end;
end;

// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.
result := 0;
end;
</source>

Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von
OpenGL) - und in 9 DWords geschrieben.
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result
geschrieben und die Funktion kehrt zurück.
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0
gesetzt.

Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu
Erkennen:

[[Datei:AAc-Beispiel.png|center]]

Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die
gezeichnete Größe von 2x2 Pixeln.

Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn
ihr jetzt nur Bahnhof versteht.
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM
schreiben (so kommt man auch an sein wohlverdientes Feedback).

Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte
neben dem Hintergrund nicht genug sind :-)

===Ergänzung: 32/16 Bit Farbtiefe===

32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei
inklusive Unterscheidung zwischen BE und LE überflüssig macht:

<source lang="pascal">
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);
</source>

<source lang="pascal">
if count > 3 then
begin
result := PixelData[4];
exit;
end;
</source>

Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)

Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.
Daraus folgt? Genau - wir brauchen sowieso den 24 Bit-Code für solche Härtefälle.
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt
und wir können getrost auf 24 Bit setzen.

Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest
während der Selektion aktiviert ist, werden selbst mit einer kulanten
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian
jedes 256ste.

Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts
auskommt.
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial
nicht weiter zu behandeln.

==Shaderlose Variante (Anregung)==

===Einleitung===

In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader
laufen.
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst
nichts mehr.

Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest
bestanden und damit die Stencilmaske geformt haben.
Nun aber zum grundlegenden Thema:

Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.

===Immediate Mode===

Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:

<source lang="pascal">
procedure Render(mode)

if mode = rendermode
Texturen aktivieren
Lighting aktivieren
usw.
if mode = selection
Texturen deaktiveren
Lighting deaktivieren
usw.

foreach i in models
if mode = rendermode
Normale Farbe[i] setzen oder Textur binden
if mode = selection
glColor3ubv(@i) // nur Little Endian...

Farblose(!) Geometrie[i] zeichnen
</source>

Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber
leider niemals erreicht wird ist maximale Performance.
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen
von Daten verarbeitet werden sollen.

===Vertex Array / VBO===

Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder
mehrere Optionen gibt.
Die Displaylisten, die im Shaderteil verwendet werden, sind
state complete. Das bedeutet, sie enthalten alle Informationen, die der
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas
absurdes zu tun.

Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und
Listen mit eingebauten Selektionsfarben.
Bei dieser Methode wird die benötigte Geometrie verdoppelt - mit anderen
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich
wieder beim Immediate Mode landen und hättet trotz Listen, die durch die
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,
nichts gewonnen.

Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:

# Der Treiber muss seine Daten "am Stück" erhalten können.
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.
# Trotzdem müssen die Farben austauschbar sein.

Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich
gut auf VBOs übertragen lassen.

Es werden drei Arrays erstellt:
* Vertices
* Farbdaten oder Texturkoordinaten
* Selektionsfarben

In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf
unsere Vertices.

glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.

Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken
und ganz nebenbei die caching performance des Treibers zu erhöhen.

==Schlusswort==

Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine
Lösung von vielen ist.
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es
anders!
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum
Tutorial (siehe unten) mal anseht. Neben dglOpenGL und
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).

Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].

Gruß Waran

== Dateien ==
* {{ArchivLink|file=tut_colorpicking_src|text=Quellcode des Beispieles}}
* {{ArchivLink|file=tut_colorpicking_exe|text=Vorkompilierte Version des Beispieles (Windows)}}

{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}
[[Kategorie:Tutorial|ColorPicking]]

SDL CreateCond

2013-01-20T08:06:41Z

End: Die Seite wurde neu angelegt: „ = SDL_CreateCond = ==Name== '''SDL_CreateCond''' - Erstellt eine Thread-Bedingung. ==Delphi-Syntax== function SDL_CreateCond: PSDL_Cond; ==Beschreibung=…“

= SDL_CreateCond =

==Name==
'''SDL_CreateCond''' - Erstellt eine Thread-Bedingung.

==Delphi-Syntax==
function SDL_CreateCond: PSDL_Cond;

==Beschreibung==

Erstellt eine neue Thread-Bedingung.

SDL KillThread

2013-01-20T08:02:31Z

End: kleiner Link zu SDL_WaitThread im Hinweis

= SDL_KillThread =

==Name==

'''SDL_KillThread''' - löscht einen Thread sofort.

==Delphi-Spezifikation==
procedure SDL_KillThread( thread : PSDL_Thread );

==Parameter==

{| border="1" rules="all"
! ''thread''
| Der Thread der gelöscht werden soll.
|}

==Beschreibung==

SDL_KillThread löscht den Thread sofort, ohne auf dessen Beendigung zu warten.

Sollte nicht verwendet werden, wenn der Thread Dateioperationen durchführt, da diese sonst sofort abgebrochen werden und Dateifragmente entstehen. Bei einer try-finally Konstruktion wird finally nicht aufgerufen!

==Hinweis==

Durch einen Bug in SDL 1.2 wird der vom Thread reservierte Speicher nicht gelöscht! Die einzige Möglichkeit einen Thread zu löschen und den Speicher zu löschen ist '''SDL_WaitThread'''[[http://wiki.delphigl.com/index.php/SDL_WaitThread]].

SDL KillThread

2013-01-20T08:00:24Z

End: Die Seite wurde neu angelegt: „= SDL_KillThread = ==Name== '''SDL_KillThread''' - löscht einen Thread sofort. ==Delphi-Spezifikation== procedure SDL_KillThread( thread : PSDL_Thread )…“

Deferred Shading

2013-01-13T09:39:34Z

End: MRT ab OpenGL 2.0 => http://en.wikipedia.org/wiki/Multiple_Render_Targets

= Deferred Shading =

Der Begriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe die Geometrieverarbeitung von der Lichtberechnung getrennt werden kann. Dies erlaubt hunderte Lichtquellen in einer hoch-komplexen Szene.

== Idee ==
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle muss also jedes Objekt gezeichnet werden. Angenommen wir haben ''nL'' Lichtquellen und ''nO'' Objekte, dann liegt die Anzahl der Rendercalls bei ''O(nO * nL)''. Natürlich ist es möglich mehrere Lichtquellen in einem Pass (z.B. 8 auf einmal) zu berechnen, aber wir gehen von hunderten Lichtquellen aus, es sind also mehrere Passes notwendig und die Geometrie müsste entsprechend mehrfach verarbeitet werden.

''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jeden Licht-Pass neu zu renderen, werden zunächst für jeden Pixel alle beleuchtungsrelevanten Daten (z.B. 3D-Position, Normale, Textur-Farbe, etc.) in ein oder mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Die eigentliche Lichtberechnung kann nun durchgeführt werden indem ein bildschirmfüllendes Quad bzw. die Lichtgeometrie (Kugel für ein Punktlicht, Kegel für ein Spotlight) gerendert wird. Für jeden Pixel werden die Daten aus dem G-Buffer ausgelesen und die Beleuchtung entsprechend dieser Daten berechnet. Die Zahl der Rendercalls liegt bei diesem Ansatz nur noch bei ''O(nO + nL)''. Mit dieser Methode sind hunderte Lichter gleichzeitig in einer hoch-komplexen Szene möglich.

Das Verfahren ist nur dann sinnvoll, wenn man es mit einer sehr komplexen Geometrie und sehr vielen Lichtquellen zu tun hat. Hat man zum Beispiel zwar viele Lichtquellen, aber eine einfache Geometrie, kann bereits ein einfacher Depth-Only-Pass zum initialisieren des Z-Buffers verhindern, dass für unsichtbare Pixel unnötige Lichtberechnungen durchgeführt werden.

== Vor-/Nachteile ==

'''Vorteile:'''
* Viele Lichtquellen bei komplexer Geometrie möglich
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field, etc.) können einfach angeschlossen werden, da bereits alle benötigten Informationen aufbereitet vorliegen.
* Lichtberechnung mit reduzierter Auflösung möglich (sinnvoll z.B. bei FSAA, siehe [[Inferred Lighting]])

'''Nachteile:'''
* Kein Hardware Anti-Aliasing möglich
* Transparente Objekte müssen getrennt behandelt werden (Abhilfe schafft [[Inferred Lighting]])
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich (ab DirectX 9 kompatiblem Grafikchip; OpenGL Version 2.0)

== Screenshots des G-Buffer ==
Um sich den Inhalt des G-Buffers besser vorstellen zu können, sind hier vier einzelnen Texturen eines G-Buffers.
<gallery widths="150" heights="80">
Datei:DeferredShading-Position.png|Positionstextur
Datei:DeferredShading-Albedo.png|Albedo bzw. Farbpuffer
Datei:DeferredShading-Normal.png|Normal-Puffer
Datei:DeferredShading-Specular.png|Specular-Puffer
</gallery>
[[Datei:DeferredShading-Final.png|200px|thumb|center|Finales Bild]]

== Implementierung ==
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.

'''Schritt 1: Erstellen der Rendertargets'''
<source lang="delphi">
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);
FRT_1_Albedo.BitDepth := adF64Bit;
FRT_1_Albedo.SetSize(surfacew, surfaceh);
FRT_1_Albedo.Filter := atPoint;

FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);
[...]

FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);
[...]

FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);
[...]
</source>

'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)''' 
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.
<source lang="c">
//Fragment Shader

struct fs_res {
float4 position: COLOR1;
float4 normal: COLOR2;
float4 albedo: COLOR0;
};

fs_res fs_std_geometry(
float3 viewpos: TEXCOORD0,
float3 normal: TEXCOORD1
)
{
fs_res OUT;

OUT.position = float4(viewpos, 1.0f);
OUT.normal = float4(normal, 1.0f);
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);

return OUT;
}

//Vertex Shader

struct vs_res {
float4 pos: POSITION;
float3 viewpos : TEXCOORD0;
float3 normal: TEXCOORD1;
};

vs_res vs_std_geometry(
float3 position : POSITION,
float3 normal: NORMAL,
uniform float4x4 modelview,
uniform float4x4 modelviewproj
)
{
vs_res OUT;

OUT.pos = mul(float4(position, 1.0f), modelviewproj);
OUT.viewpos = mul(float4(position, 1.0f), modelview);
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));

return OUT;
}
</source>

'''Schritt 3: Daten in G-Buffer Rendern'''
<source lang="delphi">
//Activate the G-Buffers
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);

FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);

//Activate the shaders
FTransformShader.FragmentShader.BindEffect;
FTransformShader.VertexShader.BindEffect;

FScene.Draw(FCamera, nil, 0);

//Deactivate the shaders
FTransformShader.VertexShader.UnbindEffect;
FTransformShader.FragmentShader.UnbindEffect;

FDraw.AdAppl.SetRenderTarget(2, nil);
FDraw.AdAppl.SetRenderTarget(1, nil);
FDraw.AdAppl.SetRenderTarget(0, nil);
</source>

'''Schritt 4: Einfacher Direktionaler Licht-Shader''' 
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.
<source lang="c">
struct ps_light_res {
float4 color: COLOR0;
};

ps_light_res ps_light_geometry(
float3 screenpos: TEXCOORD0,
float3 viewpos: TEXCOORD1,
float3 lightdir: TEXCOORD2,

uniform sampler sPosition,
uniform sampler sNormal,
uniform sampler sAlbedo,
uniform float4 lightcolor
)
{
ps_light_res OUT;

float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));

OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);

return OUT;
}

struct vs_light_res {
float4 pos: POSITION;
float3 screenpos: TEXCOORD0;
float3 viewpos: TEXCOORD1;
float3 lightdir: TEXCOORD2;
};

vs_light_res vs_light_geometry(
float3 position : POSITION,
uniform float4x4 modelview,
uniform float4x4 modelviewproj,
uniform float3 lightdir
)
{
vs_light_res OUT;

OUT.pos = float4(position, 1.0f);
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);
OUT.viewpos = mul(position, modelview);
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));

return OUT;
}
</source>

'''Schritt 5: Lichtquellen in das Composite RT rendern'''
<source lang="delphi">
//Render a directional light using a quad
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1);

FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);

FLightShader.FragmentShader.BindEffect;
FLightShader.VertexShader.BindEffect;

//Render a blue light
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));
FQuad.BlendMode = bmAdd;
FQuad.Draw(nil);

FLightShader.FragmentShader.UnbindEffect;
FLightShader.VertexShader.UnbindEffect;
</source>

'''Schritt 6: Das Ergebnis Zeichnen''' 
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.

==Weblinks==
* http://www.gamedev.net/reference/programming/features/defRender/

==Siehe auch==
* [[Shader]]
* [[FBO]]
* [[Inferred Lighting]]
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]

glEnable

2013-01-12T14:42:45Z

End: GL_FALSE = GL_TRUE? in Wahrheit GL_MULTISAMPLE (siehe OpenGL.org), fehlt aber noch ein Eintrag unten.

= glEnable, glDisable =

== Name ==
'''gEnable, glDisable''' - Aktiviert bzw. deaktiviert eine server-seitige Fähigkeit.

== Delphi-Spezifikation ==
procedure '''glEnable'''(''cap'': TGLEnum);
procedure '''glDisable'''(''cap'': TGLEnum);

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''cap''</td>
<td>Symbolische Konstante der zu (de)aktivierenden GL-Fähigkeit.</td>
</tr>
</table>

== Beschreibung ==
'''glEnable''' und '''glDisable''' aktivieren bzw. deaktivieren verschiedene Fähigkeiten, deren momentane Einstellung entweder mit [[glIsEnabled]] oder [[glGet]] ermittelt werden kann. Die Vorgabe für alle Einstellungen (Ausgenommen '''GL_DITHER''' und '''GL_MULTISAMPLE''', die beide '''GL_TRUE''' sind) ist '''GL_FALSE'''.

Beide Befehle bekommen als Argument die symbolische Konstante der OpenGL-Fähigkeit übergeben, die umgeschaltet werden soll. Gültig sind dabei folgende Werte :

=== GL_ALPHA_TEST ===
Wenn aktiviert, wird der Alphatest ausgeführt. Siehe [[glAlphaFunc]].

=== GL_AUTO_NORMAL ===
Wenn aktiviert, werden automatisch Normalen generiert, wenn '''GL_MAP2_VERTEX_3''' oder '''GL_MAP2_VERTEX_4''' zur Erstellung von Vertices genutzt werden. Siehe [[glMap2]].

=== GL_BLEND ===
Wenn aktiviert werden ankommenden RGBA-Farben mit den Werten die sich im Farbpuffer befinden vermischt. Siehe [[glBlendFunc]].

=== GL_CLIP_PLANEi ===
Wenn aktiviert, wird die Geometrie gegen die nutzerdefinierte Schnittfläche ''i'' geschnitten. Siehe [[glClipPlane]].

=== GL_COLOR_LOGIC_OP ===
Wenn aktiviert, werden die momentan gewählten logischen Operationen auf ankommenden RGBA-Farben und Farbpuffer-Werte angewendet. Siehe [[glLogicOp]].

=== GL_COLOR_MATERIAL ===
Wenn aktiviert, benutzen einer oder mehrere Materialparameter die aktuelle Farbeinstellung. Siehe [[glColorMaterial]].

=== GL_COLOR_TABLE_EXT ===
Wenn aktiviert, werden Farbbild-Komponenenten auf eine Farbtabelle verteilt, die vor einer Windung stattfindet. Siehe [[glColorTable]].

=== GL_CONVOLUTION_1D_EXT ===
Wenn aktiviert, wird die ein-dimensionale Windung während des Pixeltransfers durchgeführt. Siehe [[glConvolutionFilter1DEXT]].

=== GL_CONVOLUTION_2D_EXT ===
Wenn aktiviert, wird die zwei-dimensionale Windung während des Pixeltransfers durchgeführt. Siehe [[glConvolutionFilter2DEXT]].

=== GL_CULL_FACE ===
Wenn aktiviert, werden Polygone entsprechend ihrer Zeichnungsrichtung (Wicklung wäre der korrekt Ausdruck --[[Benutzer:Sascha Willems|Sascha Willems]] 13:05, 9. Jul 2004 (CEST)) (in Fensterkoordinaten) ausgeschlossen. Siehe [[glCullFace]].

=== GL_DEPTH_TEST ===
Wenn aktiviert werden Tiefenvergleiche getätigt und der Tiefenpuffer aktualisiert. Man beachte, dass selbst dann, wenn ein Tiefenpuffer existiert und die Tiefenmaske ungleich null ist, der Tiefenpuffer nicht aktiviert wird, wenn der [[Tiefentest]] inaktiv ist. Siehe [[glDepthFunc]] und [[glDepthRange]].

=== GL_DITHER ===
Wenn aktiviert, werden Farbkomponenten oder -indizes gedithert (siehe [[Dithering]]).

=== GL_FOG ===
Wenn aktiviert, wird die Nebelfarbe in den Farbwert nach der Texturierung gemischt. Siehe [[glFog]].

=== GL_FOG_OFFSET_EXT ===
Wenn aktiviert wird ein Versatz zum Z-Wert, der zur Berechnung des Nebels genutzt wird, addiert. Siehe [[glFog]].

=== GL_INDEX_LOGIC_OP ===
Wenn aktiviert, werden die momentan gewählten logischen Operationen auf einkommende Index- und Farbpufferindizes angewandt. Siehe [[glLogicOp]].

=== GL_INTERLACE_EXT ===
Wenn aktiviert, wird ein Bild als interlaced (zu Deutsch : verschachtelt) angesehen. Jede Reihe ''m'' des Bildes wird behandelt als wäre sie Reihe 2 * ''m''. Wenn das Quellbild also eine Höhe von ''h'' Reihen hat, erweitert dies die Höhe des Bildes effektiv auf 2 * ''h'' - 1. Wo Fehler durch die Angabe ungültiger Bilddimensionen entstehen (z.B. [[glTexImage2D]], wird die resultierende Dimension geprüft, nicht die Dimension des Quellbildes. Dieses Token hat keinen Effekt auf Bild-Leseoperationen (Siehe [[glEnable#GL_INTERLACE_READ_I3D|GL_INTERLACE_READ_I3D]].

=== GL_INTERLACE_READ_I3D ===
Wenn aktiviert, werden Bilder im Framepuffer als interlaced angesehen. Jede Reihe ''m'' des Bildes wird behandelt als wäre sie Reihe 2 * ''m''. Wenn das Bild im Framepuffer eine Höhe von ''h'' Reiehen hat, wird dieses effektiv auf eine Höhe von 2 * ''h'' - 1 vergrößert. Dieses Token betrifft nur [[glReadPixels]] und [[glCopyPixels]].

=== GL_LIGHTi ===
Wenn aktiviert, wird die Lichtquelle ''i'' in die Berechnung der Beleuchtungsgleichung mit einbezogen. Siehe [[glLightModel]] und [[glLight]].

=== GL_LIGHTING ===
Wenn aktiviert, werden die aktuellen Beleuchtungsparameter genutzt um die Vertex- oder Indexfarbe zu berechnen. Ansonsten wird einfach die aktuelle Farbe zw. der aktuelle Index zugewiesen. Siehe [[glMaterial]], [[glLightModel]] und [[glLight]].

=== GL_LINE_SMOOTH ===
Wenn aktiviert, werden Linien mit dem korrekten rechtwinkligen "Eecken" gerendert. Dieser Effekt ist nur bei [[glLineWidth|breiten Linen]] von Bedeutung. Siehe [[OpenGL_Smooth]]
{|
! Aktiviert
! Deaktiviert
|-
|[[Bild:GL LINE SMOOTH_aktiviert.png]]
|[[Bild:GL LINE SMOOTH deaktiviert.png]]
|}
''In vierfacher Vergrößerung''

=== GL_LINE_STIPPLE ===
Wenn aktiviert, wird das aktuelle Punktierungsmuster für das Zeichnen von Linien verwendet. Siehe [[glLineStipple]].

=== GL_MAP1_COLOR_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] RGBA-Werte. Siehe [[glMap1]].

=== GL_MAP1_INDEX ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] Farb-Indizes. Siehe [[glMap1]].

=== GL_MAP1_NORMAL ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] Normalen. Siehe [[glMap1]].

=== GL_MAP1_TEXTURE_COORD_1 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] s-Texturkoordinaten. Siehe [[glMap1]].

=== GL_MAP1_TEXTURE_COORD_2 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] s- und t-Texturkoordinaten. Siehe [[glMap1]].
=== GL_MAP1_TEXTURE_COORD_3 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] s-, t- und r-Texturkoordinaten. Siehe [[glMap1]].

=== GL_MAP1_TEXTURE_COORD_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] s-, t-, r- und q-Texturkoordianten. Siehe [[glMap1]].

=== GL_MAP1_VERTEX_3 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] x-, y- und z-Vertexkoordinaten. Siehe [[glMap1]].

=== GL_MAP1_VERTEX_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord1]], [[glEvalMesh1]] und [[glEvalPoint1]] x-, y-, z- und w-Vertexkoordinaten. Siehe [[glMap1]].

=== GL_MAP2_COLOR_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] RGBA-Werte. Siehe [[glMap2]].

=== GL_MAP2_INDEX ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] Farb-Indizes. Siehe [[glMap2]].

=== GL_MAP2_NORMAL ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] Normale. Siehe [[glMap2]].

=== GL_MAP2_TEXTURE_COORD_1 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] s-Texturkoordinaten. Siehe [[glMap2]].

=== GL_MAP2_TEXTURE_COORD_2 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] s- und t-Texturkoordinaten. Siehe [[glMap2]].

=== GL_MAP2_TEXTURE_COORD_3 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] s-, t- und r-Texturkoordinaten. Siehe [[glMap2]].

=== GL_MAP2_TEXTURE_COORD_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] s-, t-, r- und q-Texturkoordinaten. Siehe [[glMap2]].

=== GL_MAP2_VERTEX_3 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] x, y und z-Vertexkoordinaten. Siehe [[glMap2]].

=== GL_MAP2_VERTEX_4 ===
Wenn aktiviert, generieren Aufrufe an [[glEvalCoord2]], [[glEvalMesh2]] und [[glEvalPoint2]] x, y, z- und w-Vertexkoordinaten. Siehe [[glMap2]].

=== GL_MULTISAMPLE_EXT ===
Wenn aktiviert, bekommt jeder Pixel im Framepuffer GL_SAMPLES_EXT-Samplepunkte zugewiesen. with it.

=== GL_NORMALIZE ===
Wenn aktiviert, werden via [[glNormal]] angegebene Normalen nach ihrer Transformation auf Einheitslänge skaliert. Siehe [[glNormal]].

=== GL_OCCLUSION_TEST_EXT ===
Wenn aktiviert, wird der Ausschluß-Status (Occlusion, Deutsche Übersetzung ist leider nicht gebräuchlich --[[Benutzer:Sascha Willems|Sascha Willems]] 13:05, 9. Jul 2004 (CEST)) je nach Tiefentest aktualisiert (siehe [[glDepthFunc]]). Der Ausschluß-Status kann mit [[glGetBooleanv]] ausgelesen werden.

=== GL_PIXEL_TEX_GEN_EXT ===
Wenn aktiviert, werden die RGBA-Farben des Bildes genutzt um Texturkoordinaten für das Fragment zu generieren. Siehe [[glPixelTexGenEXT]].

=== GL_POINT_SMOOTH ===
Wenn aktiviert, werden Punkte gefiltert gezeichnet. Ansonsten werden ungefilterte Punkte gerendert. Siehe [[glPointSize]], [[OpenGL_Smooth]].

=== GL_POLYGON_OFFSET_FILL ===
Wenn aktiviert und das Polygon im GL_FILL-Modus gerendert wird, wird ein Versatz zum Tiefenwert der Fragmente des Polygons addiert, bevor der Tiefentest stattfindet. Siehe [[glPolygonOffset]].

=== GL_POLYGON_OFFSET_LINE ===
Wenn aktiviert und das Polygon im GL_LINE-Modus gerendert wird, wird ein Versatz zum Tiefenwert der Fragmente des Polygons addiert, bevor der Tiefentest stattfindet. Siehe [[glPolygonOffset]].

=== GL_POLYGON_OFFSET_POINT ===
Wenn aktiviert, wird ein Versatz zu den Tiefenwerten der Fragmente eines Polygons addiert, bevor der Tiefentest stattfindet, wenn es im GL_POINT-Modus gerendert wird. Siehe [[glPolygonOffset]].

=== GL_POLYGON_SMOOTH ===
Wenn aktiviert, werden Polygone mit korrekter Filterung gezeichnet, indem der Alphawert eines [[Fragment]]es entsprechend der Deckung gesetzt wird. [[Blenden|Blending]] muss ebenfalls aktiviert sein um korrekte Resultate zu erhalten. Siehe [[OpenGL_Smooth]]
{{Hinweis|Funktion ist meist nicht in Hardware verfügbar, es wird häufig auf Softwaremodus umgeschalten und auch dort nicht immer korrekt gezeichnet.}}

=== GL_POLYGON_STIPPLE ===
Wenn aktiviert, wird das aktuelle Polygon-Punktierungs-Muster zum Rendern der Polygone genutzt. Siehe [[glPolygonStipple]].

=== GL_POST_COLOR_MATRIX_COLOR_TABLE_EXT ===
Wenn aktiviert, werden Farbbild-Komponentne in die Farbtabelle gelegt die nach der Farbmatrix kommt. Siehe [[glColorTable]].

=== GL_POST_CONVOLUTION_COLOR_TABLE_EXT ===
Wenn aktiviert, werden Farbbild-Komponenten in eine Farbtabelle gelegt die nach der Windung, aber vor der Farbmatrix kommt. Siehe [[glColorTable]].

=== GL_RESCALE_NORMAL_EXT ===
Wenn aktiviert, werden Normalen mit einem Reskalierungsfaktor multipliziert, nachdem sie in den Augenraum transformiert wurden und bevor sie normalisiert werden. Dieser Faktor wird aus der obersten Reihe der inversen umgestellten Modelansichtsmatrix berechnet.

=== GL_SAMPLE_ALPHA_TO_MASK_EXT ===
Wenn aktiviert, wird der Alphawert eines Fragmentes genutzt, um einen temporären Maskenwert zu erstellen, welcher mit dem Maskenwert des Fragmentes verUNDet wird.

=== GL_SAMPLE_ALPHA_TO_ONE_EXT ===
Wenn aktiviert, wird der Alphawert der Fragmente durch den maximal verfügbaren Alphawert ersetzt.

=== GL_SAMPLE_MASK_EXT ===
Wenn aktiviert, wird der Wert von '''GL_SAMPLE_MASK_VALUE_EXT''' genutzt, um temporäre Maskenwerte zu erstellen, die dann mit den Maskenwerten der Fragmente geUNDet werden. (AND-Verknüpft werden)

=== GL_SCISSOR_TEST ===
Wenn aktiviert, werden Fragmente verworfen die ausserhalb des Scissor-Rechtecks liegen. Siehe [[glScissor]].

=== GL_SEPARABLE_2D_EXT ===
Wenn aktiviert und GL_CONVOLUTION_2D_EXT deaktiviert ist, wird zweidimensionale Wicklung mit separierbarem Filter während des Pixeltransfers durchgeführt. Siehe [[glSeparableFilter2D]].

=== GL_STENCIL_TEST ===
Wenn aktiviert, werden Stempeltests durchgeführt und der Stencilpuffer aktualisiert. Siehe [[glStencilFunc]] und [[glStencilOp]].

=== GL_TEXTURE_1D ===
Wenn aktiviert, wird eindimensionale Texturierung angewandt (es sei denn zweidimensionale Texturierung wurde auch aktiviert). Siehe [[glTexImage1D]].

=== GL_TEXTURE_2D ===
Wenn aktiviert, wird zweidimensionale Texturierung angewandt (es sei denn dreidimensionale Texturierung wurde auch aktiviert). Siehe [[glTexImage2D]].

=== GL_TEXTURE_3D(''_EXT'') ===
Wenn aktiviert, wird dreidimensionale Texturierung angewandt. Siehe [[glTexImage3D]].

=== GL_TEXTURE_COLOR_TABLE_EXT ===
Wenn aktiviert, wird die gefilterte Texturenfarbe an die Farbtabelle für Texturen angepasst, bevor die Umgebung mit der Fragmentfarbe vermischt wird. Siehe [[glColorTable]].

=== GL_TEXTURE_GEN_Q ===
Wenn aktiviert, wird die q-Texturkoordinate anhand der via [[glTexGen]] definierten Funktion zur Texturgenerierung berechnet. Ansonsten wird die aktuell angegebene q-Texturkoordinate genutzt. Siehe [[glTexGen]].

=== GL_TEXTURE_GEN_R ===
Wenn aktiviert, wird die r-Texturkoordinate anhand der via [[glTexGen]] definierten Funktion zur Texturgenerierung berechnet. Ansonsten wird die aktuell angegebene r-Texturkoordinate genutzt. Siehe [[glTexGen]].

=== GL_TEXTURE_GEN_S ===
Wenn aktiviert, wird die s-Texturkoordinate anhand der via [[glTexGen]] definierten Funktion zur Texturgenerierung berechnet. Ansonsten wird die aktuell angegebene s-Texturkoordinate genutzt. Siehe [[glTexGen]].

=== GL_TEXTURE_GEN_T ===
Wenn aktiviert, wird die t-Texturkoordinate anhand der via [[glTexGen]] definierten Funktion zur Texturgenerierung berechnet. Ansonsten wird die aktuell angegebene t-Texturkoordinate genutzt. Siehe [[glTexGen]].

== Erweiterungen ==
Einige Routinen und Konstanten für diese Funktion sind Teil einer Erweiterung, also nicht Teil des GL-Kerns. Die folgenden Erweiterungen müssen in der durch [[glGetString]] mit dem Argument '''GL_EXTENSIONS''' gelieferten Zeichenkette enthalten sein, damit diese genutzt werden können.

=== GL_EXT_color_table ===
'''GL_COLOR_TABLE_EXT''', '''GL_POST_CONVOLUTION_COLOR_TABLE_EXT''' und '''GL_POST_COLOR_MATRIX_COLOR_TABLE_EXT''' sind Teil der Erweiterung [[GL_EXT_color_table]].

=== GL_EXT_convolution ===
'''GL_CONVOLUTION_1D_EXT''', '''GL_CONVOLUTION_2D_EXT''' und '''GL_SEPARABLE_2D_EXT''' sind Teil der Erweiterung [[GL_EXT_convolution]].

=== GL_EXT_fog_offset ===
'''GL_FOG_OFFSET_EXT''' ist Teil der Erweiterung [[GL_EXT_fog_offset]].

=== EXT_interlace ===
'''GL_INTERLACE_EXT''' ist Teil der Erweiterung [[GL_EXT_interlace]].

=== EXT_interlace_read ===
'''GL_INTERLACE_READ_I3D''' ist Teil der Erweiterung [[GL_EXT_interlace_read]].

=== GL_EXT_multisample ===
'''GL_MULTISAMPLE_EXT''', '''GL_SAMPLE_ALPHA_TO_MASK_EXT''', '''GL_SAMPLE_ALPHA_TO_ONE_EXT''' und '''GL_SAMPLE_MASK_EXT''' sind Teil der Erweiterung [[GL_EXT_multisample]].

=== GL_EXT_occlusion_test ===
'''GL_OCCLUSION_TEST_EXT''' ist Teil der Erweiterung [[GL_EXT_occlusion_test]].

=== GL_EXT_pixel_texture ===
'''GL_PIXEL_TEX_GEN_EXT''' ist Teil der Erweiterung [[GL_EXT_pixel_texture]].

=== GL_EXT_rescale_normal ===
'''GL_RESCALE_NORMAL_EXT''' ist Teil der Erweiterung [[GL_EXT_rescale_normal]].

=== GL_EXT_texture3D ===
'''GL_TEXTURE_3D_EXT''' ist Teil der Erweiterung [[GL_EXT_texture3D]].

=== GL_EXT_texture_color_table ===
'''GL_TEXTURE_COLOR_TABLE_EXT''' ist Teil der Erweiterung [[GL_EXT_texture_color_table]].

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird generiert, wenn ''cap'' kein gültiges Token ist.

'''GL_INVALID_OPERATION''' wird generiert, wenn [[glPixelTransfer]] zwischen [[glBegin]] und dem passenden [[glEnd]] aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGet]]

[[glIsEnabled]]

(Die zu übergebenden Argumente können in der Beschreibung zu den beiden Funktionen nachgelesen werden.)

== Siehe auch ==
[[glAlphaFunc]], [[glBitmap]], [[glBlendFunc]], [[glClipPlane]], [[glColorMaterial]], [[glColorTable]], [[glCopyColorTable]], [[glCopyPixels]], [[glCopyTexImage1D]], [[glCopyTexImage2D]], [[glCopyTexSubImage1D]], [[glCopyTexSubImage2D]], [[glCopyTexSubImage3D]], [[glCullFace]], [[glDepthFunc]], [[glDepthRange]], [[glDrawPixels]], [[glEnableClientState]], [[glFog]], [[glGet]], [[glGetString]], [[glIsEnabled]], [[glLight]], [[glLightModel]], [[glLineWidth]], [[glLineStipple]], [[glLogicOp]], [[glMap1]], [[glMap2]], [[glMaterial]], [[glNormal]], [[glPointSize]], [[glPolygonMode]], [[glPolygonOffset]], [[glPolygonStipple]], [[glSampleMaskEXT]], [[glScissor]], [[glStencilFunc]], [[glStencilOp]], [[glTexGen]], [[glTexImage1D]], [[glTexImage2D]], [[glTexImage3D]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]]

[[Kategorie:GL|Enable]]
[[Kategorie:GL1.0|Enable]]
[[Kategorie:GL3|Enable]]

Tutorial glsl

2012-12-16T10:41:16Z

End: nur zwei kleine Fehler ^^

=Einleitung=
Hallo und willkommen bei meiner "Einführung" in GLSL (kurz für "Open'''GL''' '''S'''hading '''L'''anguage"), der offiziellen Hochlevel-Shadersprache von OpenGL. In diesem umfangreichen Dokument werde ich versuchen, sowohl auf die Nutzung (sprich das Laden und Anhängen von Shadern im Quellcode), als auch auf die Programmierung von Shadern selbst einzugehen, inklusive aller Sprachelemente der OpenGL Shadersprache. Es wird also auch recht viele Informationen zu der C-ähnlichen Programmstruktur und den von GLSL angebotenen Variablen und Attributen gehen. Am Ende dieser Einführung sollten alle die, die sich für das Thema interessieren, in der Lage sein, zumindest einfache Shader zu schreiben und auch in ihren Programmen zu nutzen. Außerdem soll dieses Dokument gleichzeitig als ein deutsches "Pendant" zu den von Khronoes veröffentlichten Shaderspezifikationen, und damit als alltägliches Nachschlagewerk, dienen.

==Vorkenntnisse==
Wie auch schon mein ARB_VP-Tutorial richtet sich auch diese Einführung aufgrund ihrer Thematik eher an die fortgeschritteneren GL-Programmierer und neben sehr guten GL-Kenntnissen sollten sich alle, die sich daran versuchen wollen, mit den technischen Hintergründen der GL, wie z.B. dem Aufbau der Renderpipeline auskennen. Weiterhin sind C-Kenntnisse absolut erforderlich, da die Shader ja in einer an ANSI-C angelehnten Syntax geschrieben werden. Auch Begriffsdefinitionen zu Vertex oder Fragment werden zum Verständis dieser Einführung benötigt. Wer also noch am Anfang seiner GL-Karriere steht, dem wird dieses Dokument nicht viel nützen. Ganz nebenbei solltet ihr auch noch eine gehörige Portion Zeit (am besten nen kompletten Nachmittag) mitbringen, denn die folgende Kost ist nicht nur umfangreich, sondern auch manchmal recht schwer verdaulich.

=Was ist GLSL?=
Wie Eingangs kurz angesprochen handelt es sich bei GLSL um eine Shadersprache, also um eine Hochsprache, in der man die programmierbaren Teile aktueller Grafikbeschleuniger nach eigenem Belieben programmieren kann. Sie stellt quasi den Nachfolger zu den in Assembler geschriebenen Vertex- und Fragmentprogrammen ([[GL_ARB_vertex_program]]/[[GL_ARB_fragment_program]]) dar und basiert auf ANSI C, erweitert um Vektor- und Matrixtypen sowie einige C++-Mechanismen.

Die in GLSL geschriebenen Programme nennen sich, angepasst an die Terminologie von RenderMan und DirectX, [[Shader]] (im Gegensatz zu "Programme" bei ARB_VP/FP) und werden entweder auf Eckpunkte (VertexShader), Fragmente (FragmentShader) angewendet, oder (neuerdings, ab Shadermodell 4.0) auch genutzt um Geometrie zu erstellen (Geometryshader). Andere Teile der Renderpipeline (z.B. die Rasterisierung) können momentan noch nicht durch Shader beeinflusst werden, was allerdings in Zukunft noch kommen kann.

==Voraussetzungen==

GLSL wurde 2005 mit OpenGL 1.5 eingeführt. Während es in Sachen Treiber- und Hardwareunterstützung anfänglich noch dürftig aussah, wird man inzwischen keine Grafikkarte mehr kaufen können die nicht zumindest Vertex- und Fragmentshader beherscht. Geometrieshader hingegen sind relativ neu und wurden erst mit Shadermodell 4.0 eingeführt, hier ist es also unter Umständen noch möglich dass selbst aktuelle Treiber/Karten keine Geometrieshader beherrschen.

Natürlich benötigt man auch einen passenden OpenGL-Header der die für GLSL nötigen Funktionen exportiert. Ich verweise dazu auf unseren eigenen OpenGL-Header [[DGLOpenGL.pas]], der peermanent auf dem aktuellsten Stand gehalten wird und auch Support für Geometrieshader mitbringt.

==Extensions==

Die GL-Shadersprache "besteht" in ihrer aktuellen Version aus folgenden Extensions, fürs Verständnis wäre es nicht schlecht, wenn ihr euch zumindest die Einleitungen dazu durchlest :
* [[GL_ARB_shader_objects]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shader_objects.txt Originalspezifikation])
: Definiert die API-Aufrufe, die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.
* [[GL_ARB_vertex_shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt Originalspezifikation])
: Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.
* [[GL_ARB_fragment_shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt Originalspezifikation])
: Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.
* [[GL_ARB_shading_language_100]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shading_language_100.txt Originalspezifikation])
: Gibt die unterstützte Version von glSlang an, momentan 1.00.

'''Hinweis''' : Seit OpenGL 2.0 ist GLSL Teil des Kerns. Wenn die Karte also OpenGL 2.0 unterstützt, dann unterstützt sie auch (zumindest in Software) Vertex- und Fragmentshader.

==Sprachversionen==

Neben der OpenGL-Version und dem vorhandenen Shadermodell (das eher an DirectX ausgerichtet ist), bietet auch GLSL verschiedene Versionen, die entsprechend erweiterte Funktionalität bieten.

Auslesen kann man die verfürgbare GLSL-Version wie folgt:

glGetString(GL_SHADING_LANGUAGE_VERSION)

Erst ab Version 1.4. kann man davon ausgehen dass GLSL alle Features des Shadermodells 4.0 liefert, ab 1.3 grob gesagt Shadermodell 3.0 (bei GLSL lässt sich das leider nicht so leicht unterteilen).

Außerdem kann man seinem Shader eine Versionsnummer verpassen. Sollte der Shadercompiler (also Treiber bzw. Hardware) diese Version nicht unterstützen, gibt dieser eine Fehlermeldung heraus:

#version 1.50

''(Hinweis: Muss am Anfang des Shaders stehen)''

==Objekte==

Im Zuge der Vereinheitlichung der GL wird immer häufiger in Objekte gekapselt, deren API dann auch aneinander angelehnt ist. Ziel ist, dabei die Programmierung der GL uniform zu machen, so dass z.B. zwischen dem Erstellen und Verwalten eines Vertex-Buffer-Objektes oder eines Shader-Objektes kaum ein Unterschied besteht (demnächst kommen dann auch Pixel-Buffer-Objekte dazu). Mit glSlang wurden dann im Zuge dieser Aktion zwei neue Objekte eingeführt, deren Definition ihr euch unbedingt einprägen solltet:

* '''Programmobjekt'''
:Ein Objekt, an das die Shader später angebunden werden. Bietet Funktionalität zum Linken der Shader und prüft dabei die Kompatibilität zwischen Vertex- und Fragmentshader.

* '''Shaderobjekt'''
:Dieses Objekt verwaltet den Quellcodestring eines Shaders und ist entweder vom Typ '''GL_VERTEX_SHADER''', '''GL_FRAGMENT_SHADER_ARB''' oder '''GL_GEOMETRY_SHADER'''.

==Ressourcen==

Die Shadersprache ist keinesfalls final und es wurden bereits diverse Ausdrücke für zukünftige Verwendung reserviert, denn ein Ziel bei ihrer Entwicklung war es, sie so zukunftsorientiert zu gestalten, dass auch Grafikkarten der nächsten und übernächsten Generation voll ausgenutzt werden können. Damit einher geht die Tatsache, dass sich die Spezifikationen in Zukunft ändern/erweitern werden, weshalb man da immer einen Blick hineinwerfen sollte. Die Anlaufstelle dafür ist die [http://www.opengl.org/documentation/specs/ Spezifikationenliste auf OpenGL.org].

=GLSL im Programm=
Bevor wir uns mit der Syntax von glSlang beschäftigen, zeige ich euch erstmal, wie ihr Shader in euer Programm einbindet und nutzt. Warum das zuerst? Ganz einfach deshalb, weil ihr dann das, was ihr im glSlang-Syntaxteil lernt, direkt in eurer Testanwendung verwenden könnt. Hoffe diese Entscheidung klingt logisch und findet Anklang.

Zuerst benötigen wir natürlich unsere Objekte. Zum einen ein ''Programmobjekt'', an das unsere Shader gebunden werden, und zwei ''Shaderobjekte'', die den Quellcode unseres Vertex bzw. Fragment Shaders aufnehmen. Dazu wurde eigens der neue "Datentyp" {{INLINE_CODE|glHandle}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandle;
VertexShaderObject : GLhandle;
FragmentShaderObject : GLhandle;

Nach dieser Deklaration können wir dann damit beginnen unsere Objekte zu erstellen. Den Anfang macht das Programmobjekt :

ProgramObject := glCreateProgram;

Die Funktion [[glCreateProgram]] erstellt uns oben ein leeres Programmobjekt und gibt ein gültiges Handle darauf zurück.

Weiter gehts mit der Erstellung unseres Vertex bzw. Fragment Shaders :

VertexShaderObject := glCreateShader(GL_VERTEX_SHADER);
FragmentShaderObject := glCreateShader(GL_FRAGMENT_SHADER);

[[glCreateShader]] dient zur Generierung eines leeren Shaderobjektes. Momentan unterstützt diese Funktion VertexShader und FragmentShader.

Nachdem wir nun also zwei gültige Shaderobjekte haben, wollen wir diese auch mit entsprechendem Quellcode versorgen :

glShaderSource(VertexShaderObject, 1, @ShaderText, @ShaderLength);
glShaderSource(FragmentShaderObject, 1, @ShaderText, @ShaderLength);

Via [[glShaderSource]] setzen wir den Quellcode eines Shaderobjektes ''komplett'' neu. Zum Laden des Quellcodes bietet sich unter Delphi übrigens eine TStringList geradezu an. Es sollte beachtet werden, dass der Quellcode zu diesem Zeitpunkt ''nicht geparst'' wird, also keine Fehleruntersuchung stattfindet.

Der Quellcode wurde jetzt also an unsere Shaderobjekte gebunden und sollte dann natürlich auch noch kompiliert werden :

glCompileShader(VertexShaderObject);
glCompileShader(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShader]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der Shadercompiler (je nach Treiber) recht detaillierte Infos aus. Wie man an diese Infos kommt könnt ihr gleich nachlesen.

Wenn unsere Shader dann kompiliert werden konnten, ist es Zeit, diese an unser anfangs erstelltes Programmobjekt anzuhängen :

glAttachShader(ProgramObject, VertexShaderObject);
glAttachShader(ProgramObject, FragmentShaderObject);

Nachdem die Shaderobjekte nun an das Programmobjekt angehängt wurden, werden diese nicht mehr benötigt und ihre Resourcen können freigegeben werden :

glDeleteShader(VertexShaderObject);
glDeleteShader(FragmentShaderObject);

Am Schluß müssen wir dann noch unsere ans Programmobjekt gebundenen Shader linken :

glLinkProgram(ProgramObject);

Während [[glCompileShader]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgram]] die angehangenen Shader zu einem ausführbaren Shader gelinkt. Folgende Bedingungen führen zu einem '''Linkerfehler''':

* Die Zahl der von der Implementation unterstützten Attributvariablen wurde überschritten
* Der Speicherplatz für Uniformvariablen wurde überschritten
* Die Zahl der von der Implementation angebotenen Sampler wurde überschritten
* Die main-Funktion fehlt
* Die Liste der Varying-Variablen des Vertexshaders stimmt nicht mit der des Fragmentshaders überein
* Funktions- oder Variablenname nicht gefunden
* Eine gemeinsame Globale ist mit unterschiedlichen Werten oder Typen initialisiert worden
* Zwei Sampler unterschiedlichen Typs zeigen auf die selbe Textureneinheit
* Ein oder mehrere angehangene(r) Shader wurden nicht erfolgreich kompiliert

Die Nutzung von glSlang im eigenen Programm ist wie oben erkennbar also nicht wirklich schwer und innerhalb kurzer Zeit realisiert. Natürlich ist es auch möglich z.B. nur einen VertexShader oder nur einen FragmentShader an ein Programmobjekt zu binden.

Noch eine kleine Notiz zum Löschen der Shader mittel [[glDeleteShader]] : Da Shader(objekte) einen Referenzzähler besitzen und erst gelöscht werden wenn diese nirgendwo mehr benötigt werden, ist es nicht falsch diese vor dem Linkvorgang zu löschen. Allerdings spielt es letztendlich keine Rolle ob die Löschanweisung vorher der nachher ausgeführt wird.

==Fehlererkennung==
Natürlich wird es ohne Fehlerausgabe recht schwer, etwaige Probleme in einem Vertex- oder Fragmentshader zu finden. Doch auch in diesem Bereich wurde glSlang recht gut durchdacht und es wurden zwei Funktionen eingeführt, welche im Zusammenspiel die Fehlersuche recht einfach machen, nämlich [[glGetShaderInfoLog]] und [[glGetShader]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH}}. Erstere Funktion liefert uns einen Logstring, während uns letztere Funktion dessen Länge angibt. Der Logstring wird verändert, sobald ein Shader kompiliert oder ein Programm gelinkt wird.

Um die Ausgabe dieses Logs so einfach wie möglich zu machen, bietet es sich an beide in einer einfach Funktion unterzubringen :

<source lang="pascal">function glSlang_GetInfoLog(pShader: GLHandleARB): String;
var
blen, slen: GLInt;
InfoLog: PGLCharARB;

begin
glGetShaderiv(pShader, GL_INFO_LOG_LENGTH , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen * SizeOf(GLCharARB));
glGetShaderInfoLog(pShader, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</source>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetShaderiv}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetShaderInfoLog}} in {{INLINE_CODE|InfoLog}} ausgeben und liefern diesen als Ergebnis zurück.

Wie bereits gesagt wird nur nach dem Kompilieren eines Shaders bzw. dem Linken eines Programmobjektes ein Infolog erstellt. Es bietet sich dadurch an, direkt danach einen solchen Aufruf zu machen :

glCompileShader(VertexShaderObject);
ShowMessage(glSlang_GetInfoLog(VertexShaderObject));

Wenn unser Vertex Shader komplett fehlerfrei kompiliert werden konnte, dann sehen wir als Ergebnis nur einen leeren Dialog. Ist dies nicht der Fall, so werden wir vom Treiber mit recht detaillierten Fehlerinformationen "belohnt", z.B. so :

[[Bild:GLSL_error_vshader.jpg]]

Auch das Infolog nach dem Linken des Programmobjektes dürfte, selbst wenn keine Fehler vorkommen, recht interessant sein, das sieht dann nämlich so aus :

[[Bild:GLSL info programobject.jpg]]

Wie zu sehen, wird uns nach dem erfolgreichen Linken auch gesagt, ob und welcher Shader in Hardware bzw. Software läuft. Für Debuggingzwecke sicherlich eine mehr als brauchbare Information.

==Shader benutzen==
Um den Shader auch für die nächsten Polygone zu benutzen oder Uniformparameter übergeben zu können, ruft man die Funktion
glUseProgram(ProgramObject);
um alle Shader zu deaktivieren, ruft man dieselbe Funktion mit dem Parameter 0.

==Parameterübergabe==
Uniformparameter (mehr dazu später) stellen die Schnittstelle zwischen eurem Programm und dem Shader dar, werden also genutzt um Daten aus dem Programm heraus an einen Shader zu übergeben. Zur Übergabe dieser Parameter bietet OpenGL diverse Funktionen, die alle Abkömmlinge von [[glUniform]] sind. Während mit {{INLINE_CODE|glUniform4f}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fv}} ganze Matrizen schnell und einfach übergeben. Außerdem gibt es nun die Möglichkeit Uniformparameter direkt über ihren Namen, statt wie unter ARB_FP/VP über einen festen Index zu adressieren. Die Funktion [[glGetUniformLocationARB]] gibt anhand des übergebenen Parameternamens dessen Position zurück. Man kann also ganz einfach über den Namen drauf zugreifen :

glUniform3f(glGetUniformLocation(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1i(glGetUniformLocation(ProgramObject, PGLCharARB('texSamplerTMU3')), 3);

Wichtig ist hier, das man je nach Parametertyp auch die passende Anzahl von Argumenten übergibt. Also für einen 4-Komponenten Floatvektor {{INLINE_CODE|glUniform4fARB}} und für einen einfachen Integerwert (z.B. Textureinheit für einen Sampler) glUnifrom1iARB. Auch nicht vergessen dürft ihr, das die Namen der Parameter genauso wie im Shader geschrieben werden müssen, also Groß- und Kleinschreibung beachtet werden muß.

=Die Shadersprache=

Nachdem wir uns mit der Einbindung der glSlang-Shader in unser Programm beschäftigt haben, wollen wir uns in den folgenden Kapiteln um die Sprachelemente von glSlang kümmern. Wie schon gesagt basiert glSlang auf ANSI-C, wurde allerdings um speziell auf den Zielbereich angepasste Vektor- und Matrixtypen und einige C++-Features wie das freie deklarieren von Variablen an jeder Stelle und das Funktionsüberladen auf Basis des Argumenttyps erweitert. Wer sich ein wenig mit C/C++ auskennt sollte also in der nun folgenden Materie keine Probleme bekommen.

'''Obligatorische Hinweise für verwöhnte Delphi-Nutzer : '''
*Wie von C/C++ her gewohnt, spielt auch in glSlang die Groß- und Kleinschreibung eine wichtige Rolle, also bitte achtet darauf. gl_Position ist eine komplett andere Variable als z.B. gl_position.
*Es findet keine automatische Typenkonvertierung statt. Das bedeutet also das float MyFloat = 1 ungültig ist und es in dem Falle float MyFloat = 1.0 heissen muss. Typecasts müssen also immer manuell stattfinden, z.B. MyFloat = float(MyInt).

'''Kleine Programmstrukturkunde für C-Unkundige :''' 
Da sicherlich einige Delpher nie richtig was mit C gemacht haben, zeige ich mal anhand eines kleinen Beispieles (das auf keinen Fall nen brauchbaren Shader darstellt) den grundlegenden Aufbau eines glSlang-Shaders, der natürlich dem Aufbau eines C-Programmes stark ähnelt :
<source lang="glsl">
uniform vec4 VariableA;
float VariableB;
vec3 VariableC;
const float KonstanteA = 256.0;

float MyFunction(vec4 ArgumentA)
{
float FunktionsVariableA = float(5.0);

return float(ArgumentA * (FunktionsVariableA + KonstanteA));
}

// Ich bin ein Kommentar
/* Und ich auch */
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Sieht doch recht bekannt aus, unser Programmaufbau. Delphi und C haben ja so einige Grundlagen gleich, darunter auch der ungefähre Programmaufbau. Ausserhalb jeglicher Funktionen legen wir am Programmanfang unsere Variablen, Konstanten und Attribute fest, die dann ''global'' nutzbar sind, also in jeder Funktion.

Darunter deklarieren wir dann eine kleine Funktion. Wie auch bei den Variablendeklarationen wird hier der Rückgabetyp nicht wie bei Pascal nach dem Funktionsnamen untergebracht, sondern davor. Innerhalb der Funktion können dann wieder Variablen deklariert werden, die dann allerdings ''lokal'', also nur in dieser Funktion nutzbar sind. Vorteil dieser Deklaration ist die Tatsache, dass je nach Grafikkarte nur bestimmt viele globale Variablen deklariert werden können. Wenn möglich sollte man also mit lokalen Vorlieb nehmen. Unsere Funktion gibt dann natürlich noch via return einen Wert zurück, ''was gemacht werden muss'', sofern man diese nicht als void deklariert hat (entspräche dann einer Prozedur in Pascal). Wird dies nicht getan, so spuckt der Compiler einen Fehler aus.

Auch wichtig sind natürlich Kommentare. Erste Variante (Doppelslash) ist auch in der Pascalwelt verfügbar und kommentiert eine einzelne Zeile aus. Die Variante darunter kann man für Kommentarblöcke nutzen (/* .. */) und entspricht den Kommentaren in geschweiften Klammern in Delphi.

Danach kommt dann die '''wichtigste Funktion''' des Shaders, nämlich '''main''', die in keinem Shader fehlen darf. Sie stellt quasi den Programmkörper dar und ist oft auch die einzige Funktion in einem Shader. Sie erhält weder ein Argument, noch gibt sie einen Wert zurück.

Soviel also zum grundlegenden Aufbau eines Shader. Hoffe das jetzt alle die in C nicht so bewandert sind damit klar kommen, und dann bald ihre ersten glSlang-Shader schreiben können.

==Datentypen==

Obwohl einige Datentypen aus C übernommen wurden, sieht man der Typenliste an, das diese speziell auf den 3D-Bereich zugeschnitten wurde. Variablen müssen vor ihrer Nutzung eindeutig deklariert sein, Typecasting erfolgt über Konstruktoren (dazu später mehr). Folgende Datentypen stehen sowohl im Vertex- als auch Fragmentshader zur Verfügung :

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|void
|Für Funktionen die keinen Wert zurückgeben
|-
|bool
|Konditionaler Typ, entweder true (wahr) oder false (falsch)
|-
|int
|Vorzeichenbehafteter vorzeichenbehafteter Integerwert
|-
|uint
|Vorzeichenbehafteter vorzeichenloser Integerwert
|-
|float
|Fließkommaskalar mit Singlegenauigkeit (32 Bit)
|-
|vec2
|2-Komponenten Fließkommavektor
|-
|vec3
|3-Komponenten Fließkommavektor
|-
|vec4
|4-Komponenten Fließkommavektor
|-
|bvec2
|2-Komponenten Booleanvektor
|-
|bvec3
|3-Komponenten Booleanvektor
|-
|bvec4
|4-Komponenten Booleanvektor
|-
|ivec2
|2-Komponenten vorzeichenbehafteter Integervektor
|-
|ivec3
|3-Komponenten vorzeichenbehafteter Integervektor
|-
|ivec4
|4-Komponenten vorzeichenbehafteter Integervektor
|-
|uvec2
|2-Komponenten vorzeichenloser Integervektor
|-
|uvec3
|3-Komponenten vorzeichenloser Integervektor
|-
|uvec4
|4-Komponenten vorzeichenloser Integervektor
|-
|mat2
|2x2 Fließkommamatrix
|-
|mat3
|3x3 Fließkommamatrix
|-
|mat4
|4x4 Fließkommamatrix
|-
|matMxN
|Matrix mit M Spalten und N Zeilen
|}

Die sampler-Typen stellen eine besondere Klasse zum Zugriff auf Texturen dar, und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler2DRect
|Zugriff auf Texturen die nicht 2^n * 2^n entsprechen ("non power-of-two", NPOT)
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|samplerCubeShadow
|Zugriff auf Tiefentextur in einer Cubemap (z.b. für omni-diretionale Lichtquellen)
|-
|sampler2DRectShadow
|Zugriff auf 2D-NPOT-Tiefentextur
|-

|sampler1DArray
|Zugriff auf ein array aus 1D-Texturen
|-
|sampler2DArray
|Zugriff auf ein array aus 2D-Texturen
|-
|sampler1DArrayShadow
|Zugriff auf ein array aus 1D-Tiefentexturen
|-
|sampler2DArrayShadow
|Zugriff auf ein array aus 2D-Tiefentexturen
|-
|samplerBuffer
|Zugriff auf eine Puffertextur (1D-Texutr zum Speichern von Pufferobjekten)
|-
|sampler2DMS
|Zugriff auf eine 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|sampler2DMSArray
|Zugriff auf einarray aus 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|}

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<source lang="glsl">
float temp[3];
</source>
beginnt also bei Index 0 und endet bei Index 2. Im Gegensatz zu C lassen sich Arrays in glSlang allerdings ''nicht bei der Initialisierung vorbelegen''. Wenn ein Array als Parameter einer Funktion deklariert wird, so darf dieses keine Dimensionierung erhalten.

===Strukturen===

Neu ggü. ARB_FP/VP ist nun auch die Möglichkeit, Strukturen in einem Shader zu deklarieren. Vor allem die Übersicht komplexerer Shader kann dadurch stark verbessert werden. Strukturen werden wie gewohnt mit dem Schlüsselwort {{INLINE_CODE|struct}} eingeleitet und können dann zur Typisierung von Variablen genutzt werden. Folgendes Beispiel dürfte die Nutzung verdeutlichen :
<source lang="glsl">
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</source>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<source lang="glsl">
light LightSource[3];
</source>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<source lang="glsl">
LightSource[i].position = vec3(1.0, 1.0, 5.0);
</source>

==Typenqualifzierer==

Zusätzlich zur Typendeklaration kann eine Variable noch einen Typenqualifizerer vorangestellt bekommen, der an den Anfang der Deklaration gehört.

* '''const'''
: Festgelegte (nur lesen) Konstante bzw. nur lesbarer Funktionsparameter.

* '''uniform'''
: Ein den ganzen Shader über gleichbleibender Wert, der eine Schnittstelle zwischen dem Shader und der OpenGL-Anwendung darstellt. Ein Uniformwert wird in der Hauptanwendung an den entsprechenden Shader übergeben und kann dort dann genutzt werden.

* '''attribute'''
: Nur lesbare Werte die eine Verbindung zwischen dem Shader und der OpenGL-VertexAPI darstellen (z.B. VertexParameter eines VertexArrays). Natürlich nur in einem Vertex Shader nutzbar.

* '''varying'''
: Stellt die Verbindung zwischen einem Vertex- und einem FragmentShader dar. Werden im VertexShader geschrieben und dann perspektivisch korrekt über die Primitive interpoliert, um dann im Fragment Shader gelesen werden zu können. Nutzbar sind hier nur die Typen float, vec2, vec3, vec4, mat2, mat3 und mat4, Strukturen und andere Datentypen können nicht varying sein. Die Namen einer varying-Variable müssen sowohl im VertexShader als auch im FragmentShader gleich sein.

* '''in'''
: Für Variablen die an eine Funktion übergeben und dort ausgelesen werden.

* '''out'''
: Für Variablen die von einer Funktion nach außen zurückgegeben werden.

* '''inout'''
: Für Variablen die sowohl an eine Funktion übergeben als auch von dieser zurückgegeben werden.

Um obige Auflistung nicht leer im Raum stehen zu lassen zeige ich ein paar Beispiele die hoffentlich zum Verständnis beitragen :

===Beispiel A===
Vertexnormale soll an einen FragmenShader (interpoliert) übergeben werden :

:Im VertexShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</source>
:Im FragmentShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</source>

===Beispiel B===
Uniformparameter zur nachträglichen Farbänderung der Szene wird im Programm übergeben :

:Im VertexShader :
<source lang="glsl">
uniform vec4 GlobalColor;
...
gl_FrontColor = GlobalColor * gl_Color;
</source>
:Im Programm :

glUniform4fARB(glSlang_GetUniLoc(ProgramObject, 'GlobalColor'), Col[0], Col[1], Col[2], Col[3]);

===Beispiel C===
Konstante zur festen Farbänderung :

:Im VertexShader :
<source lang="glsl">
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</source>
==Konstruktoren==

Um in einem Shader ''Vektoren'' oder ''Matrizen'' mit Werten zu belegen, gibt es sogenannte Konstruktoren (nicht zu verwechseln mit z.B. Klassenkonstruktoren unter Delphi), die im Endeffekt nichts anderes als Funktionen zur Vorbelegung von Vektoren oder Matrizen darstellen. Dabei trägt der Konstruktor den selben Namen wie die Typendeklaration, also lässt sich eine Variable vom Typ {{INLINE_CODE|vec4}} mit dem Konstruktor {{INLINE_CODE|vec4(float, float, float, float)}} initialisieren.

Allerdings hat man sich recht viel Mühe bei dieser Konstruktorgeschichte gemacht, so dass man einen vec4 nicht unbedingt mit einem {{INLINE_CODE|vec4}}-Konstruktor vorbelegen muss, sondern es vielseitige Möglichkeiten gibt. Um dies zu verdeutlichen gibts ein paar Beispiele :
<source lang="glsl">
vec4 Color = vec4(1.0, 0.0, 0.0, 0.0);
vec4 Color = vec4(MyVec3, 1.0);
vec4 Color = vec4(MyVec2_A, MyVec2_B);

vec3 LVec = vec3(MyVec4);
vec2 Tmp = vec2(MyVec3);
</source>

Trotz der recht wenigen Beispiele sollte schnell erkennbar sein, das man hier wirklich sehr viele Kombinationsmöglichkeiten hat, die dann gültig sind ''wenn man mindestens auf die benötigte Anzahl der Argumente kommt''. Im vorletzten Beispiel wird z.B. ein 3-Komponentenvektor aus einem 4-Komponentenvektor initialisiert. Das erzeugt keinen Fehler, sondern führt dazu das {{INLINE_CODE|vec3.x, vec3.y, vec3.z}} aus MyVec4 übernommen werden und MyVec4.w einfach ignoriert wird.

Das Umkehrbeispiel, also
<source lang="glsl">
vec4 Color = vec4(MyVec3)
</source>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<source lang="glsl">
vec4 Color = vec4(MyVec3, 0.0)
</source>
heissen.

Obiges gilt natürlich auch für ''Matrixkonstruktoren'', hier sind z.B. folgende Konstuktoren denkbar, obwohl eigentlich alle Möglichkeiten nutzbar sind, ''solange die benötigte Zahl an Argumenten erreicht wird'' :
<source lang="glsl">
mat4 MyMatrix = mat4(MyVec4, MyVec4, MyVec4, MyVec4);
mat2 MyMatrix = mat4(1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
0.0, 0.0, 0.0, 1.0);
</source>

==Vektor- und Matrixkomponenten==

Was natürlich in keiner Shadersprache fehlen darf, ist der leichte Zugriff auf die einzelnen Komponenten eines Vektors. glSlang bietet, je nach Anwendungsgebiet gleich drei Namensets für den Zugriff auf die Komponenten eines solchen Vektors, welches Set man nutzen will bleibt natürlich frei und ist unabhängig von der Deklaration eines Vektors. Man sollte nur darauf achten, beim gleichzeitigen Zugriff auf mehrere Komponenten im gleichen Namenset zu verbleiben :

* {x, y, z, w}
:Für den Zugriff auf Vektoren die Punkte, Normale oder sonstige Vertexdaten repräsentieren.

* {r, g, b, a}
:Für den Zugriff auf Vektoren die Farbwerte repräsentieren.

* {s, t, p, q}
:Für den Zugriff auf Vektoren die Texturkoordinaten repräsentieren.

Ein paar Beispiele zur Unterstreichung des oben gesagten :
<source lang="glsl">
v4.rgba = vec4(1.0, 0.0, 0.0, 0.0); // gültig
v4.rgzw = vec4(1.0, 1.0, 1.0, 2.0); // Ungültig, da verschiedenen Namensets
v2.rgb = vec3(1.0, 2.0, 1.0); // Ungültig, da vec2 nur r+g besitzt
v2.xx = vec2(5.0, 3.0); // Ungültig, da 2 mal gleiche Komponente
</source>

Auch der Zugriff auf die Komponenten einer Matrix geht leicht von der Hand. Namensets wie bei den Vektoren gibt es hier natürlich keine, aber folgende Beispiele sollen den Zugriff aufzeigen :
<source lang="glsl">
MyMat4[2] = vec4(1.0); // Setzt die 3.Zeile der Matrix komplett auf 1.0
MyMat4[3][3] = 3.5; // Setzt das Element unren rechts auf 3.5
</source>

Ein Zugriff auf Matrixelemente ausserhalb ihrer Dimension (also z.B. MyMat4[4][4]) liefert unvorhersehabre Ergebnise, also sollte man auf diese Fälle prüfen.

==Vektor- und Matrixoperationen==

Wie von C gewohnt sind in glSlang so ziemlich alle Operatoren die man auf Matrizen oder Vektoren anwenden kann überladen, so das man nicht umständlich über selbstgeschriebene Funktionen kombinieren muss. Darüber hinaus ist es in den meisten Fällen auch möglich ohne Konvertierung Fließkommawerte mit kompletten Matrizen oder Vektoren zu kombinieren. Folgende Beispiele zeigen einige der vielfältigen Kombinationsmöglichkeiten auf :
<source lang="glsl">
vec3 dest;
vec3 source;
float factor;

vec3 dest = source + factor;

// Ist gleich
dest.x = source.x + factor;
dest.y = source.y + factor;
dest.z = source.z + factor;
</source>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<source lang="glsl">
vec3 dest;
vec3 source;
mat3 MyMat;

dest = source * MyMat;

// Ist gleich
dest.x = dot(source, MyMat[0]);
dest.y = dot(source, MyMat[1]);
dest.z = dot(source, MyMat[2]);
</source>

Auch hier sind die Möglichkeiten fast unbeschränkt und zeigen wieder wie flexibel glSlang ausgelegt ist.

==Operatoren==

glSlang bietet (momentan) folgende Operatoren, die Liste ist nach ihrer Gewichtung sortiert (Anfang = höchste). Alle ''reservierten'' Operatoren werden erst in kommender Hardware/glSlang-Versionen nutzbar sein :

<div align="center">
{|{{Prettytable_B1}}
!Operatorklasse
!Operatoren
!Assoziation
|-
|Gruppering
|()
| -
|-
|Arrayindizierung Funktionsaufrufe und Konstruktoren Strukturfeldwahl und Swizzle Postinkrement und -dekrement 
|[] () . ++ --
|Links n. Rechts
|-
|Prefixinkrement- und dekrement Einheitlich (~ reserviert)
| ++ -- + - ~ !
|Rechts n. Links
|-
|Mulitplikation (% reserviert)
|* / %
|Links n. Rechts
|-
|Additiv
| + -
|Links n. Rechts
|-
|Bitweises Verschieben (reserviert)
|<< >>
|Links n. Rechts
|-
|Relation
|< > <= >=
|Links n. Rechts
|-
|Vergleich
|== !=
|Links n. Rechts
|-
|Bitweises AND (reserviert)
|&
|Links n. Rechts
|-
|Bitweises XOR (reserviert)
|^
|Links n. Rechts
|-
|Bitweises OR (reserviert)
| <nowiki>|</nowiki>
|Links n. Rechts
|-
|Logisches AND
|&&
|Links n. Rechts
|-
|Logisches XOR
|^^
|Links n. Rechts
|-
|Logisches OR
| <nowiki>||</nowiki>
|Links n. Rechts
|-
|Auswahl
|?:
|Rechts n. Links
|-
|Zuweisung Arithmetrische Zuweisung (Modulis, Shift und bitweise Op. reserviert)
|<nowiki>=</nowiki> <nowiki>+= -= *= /= %=</nowiki> <nowiki><<= >>= &= ^= |=</nowiki>
|Rechts n. Links
|-
|Aufzählung
|,
|Links n. Rechts
|-
|}
</div>

==Funktionen==

Ein großer Vorteil von Hochsprachen ist u.A. die Möglichkeit oft genutzte Codeteile in Funktionen (bzw. auch Prozeduren unter Pascal) zu verpacken um so Flexibilität als auch Übersichtlichkeit zu steigern. Wer schonmal was in C geschrieben hat, der wird sich jetzt sicherlich kein Kopfzerbrechen machen müssen. Funktionen werden in glSlang genauso nach folgendem Prinzip deklariert :
<source lang="glsl">
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</source>

Funktionen die ''nichts zurückgeben'' müssen mit dem RückgabeTyp {{INLINE_CODE|void}} deklariert werden, außerdem entfällt dann logischerweise das {{INLINE_CODE|return}}. Falls die Funktion eines ihrere Argumente nach außen übergeben soll, muss dieses Argument mit dem Typenqualifizierer out (Siehe Kapitel 4.2) versehen werden. ''Arrays'' können nur als Eingabeargumente übergeben werden und dürfen nich dimensioniert als Argument verwendet werden, sondern müssen mit leeren Klammern argumentiert werden.
Ein paar Beispiele :
<source lang="glsl">
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</source>

Diese Funktion gibt ''nichts'' zurück, aber gibt EingabeWert*MyConstValue im Ausgabeargument AusgabeWert nach außen.
<source lang="glsl">
float MeineFunktion(float EingabeWert)
{
return EingabeWert*MyConstValue;
}
</source>

Bietet genau die selbe Funktionalität wie das Beispiel darüber. Allerdings wird hier der berechnete Wert als Ergebnis der Funktion zurückgeliefert.
<source lang="glsl">
float VektorSumme(float v[])
{
return v[0]+v[1]+v[2]+v[3];
}
</source>

Wie bereits gesagt darf ein Array als Argument keine Dimensionierung enthalten. Wenn man der Funktion also ein Array übergibt, sollte man vorher drauf achten das es entsprechend der in der Funktion genutzten Indizes dimensioniert wurde.

==if-Anweisung==

Selektion über eine if-Anweisung darf auch in keiner Hochsprache fehlen. Genauso wie in C oder Delphi erwartet auch hier die If-Anweisung einen boolschen Ausdruck (Wahr oder Falsch) und wird dann ausgeführt (wahr) bzw. verzweigt auf ein (wenn vorhanden) else (falsch). Verschachtelung ist wie erwartet auch möglich.

'''Hinweis : '''
Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten im Fragmentshader kein Early-Out, was zur Folge hat das bei einer If-Anweisung immer alle Zweige ausgeführt werden. Am Ende wird dann aber nur ein Ergebnis geschrieben, die anderen verworfen. Auf solchen Karten bringen If-Anweisungen also im Normalfall keine Geschwindigkeitssteigerung, sondern oft eher das Gegenteil.
Neuere SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall, da hier dynamische Verzweigungen und auch Early-Out von der Hardware implementiert werden.

==Schleifen==

Auch Schleifen, ein wichtiges Konzept jeder Hochsprache haben ihren Weg in glSlang gefunden. Unterstützt werden folgende Schleifentypen :

* '''for'''-Schleife
<source lang="glsl">
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck)
{
statement
}
</source>

* '''while'''-Schleife
<source lang="glsl">
while (Durchlaufbedingung)
{
statement
}
</source>

* '''do'''-while-Schleife
<source lang="glsl">
do
{
statement
}
while (Durchlaufbedingung)
</source>

'''Hinweis :''' Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten Schleifen nicht in Hardware. Schleifen werden dann beim Kompilieren vom Treiber entrollt, wodurch natürlich Shader mit weitaus mehr Instruktionen als erwartet generiert werden. Von daher sollte man auf solchen Karten möglichst auf Schleifen verzichten, oder diese nur recht kurz halten. Bei SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall.

=Eingebaute Variablen, Attribute und Konstanten=
Nachdem wir uns nun lange genug mit den minderinterssanten Elementen der glSlang-Syntax beschäftigt haben, gehts jetzt endlich an die wirklich interessanten Dinge. Wie schon ARB_VP/ARB_FP bringt auch glSlang jede Menge eingabauter Variablen, Attribute und Konstanten mit, deren Aliase sie recht leicht identifizierbar machen (ganz im Gegensatz zum Indexgewusel bei den DX-Shadern).

==Variablen im Vertex Shader==
Exklusiv im Vertex Shader stehen die folgenden Variablen zur Verfügung :

* vec4 gl_Position muss geschrieben werden
:Dieser Variable '''muss''' im Vertexshader ein Wert zugewiesen werden, wird dies nicht getan ist das Ergebnis (sprich die Position des Vertex) undefiniert. Vorgesehen ist diese Variable für die ''homogene Position des Vertex'' und wird u.a. zum Clipping und Culling verwendet. Sie darf natürlich auch (mehrfach) geschrieben und ausgelesen werden.

* float gl_PointSize kann geschrieben werden
:Diese Variable wurde dazu vorgesehen um dort im VertexShader die Punktgröße in Pixeln hineinzuschreiben.

* vec4 gl_ClipVertex kann geschrieben werden
:Falls genutzt, sollten hier die Vertexkoordinaten die im Zusammenhang mit benutzerdefinierten Clippingplanes genutzt werden abgelegt werden. Wichtig ist, das gl_ClipVertex im selben Koordinatenraum wie die Clippingplane definiert ist.

==Attribute im Vertex Shader==

Folgende Attribute stehen nur im Vertex Shader zur Verfügung und '''können nur gelesen werden''' :

* vec4 gl_Color
: Farbwert des Vertex.
* vec4 gl_SecondaryColor
:Sekundärer Farbwert des Vertex.
* vec4 gl_Normal
:Normale des Vertex.
* vec4 gl_Vertex
:Koordinaten des Vertex;
* vec4 gl_MultiTexCoord0..7
:Texturkoordinaten auf Textureinheit 0..7.
* float gl_FogCoord
:Nebelkoordinate des Vertex.

==Variablen im Fragment Shader==

Im Fragment Shader sind folgende Variablen exklusiv nutzbar :

* vec4 gl_FragColor
: Speichert den Farbwert des Fragmentes, der von folgenden Funktionen der festen Pipeline genutzt wird. Wird dieser Variable nichts zugewiesen, so ist ihr Inhalt undefiniert und darauf aufbauende Ergebnisse ebenfalls.

* vec4 gl_FragData[0..15]
: Ersetzt gl_FragColor bei der Verwendung von multiplen Rendertargets.

* float gl_FragDepth
: Durch schreiben dieser Variable kann man den von der festen Funktionspipeline ermittelten Tiefenwert überspringen, der mit {{INLINE_CODE|gl_FragCoord.z}} ausgelesen werden kann. Wird dieser Wert nicht geschrieben, nutzen folgende Funktionen der Pipeline den vorher fest berechneten Wert.

* vec4 gl_FragCoord nur lesen
: In dieser Variable ist die Position des Fragmentes relativ zur Fensterposition im Format x,y,z,1/w abgelegt, wobei z den von der festen Funktionspipeline berechneten Tiefenwert enthält.

* bool gl_FrontFacing nur lesen
: Gibt an ob das Fragment zu einer nach vorne zeigenden Primitive gehört (=true).

Im Bezug auf {{INLINE_CODE|gl_FragColor}} und {{INLINE_CODE|gl_FragDepth}} sei noch anzumerken das diese ''nicht'' in den Wertebereich 0..1 gebracht werden müssen, da dies später durch die feste Funktionspipeline automatisch gemacht wird.

==Eingebaute Varyings==

Wie bereits in Kapitel 4.2 erwähnt, stellen Varyings eine Schnittstelle zwischen dem Vertex und dem Fragment Shader dar. Sie werden im Vertex Shader geschrieben und können dann im Fragment Shader ausgelesen werden, ohne das die folgenden Varyings dafür explizit deklariert werden müssen :

* vec4 gl_FrontColor
: Farbe der Vorderseite des Vertex.

* vec4 gl_BackColor
: Farbe der Rückseite des Vertex.

* vec4 gl_FrontSecondaryColor
: Sekundäre Farbe der Vorderseite des Vertex.

* vec4 gl_BackSecondaryColor
: Sekundäre Farbe der Rückseite des Vertex.

* vec4 gl_TexCoord[x]
: Texturkoordinaten des Vertex auf Textureinheit x, wobei x die von der Hardware zur Verfügung gestellte Zahl der Textureinheiten-1 nicht überschreiten darf.

* float gl_FogFragCoord
: Nebelkoordinate des Fragmentes.

Die Varyings {{INLINE_CODE|gl_FrontColor, gl_FrontSecondaryColor, gl_BackColor}} und {{INLINE_CODE|gl_BackSecondaryColor}} können im FragmentShader nur unter den Aliases gl_Color bzw. gl_SecondaryColor gelesen werden. Welcher Wert des Vertex Shaders im Fragment Shader dort eingesetzt wird ist abhängig davon ob das Fragment zu einer nach vorne oder nach hinten zeigenden Primitive gehört.

==Eingebaute Konstanten==
Auch diverse Konstanten wurden definiert um darauf schnell im Shader zugreifen zu können. In den Klammern stehen die von einer GL-Implementation als Mindestanforderung anzubietenden Werte. Alle Konstanten sind sowohl im Vertex als auch im Fragment Shader abrufbar :

: OpenGL 1.0/1.2 :
* int gl_MaxLights (8)
* int gl_MaxClipPlanes (6)
* int gl_MaxTextureUnits (2)

: ARB_Fragment_Program :
* int gl_MaxTextureCoordsARB (2)

: Vertex_Shader :
* int gl_MaxVertexAttributesGL2 (16)
* int gl_MaxVertexUniformFloatsGL2 (512)
* int gl_MaxVaryingFloatsGL2 (32)
* int gl_MaxVertexTextureUnitsGL2 (1)

: Fragment_Shader :
* int gl_MaxFragmentTextureUnitsGL2 (2)
* int gl_MaxFragmentUniformFloatsGL2 (64)

==Eingebaute Uniformvariablen==

Um den Zugriff auf OpenGL-Staten zu vereinfachen wurden in glSlang diverse Uniformvariablen zur direkten Verwendung im Shader eingebaut. Wie gewohnt wurden auch hier sinnvolle Namen verwendet, so dass eine tiefere Erklärung unnötig sein dürfte :

* mat4 gl_ModelViewMatrix
* mat4 gl_ProjectionMatrix
* mat4 gl_ModelViewProjectionMatrix
* mat3 gl_NormalMatrix
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die invertierten und anschließend transponierten oberen 3x3 Werte der {{INLINE_CODE|gl_ModelViewMatrix}}.
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]

* float gl_NormalScale
: Gibt den unter OpenGL festgelegten Faktor zur Skalierung der Normalen zurück.

* struct gl_DepthRangeParameters
<source lang="glsl">
struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;
</source>
: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
<source lang="glsl">
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</source>
*struct gl_MaterialParameters
<source lang="glsl">
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</source>
*struct gl_LightSourceParameters
<source lang="glsl">
struct gl_LightSourceParameters
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
vec4 position;
vec4 halfVector;
vec3 spotDirection;
float spotExponent;
float spotCutoff;
float spotCosCutoff;
float constantAttenuation;
float linearAttenuation;
float quadraticAttenuation;
};
gl_LightSourceParameters gl_LightSource[gl_MaxLights];
</source>
*struct gl_LightModelParameters
<source lang="glsl">
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</source>
*struct gl_LightModelProducts
<source lang="glsl">
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</source>
*struct gl_LightProducts
<source lang="glsl">
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</source>
* vec4 gl_TextureEnvColor[gl_MaxFragmentTextureUnitsGL2]
* vec4 gl_EyePlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneQ[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneQ[gl_MaxTextureCoordsARB]

*struct gl_FogParameters
<source lang="glsl">
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</source>
Diese recht umfangreiche GL-Stateliste sollte eigentlich jeden Bedarf decken und momentan gibts kaum einen OpenGL-Status den man so nicht in einem Shader abfragen bzw. nutzen kann.

=Eingebaute Funktionen=
glSlang ist mit diversen Skalar- und Vektorfunktionen ausgestattet, die teilweise (idealerweise) sogar direkt in der Hardware ausgeführt werden, weshalb einer fertigen Funktion ggü. gleichwertigen eigenen Berechnungen immer der Vorzug zu geben ist.
{{Hinweis| ''genType'' kann vom Type float, vec2, vec3 oder vec4 sein, ''mat'' vom Typ mat2, mat3 oder mat4.}}

==Trigonometrie und Winkel==
Alle übergebenen Winkel sollten, soweit nicht anders vermerkt, in Radien angegeben werden.

* genType radians (genType degrees)
: Wandelt von Grad nach Radien.
* genType degrees (genType radians)
: Wandelt von Radien nach Grad.
* genType sin (genType x)
: Gibt den Sinus von x zurück, wobei x in Radien angegeben wird.
* genType cos (genType x)
: Gibt den Kosinus von x zurück, wobei x in Radien angegeben wird.
* genType tan (genType x)
: Gibt den Tangens von x zurück, wobei x in Radien angegeben wird.
* genType asin (genType x)
: Liefert den Arcsinus von x zurück, also den Winkel dessen Sinus x ergeben würde.
* genType acos (genType x)
: Liefert den Arckosinus von x zurück, also den Winkel dessen Cosinus x ergeben würde.
* genType atan (genType y, genType x)
: Liefert den Winkel zurück, dessen Tangens x/y ergeben würde.
* genType atan (genType y_over_x)
: Liefert den Winkel zurück, dessen Tangens x über y ergeben würde.

==Hyperbolisch==
* genType sinh (genType x)
: Gibt den Sinus Hyperbolicus von x zurück. (return = (exp(x) - exp(-x)) * 0.5; )
* genType cosh (genType x)
: Gibt den Kosinus Hyperbolicus von x zurück. (return = (exp(x) + exp(-x)) * 0.5; )
* genType tanh (genType x)
: Gibt den Tangens Hyperbolicus von x zurück. (return = (exp(x) - exp(-x)) / (exp(x) + exp(-x)); )
* genType asinh (genType angle)
: Gibt den Areasinus Hyperbolicus von x zurück. (return = log(x + sqrt(x * x + 1.0)); )
* genType acosh (genType angle)
: Gibt den Areakosinus Hyperbolicus von x zurück. (return = log(x + sqrt(x * x - 1.0)); )
* genType atanh (genType x)
: Gibt den Areatangens Hyperbolicus von x zurück. (return = log((1.0 + x) / (1.0 - x)) * 0.5; )

==Exponentiell==
* genType pow (genType x, genType y)
: Gibt x hoch y zurück.
* genType exp (genType x)
: Gibt e(Eulerischezahl ≈ 2.7182) hoch x zurück.
* genType log (genType x)
: Gibt den Logarithmus zur Basis e(Eulerischezahl ≈ 2.7182) von x zurück.
* genType exp2 (genType x)
: Gibt 2 hoch x zurück.
* genType log2 (genType x)
: Gibt den Logarithmus zur Basis 2 von x zurück.
* genType sqrt (genType x)
: Gibt die Wurzel von x zurück.
* genType inversesqrt (genType x)
: Gibt die umgekehrte Wurzel von x zurück.

==Standardfunktionen==
* genType abs (genType x)
: Liefert den absoluten Wert von x zurück.
* genType sign (genType x)
: Gibt -1.0 zurück, wenn x < 0.0, 0.0 wenn x = 0.0 und 1.0 wenn x > 0.0.
* genType roundeven(genType x)
: Rundet auf den nächsten Integerwert und gibt diesen zuück. Bei ".5" Werten wird zur nächsten geraden Zahl gerundet.
* genType round(genType x)
: Rundet auf den nächsten Integerwert und gibt diesen zuück. ".5" Werte werden je nach Implementation anders behandelt.
* genType trunc(genType x)
: Rundet auf den nächsten Integerwert dessen Absoluterwert nicht größer ist als der Absolutewert von x
* genType floor (genType x)
: Gibt denn größten Integerwert zurück, der kleiner oder gleich x ist.
* genType ceil (genType x)
: Gibt den kleinsten Integerwert zurück, der größer oder gleich x ist.
* genType fract (genType x)
: Gibt den Nachkommateil von x zurück.
* genType mod (genType x, float y)
* genType mod (genType x, genType y)
: Gibt den Modulus zurück. (result = x - y * floor(x / y))
* genType min (genType x, genType y)
* genType min (genType x, float y)
: Liefert y zurück wenn y < x, ansonsten x.
* genType max (genType x, genType y)
* genType max (genType x, float y)
: Liefert y zurück wenn x < y, ansonsten x.
* genType clamp (genType x, genType minVal, genType maxVal)
* genType clamp (genType x, float minVal, float maxVal)
: Zwängt x in den Bereich minVal ... maxVal . (return = min(minVal, max(maxVal, x)))
* genType mix (genType x, genType y, genType a)
* genType mix (genType x, genType y, float a)
: Liefert den linearen Blend zwischen x und y zurück. (result = x * (1 - a) + y * a)
* genType step (genType edge, genType x)
* genType step (float edge, genType x)
: Liefert 0.0 zurück, wenn x < edge, ansonsten 1.0.
* genType smoothstep (genType edge0, genType edge1, genType x)
* genType smoothstep (float edge0, float edge1, genType x)
: Liefert 0.0 zurück, wenn x <= edge0 und 1.0 wenn x >= edge1. Dazwischen wird eine weiche Hermite Interpolation durchgeführt.
::float t = clamp((x - edge0) / (edge1 - edge0), 0.0, 1.0);
::result = t * t * (3.0 - 2.0 * t)

==Geometrie==
* float length (genType x)
: Gibt die Länge des Vektors x (= sqrt(x[0]² + x[1]² + ... + x[n]²) zurück.
* float distance (genType p0, genType p1)
: Gibt die Distanz zwischen den zwei Vektoren p0 un p1 (= length(p0-p1)) zurück.
* float dot (genType x, genType y)
: Gibt das Punktprodukt von x und y zurück (=x[0]*y[0] + x[1]*y[1] + ... + x[n]*y[n]).
* vec3 cross (vec3 x, vec3 y)
: Gibt das Kreuzprodukt von x und y zurück.
* genType normalize (genType x)
: Normalisiert den Vektor x auf die Länge 1.
* vec4 ftransform()
: Nur im Vertex Shader. Die Funktion stellt sicher, das das eingehende Vertex haargenau so transformiert wird wie in der festen Funktionspipeline. gl_Position = ftransform() wird dann also gebraucht, wenn in mehreren Durchgängen sowohl im Shader als auch in der festen Pipeline gerendert wird, um sicherzustellen das in beiden Fällen die gleiche Vertexposition herauskommt.
* genType faceforward (genType N, genType I, genType Nref)
: Gibt einen nach vorne zeigenden Vektor N zurück. (If dot(NRef, I) < 0 return N else return -N)
* genType reflect (genType l, genType N)
: Gibt den an der Flächenausrichtung N reflektierten Vektor I zurück. (result = l - 2.0 * dot(N,I) * N; )
* genType refract (genType l, genType N, float eta)
: Gibt den an der Flächenausrichtung N mit dem Brechungsindex eta gebrochenen Vektor l zurück.
::gentype k = 1.0 - eta * eta * (1.0 - dot(N, l) * dot(N, l))
::if (k < 0.0)
:::result = 0.0
::else
:::result = eta * l - (eta * dot(N, l) * sqrt(k)) * N

==Matrixfunktionen==
* mat matrixCompMult (mat x, mat y)
: Multipliziert Matrix X mit Matrix Y komponentenweise. Um eine normale lineare Matrixmultiplikation durchzuführen, sollte der "*"-Operator genutzt werden.
* mat transpose (mat m)
: Gibt die transponierte Matrix von m zurück.
* mat invert (mat m)
: Gibt die invertierte Matrix von m zurück. Also die Matrix, die mit m multipliziert die Normalmatrix ergeben würde.
* mat outerProduct(vec c, vec r)
: Gibt eine eine Matrix als Ergebnis der linearen (return[m, n] = c[m] * r[n])-Operation zurück.

==Vektorvergleiche==
Die meisten Vektorvergleichsfunktionen liefern als Ergebnis einen boolvektor zurück, da die Vergleiche per Komponente stattfinden. Wenn man also x = vec4(1.0, 3.0, 0.0, 0.0) mit y = vec4(2.0, 1.5, 1.5, 0.0) via lessThan(x, y) vergleicht, erhält man als Ergebnis bvec(true, false, true, false).

* bvec lessThan (vec x, vec y)
* bvec lessThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x < y zurück.
* bvec lessThanEqual (vec x, vec y)
* bvec lessThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x <= y zurück.
* bvec greaterThan (vec x, vec y)
* bvec greaterThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x > y zurück.
* bvec greaterThanEqual (vec x, vec y)
* bvec greaterThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x >= y zurück.
* bvec equal (vec x, vec y)
* bvec equal (ivec x, ivec y)
* bvec equal (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x == y zurück.
* bvec notEqual (vec x, vec y)
* bvec notEqual (ivec x, ivec y)
* bvec notEqual (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x != y zurück.
* bool any (bvec x)
: Liefert true zurück, wenn mindestens eine der Komponenten von x true ist.
* bool all (bvec x)
: Liefert true zurück, wenn alle Komponenten von x true sind.
* bvec not (bvec x)
: Liefert die logische Negation von x zurück.

==Texturenzugriffe==

Diese wichtige Funktionskategorie dient dazu, Werte aus einer an eine Textureinheit gebundenen Textur zu ermitteln. Die Texturenzugriffe können sowohl im Vertex (!) als auch im Fragment Shader ausgeführt werden, wobei der optionale Parameter bias im Vertex Shader ignoriert wird. Allerdings gibt es zusätzlich Funktionen die auf "Lod" enden und nur im Vertex Shader genutzt werden dürfen um eben dieses Manko zu umgehen. Funktionen mit dem Suffix "Proj" geben einen projizierten Texturenwert zurück.

: '''1D-Texturen :'''
* vec4 texture1D (sampler1D sampler, float coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec2 coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture1DLod (sampler1D sampler, float coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec2 coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec4 coord, float lod)

: '''2D-Texturen :'''
* vec4 texture2D (sampler2D sampler, vec2 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

: '''3D-Texturen :'''
* vec4 texture3D (sampler3D sampler, vec3 coord [, float bias])
* vec4 texture3DProj (sampler3D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture3DLod (sampler3D sampler, vec3 coord, float lod)
* vec4 texture3DProjLod (sampler3D sampler, vec4 coord, float lod)

: '''Cubemap :'''
* vec4 textureCube (samplerCube sampler, vec3 coord [, float bias])
: Nur im Vertex Shader :
*vec4 textureCubeLod (samplerCube sampler, vec3 coord, float lod)

: '''Tiefentextur (Shadowmap) :'''
* vec4 shadow1D (sampler1DShadow sampler, vec3 coord [, float bias])
* vec4 shadow2D (sampler2DShadow sampler, vec3 coord [, float bias])
* vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord [, float bias])
* vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 shadow1DLod (sampler1DShadow sampler, vec3 coord, float lod)
* vec4 shadow2DLod (sampler2DShadow sampler, vec3 coord, float lod)
* vec4 shadow1DProjLod (sampler1DShadow sampler, vec4 coord, float lod)
* vec4 shadow2DProjLod (sampler2DShadow sampler, vec4 coord, float lod)

: '''Texturegröße :'''
Mit den textureSize-Befehlen kann die Größe einer Textur bestimmt werden, wobei lod das Mipmaplevel angibt:
*int textureSize(sampler1D sampler, int lod)
*ivec2 textureSize(sampler2D sampler, int lod)
*ivec3 textureSize(sampler3D sampler, int lod)
*ivec2 textureSize(samplerCube sampler, int lod)
*int textureSize(sampler1DShadow sampler, int lod)
*ivec2 textureSize(sampler2DShadow sampler, int lod)

Wie bereits eingangs gesagt ist dieses Kapitel ein sehr wichtiges, denn eine 3D-Szene ohne Texturen ist heute kaum denkbar. Darüber hinaus lassen sich durch Texturenzugriffe recht viele interessante Sachen machen, z.B. ein einfacher Blurfilter oder das freie überblenden bestimmter Texturenteile. Deshalb führe ich hier kurz ein paar Beispiele an, welche die Nutzung dieser Funktionen verdeutlichen sollen :

===Beispiel A===
Eine Textur gebunden die einfach ausgegeben werden soll

''Im Vertex Shader'' :
<source lang="glsl">
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>
Der Vertex Shader ist recht minimal. Neben der homogenen Vertexposition leiten wir hier nur die im OpenGL-Programm angegebenen Texturkoordinaten weiter. ''Dies ist aber unbedingt nötig!'' Ohne die letzte Zeile hätten wir im Fragment Shader keine gültigen Texturkoordinaten auf TMU0, was in einer Fehldarstellung enden würde.

''im Fragment Shader'' :
<source lang="glsl">
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</source>
Zuerst deklarieren wir hier einen 2D-Texturensampler, wichtig : '''Texturensampler müssen IMMER als uniform deklariert werden!''' In der Hauptfunktion weisen wir dann einfach den über die Funktion texture2D aus unserer gebundenen Textur ausgelesenen Farbwert, anhand der vom Vertex Shader übergebenen Texturkoordinaten, zu.
{{Vorlage:Hinweis|Der Uniform-Integer für den Sampler referenziert '''nicht''' den Namen (die ID) des Texturobjektes, sondern die Nummer der Texturunit.}}

===Beispiel B===
Zwei Texturen, jeweils auf TMU0 und TMU1. Fragmentfarbe soll eine Multiplikation der beiden Texturen darstellen.

In diesem Beispielfall (der recht häufig vorkommt) müssen wir im Programm festlegen, ''welcher Sampler welche Textureinheit adressiert'', genau deshalb müssen die Texturensampler auch als uniform deklariert werden. Die Standardtextureneinheit eines Samplers ist TMU0, was in unserem Falle natürlich nicht brauchbar ist. Also müssen wir unserem zweiten Textursampler im Programm mitteilen das er seine Daten aus TMU1 beziehen soll :

glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);

Dies ist also unbedingt zu machen, sobald ein Texturensampler eine Textureinheit > GL_TEXTURE_0 adressieren will. Die Textureneinheit des Samplers lässt sich also nicht im Shader selbst festlegen. Der Fragment Shader ist nun allerdings schnell hergeleitet (Vertex Shader verändert sich nicht, da TMU1 die Texturkoordinaten auch von TMU0 bezieht) :

im Fragment Shader :
<source lang="glsl">
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

void main(void)
{
gl_FragColor = texture2D(texSamplerTMU0, vec2(gl_TexCoord[0])) *
texture2D(texSamplerTMU1, vec2(gl_TexCoord[0]));
}
</source>

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich [[GLSL noise|Noisefunktionen]] nutzen, mit deren Hilfe sich eine gewisse "Zufälligkeit" simulieren lässt (wirklich zufällige Werte sind es natürlich nicht). Ein zurückgegebener Wert liegt dabei immer im Bereich [-1..1] und ist immer bei gleichem Eigabewert auch immer gleich. Die Verwendung empfiehlt sich derzeit allerdings eher nicht, da nur die 3DLabs Treiber die Funktionen unterstützen und eine Noisetextur wahrscheinlich performanter ist.

* float noise1 (genType x)
* vec2 noise2 (genType x)
* vec3 noise3 (genType x)
* vec4 noise4 (genType x)

==Discard==
Eigentlich keine Funktion, sondern eine Abbruchbedingung '''nur im Fragment Shader'''. Das Schlüsselwort {{INLINE_CODE|discard}} verwirft das aktuell bearbeitete Fragment und beendet gleichzeitig den Shader. Es kann z.B. genutzt werden um Alphamasking manuell durchzuführen.
Man sollte dabei jedoch beachten dass ein Großteil der aktuellen Hardware kein "early-out" (frühes Beenden) im Fragmentshader unterstützt. Wenn dort also ein {{INLINE_CODE|discard}} auftaucht, wird trotzdem auch der Code danach ausgeführt und einfach verworfen. Einen Geschwindigkeitsvorteil durch diesen Befehl wird man also erst auf neueren Karten feststellen, die dieses Faeature auch so unterstützen wie es angedacht war.

=Beispielshader=
Wen bis hierhin nicht der Mut verlassen hat, und wer aufmerksam gelesen hat, dürfte jetzt also zumindest in der Lage sein kleinere Shader in glSlang zu schreiben und diese auch im Programm zu nutzen. Ich habe im Themenbereich "glSlang" versucht alle Bereiche der Shadersprache selbst anzusprechen und hoffe das auch brauchbar rübergebracht zu haben. Um oben erlerntes (hoffe ich doch mal) nochmal zu vertiefen werde ich jetzt (wie ich das bereits bei meinem ARB_VP-Tutorial getan habe) einen simplen Beispielshader (Vertex und Fragment Shader) auseinanderpflücken um so u.a. auch die Programmstruktur für alle die in C nicht so bewandert sind zu erörtern.

==Der Vertex Shader==
<source lang="glsl">
uniform vec4 GlobalColor;

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color * GlobalColor;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Wie gesagt recht simpel. Angefangen wird mit der Deklaration einer globalen Uniformvariable namens {{INLINE_CODE|GlobalColor}}. Wie wir uns erinnern gibt der Typenqualifizierer uniform an, das wir den Wert dieser Variable (ein 4-Komponentenvektor, da Farbwerte aus R,G,B und A bestehen) in unserem Programm an den Shader übermitteln.

Danach gehts ohne Umwege direkt in unsere Hauptfunktion, da wir im Vertex Shader keine anderen Funktionen benötigen. Dort berechnen wir zuerst die homogene Position unseres Vertex, die sich aus der eingehenden Vertexposition multipliziert mit der Modelansichtsmatrix ergibt. Wie schonmal gesagt '''muss diesem Wert etwas zugewiesen werden''', da sonst alle darauf aufbauenden Funktionen unvorhersehbare Ergebnisse liefern.
Außerdem wollen wir die Frontfarbe unseres Vertex jedesmal mit der im Programm übergebenen GlobalColor multiplizieren, so dass wir den Farbwert der gesamten Szene aus unserem Programm heraus manipulieren können. Zu guterletzt geben wir dann noch unsere aus der festen Funktionspipeline erhaltenen Texturkoordinaten auf Textureinheit 0 weiter. Wenn im Fragmentshader Texturkoordinaten verwendet werden, '''muss das getan werden'''.

==Der Fragment Shader==
<source lang="glsl">
uniform sampler2D Texture0;
uniform sampler2D Texture1;
uniform sampler2D Texture2;
uniform sampler2D Texture3;

void main(void)
{
vec2 TexCoord = vec2( gl_TexCoord[0] );
vec4 RGB = texture2D( Texture0, TexCoord );

gl_FragColor = texture2D(Texture1, TexCoord) * RGB.r +
texture2D(Texture2, TexCoord) * RGB.g +
texture2D(Texture3, TexCoord) * RGB.b;
}
</source>

Auch hier passiert nicht wirklich viel Großartiges. Wir deklarieren beim Shaderanfang zuerst vier Texturensampler, da wir insgesamt vier verschiedene Texturen im Shader auslesen wollen, eine Verlaufstextur und drei Oberflächentexturen. Auch hier sei wieder gesagt das man Sampler '''immer als uniform deklarieren muss'''. In der Hauptfunktion deklarieren wir dann einen Farbvektor, der auch direkt einen Farbwert aus Textureinheit 0 zugewiesen bekommt. Auf Textureinheit 0 haben wir ihm Hauptprogramm eine Verlaufstextur gebunden, die angibt wie die drei folgenden Texturen ineinander geblendet werden.
Danach schreiben wir dann den Farbwert des Fragmentes, der '''im Fragment Shader ausgegeben werden muss'''. Der besteht wie einfach zu erkennen aus Farbwert von Textureinheit 1 * Rotwert von Textureinheit 0 + Farbwert von Textureinheit 2 * Grünwert von Textureinheit 0 + Farbwert von Textureinheit 3 * Blauwert von Textureinheit 0. So ist z.B. an Stellen an denen in der Verlaufstextur reines blau liegt nur die dritte Textur sichtbar.

So viel also zu unserem kleinen Beispielshader. Er ist weder besonders toll noch besonders sinnvoll, sollte aber auch eher dazu dienen euch glSlang ein wenig zu veranschaulichen, was mir hoffentlich gelungen ist.

Wenn ihr in den vorangegangenen Kapiteln zumindest ein wenig aufgepasst habt, dann könnt ihr euch vor eurem inneren Auge hoffentlich vortstellen was der Shader macht : Er blendet drei Texturen weich anhand der Verlaufstextur ineinander über. Sowas kann man z.B. für ein Terrain nutzen, um dieses anhand einer Farbtextur zu texturieren. Für alle, die damit Probleme haben hier zwei Bilder die den Shader veranschaulichen. Links die Verlaufstextur, die angibt wo welche Textur wie stark gewichtet wird und rechts dann das Ergebnis :

<div align="center"> [[BILD:GLSL_sample_shader_a.jpg]] [[BILD:GLSL_sample_shader_b.jpg]]</div>

=Post Mortem=
Das wars also, meine "Einführung" in die OpenGL Shader Sprache. Ich hoffe es hat euch nicht gelangweilt und auch die von mir zur Verfügung gestellten Informationen haben euch hoffentlich ausgereicht. Mit der Veröffentlichung dieser Einführung geht übrigens auch die Eröffnung eines Shaderforums hier auf der DGL einher, in der ihr dann also fleissig Fragen zum Thema stellen oder eure Shader präsentieren könnt. In diesem Post Mortem gehe ich jetzt noch kurz auf die Zukunft von glSlang ein und zeige ein paar Screenshots (damit die Augen entspannen können), bevor ihr euch dann selbst in die Shaderwelt stürzen könnt.

=Beispiele=

Anbei ein paar exemplarische Screenshots. Da man mit GLSL aber alle möglichen Effekte berechnen kann (u.a. auch 1:1 die feste Funktionspipeline) ist es hier unmöglich einen Überblick aller möglichen Techniken zu geben.

[[Datei:tut_glsl_eigenershader_01.png]] [[Datei:tut_glsl_eigenershader_02.png]] [[Datei:tut_glsl_eigenershader_03.png]]

Wie im ersten (und dritten) Screenshot zu sehen ist es natürlich auch möglich mehrere Techniken innerhalb einer Szene zu nutzen. Hier sind letztendlich bis auf Hardwarelimitationen keine Grenzen gesetzt.

=Die Zukunft=
Als dieses Tutorial geschrieben wurde, war noch nicht ganz abzusehen dass bzw. ob sich GLSL auch durchsetzen würde. ARB-Shader und NVidias cG waren damals die Platzhirsche, aber inzwischen werden ARB-Shader nicht mehr genutzt (und auch schon länger nicht mehr weiterentwickelt) und auch NVidia setzt primär auf GLSL. GLSL wird permanent weiterenwtickelt und Hersteller können dank des flexiblen Extensionsystems auch in GLSL eigene Extensions offenlegen um die aktuellsten Features (wie z.b. den Tesselator auf aktuellen ATI-Karten) nutzen zu können. GLSL gilt inzwischen auch offizielle die Shadersprache für OpenGL und wird permanent an die neusten technischen Entwicklungen im Grafikkartenbereich angepasst.

Wer also unter OpenGL etwas mit Shadern machen möchte, kommt an GLSL nicht vorbei!

Also viel Spaß beim Experimentieren und Shaderschreiben! Und nicht vergessen : Wir wollen sehen was ihr so treibt,

Euer
:Sascha Willems

{{TUTORIAL_NAVIGATION|-|[[Tutorial_glsl2]]}}
[[Kategorie:Tutorial|GLSL]]

Tutorial SDL Einstieg

2012-12-16T10:30:21Z

End: siehe Forumsbeitrag http://www.delphigl.com/forum/viewtopic.php?f=8&p=92541#p92541

=SDL - Simple Directmedia Layer=
==Vorwort==

Ich weiß, dass ich mich damit unbeliebt machen werde,aber... Was haben GLUT und DirectX gemeinsam? Na, Na! Wer weiß es? Richtig, sie haben beide keine Zukunft mehr. ;) Na gut, war nicht wirklich der Reißer, aber zumindest war es der Gedanke, den ich hatte als ich mich das erste Mal mit dem Simple DirectMedia Layer befaßt habe (kurz SDL). Das Ganze hat nichts mit einem Breitbandanschluß oder einer neuen Designer-Droge zu tun, sondern es handelt sich dabei um eine plattformübergreifende API.

Die Idee die dahinter steckt ist genauso simpel wie genial! DirectX ist eine wirklich hervorragende API, allerdings hat das ganze ein Nachteil! Es kommt von Microsoft und ist nur für Windows verfügbar. Die OpenSource-Gemeinde müsste vor Scham im Boden versinken, wenn man dazu nicht passend ein Projekt ins Leben rufen würde, dass diesem Defizit ein Ende bereitet. Bei SDL handelt es sich um einen abstrakten Layer der auf jeder Plattform gleich ist und dann im Hintergrund die Befehle entsprechend dem darunter befindlichen OS umwandelt. Der Vorteil für den Programmierer ist klar: Wer seine Anwendung mit SDL schreibt, kann diese auch sehr schnell auf andere Systeme portieren. Eine reine SDL Anwendung in Delphi geschrieben, sollte sich also ohne Probleme auch unter Kylix kompilieren lassen und das ganz ohne den ganzen Source-Code umzubauen. Das Ganze ist zwar nicht so komplex wie DirectX von Microsoft, hat aber mindestens genauso viel Potenzial! Wer sich nun fragt, wozu das Ganze für ihn interessant sein soll, hat nicht mitgedacht! SDL für Fensterverwaltung und Benutzerinteraktion und dazu die geilste und portabelste Grafik-API, die es auf der Welt gibt : OpenGL! ;)

Ich hoffe sehr, dass ich mit diesem Artikel einige von euch für die Kombination SDL und OpenGL begeistern kann, denn gerade wir Delpher haben auch im Linux-Sektor eine Menge Potenzial, dass leider nicht genutzt wird! In diesem Sinne viel Erfolg! ;)

==Initialisierung von SDL==
===SDL! Bitte kommen!===

Wer sich bereits einmal mit der Programmierung der Windows-API beschäftigt hat, wird hier sicherlich nichts stark Befremdliches vorfinden. Sicherlich, alles heißt irgendwie anders, aber dafür ist das Ganze auch um einiges leichter zu handhaben als die Fenstererzeugung mit der WinAPI. Direkt im Hauptprogramm fangen wir erst einmal damit an SDL zu initialisieren:

<source lang="pascal"> SDL_Init ( SDL_INIT_VIDEO );</source>

Auf diese Weise teilen wir unserem Programm mit welche Teile von SDL initialisiert werden sollen. In unserem Beispiel die Bildschirmausgabe. Wir können als Parameter auch weitere Subsysteme übergeben z. B:

<source lang="pascal"> SDL_Init ( SDL_INIT_VIDEO or SDL_INIT_TIMER );</source>

Dazu aber später mehr! Wie immer ist es wichtig, dass man nicht nur Code an den Computer schickt, sondern auch darauf vorbereitet ist dass eventuell ein Fehler aufgetreten ist. Dieser soll dann natürlich auch vom Programm abgefangen werden!

<source lang="pascal">// Initalisieren vom Simple DirectMedia Layer
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) then
begin
Log.LogError('Initalisierung von SDL schlug fehl: '+SDL_GetError,'SDL_Init');
Quit_App;
end;</source>

Sollte ein negativer Wert als Rückgabe erfolgen, so ist ein Fehler aufgetreten. Wir machen uns in diesem Fall die Fehlerbehandlung sehr einfach. Wir nutzen das im SDL integrierte Log-File und geben dort eine Fehlermeldung aus. Um die Orientierung zu erleichtern geben wir noch das Modul an in dem der Fehler auftrat. In diesem Fall eben bei der Initialisierung von SDL. Zu {{INLINE_CODE|Quit_App}} kommen wir später. Es handelt sich dabei um eine selbst geschriebene Funktion zum Freigeben der Ressourcen.

===Grafikkarten sind gar nicht so anders===

Sicherlich ist es nicht jedem Leser hier bewusst, dass man für eine grafische Ausgabe auch eine Grafikkarte braucht. Deswegen werde ich hier noch einmal explizit darauf eingehen! :) Da SDL uns zur Verfügung steht können wir es auch verwenden um uns Informationen über die eingebaute Grafikkarte einzuholen:

<source lang="pascal">// Information über Grafikkarte einholen
videoInfo := SDL_GetVideoInfo;
if ( videoInfo = nil ) then
begin
Log.LogError('Grafikkarte ließ sich nicht abfragen: '+SDL_GetError,'SDL_Init' );
Quit_App;
end;</source>

Bei VideoInfo handelt es sich um eine {{INLINE_CODE|PSDL_VideoInfo}}-Struktur. Konnten die Informationen erfolgreich abgefragt werden, so sind alle interessanten Informationen in dieser Struktur enthalten, z.B. wie viel MB Speicher diese hat! Ist die Rückgabe undefiniert, greift natürlich unsere Fehlerbehandlung.

===Die Suche nach dem wahren Pixelformat===

Unser nächstes Ziel ist nun die Erzeugung der eigentlichen Zeichenfläche. Diese ist zu vergleichen mit dem Canvas eines Windows-Fensters. Natürlich müssen wir auch hier erst einige Einstellungen vornehmen!Immerhin wollen wir ja auch nicht ein paar 2D-Bilder á la DirectDraw rendern, sondern hardwarebeschleunigtes OpenGL!Also beginnen wir die Flags für die eigentliche Initalisierung zu sammeln:

<source lang="pascal">// Flags für den SDL-Grafikmodus setzen
videoFlags := SDL_OPENGL or // OpenGL-Unterstützung aktivieren
SDL_HWPALETTE; // Palette in Hardware speichern</source>

Vermutlich wird sich niemand finden, der die Sinnhaftigkeit dieser Flags wirklich anzweifeln wird!Als nächstes ermitteln wir ob die Möglichkeit besteht den Speicher und die eigentliche Hardwarebeschleunigung auch zu nutzen. Ich denke nicht, dass jemand heutzutage noch darauf verzichtet wenn er es nicht muss ;)

<source lang="pascal">// Kann das Surface in den Speicher?
if ( videoInfo.hw_available <> 0 ) then
videoFlags := videoFlags or SDL_HWSURFACE
else
videoFlags := videoFlags or SDL_SWSURFACE;

// Wird hardware blitting unterstützt?
if ( videoInfo.blit_hw <> 0 ) then videoFlags := videoFlags or SDL_HWACCEL;</source>

Nun erfolgt die die Definition des PixelFormats dass für die Initialisierung von OpenGL unentbehrlich ist:

<source lang="pascal">// Setzen der OpenGL-Attribute
SDL_GL_SetAttribute( SDL_GL_RED_SIZE, 5 );
SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE, 5 );
SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE, 5 );
SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 16 );
SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );</source>

Die Farbwerte sollten so belassen werden. Der Tiefenbuffer wird auf 16 Bit festgelegt und ein BackBuffer soll auch erzeugt werden. Jeder der sich bereits einmal mit der Initialisierung beschäftigt hat, wird hier Gemeinsamkeiten finden und sich auch denken können wie man z.B. den Stencil-Buffer unter SDL setzt:

<source lang="pascal">SDL_GL_SetAttribute( SDL_GL_STENCIL_SIZE, 8 );</source>

Nun würden wir einen 8 Bit-Stencil-Buffer initialisieren. Gleiches gilt natürlich auch für den Akkumulations-Buffer!Damit haben wir alle Informationen gesammelt die wir brauchen um ein OpenGL-Fenster mit SDL zu erzeugen. Wenn man sich den Source Code ansieht, wird man merken, dass dieser um einiges schlanker ist als die Initalisierung der WinAPI und wir zudem auch noch plattformunabhängig sind!Einige kleinere Einstellungen nehmen wir allerdings noch vor. Nur kleine kosmetische Änderungen wie der Fenstertitel:

<source lang="pascal">// Fenstertitel festlegen
SDL_WM_SetCaption( WINDOWS_CAPTION , nil);</source>

Als einfacher String wird der Titelname übergeben, der zweite Paramter kann dazu verwendet werden ein Icon für die Leiste zu definieren. Auch können wir an dieser Stelle entscheiden ob der Benutzer in der Lage sein soll das Fenster in seiner Größe zu verändern. Standardgemäß ist dieses Feature deaktiviert, so dass die Fenstergröße immer gleich bleibt. Wollen wir ein Skalieren jedoch zulassen, übergeben wir einfach ein weiteres Video-Flag:

<source lang="pascal">videoflags := videoFlags or SDL_RESIZABLE; // Enable window resizing</source>

Nun haben wir alles beisammen und erzeugen unser Surface!

<source lang="pascal">videoflags := // Initalisierung der Surface
surface := SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP,videoflags );
if ( surface = nil ) then
begin
Log.LogError('Erzeugen einer OpenGL-Zeichenfläche schlug fehl: '+SDL_GetError,'SDL_Init' );
Quit_App;
end;</source>

Ich denke nicht, dass es einer genaueren Erklärung bedarf was an dieser Stelle geschieht. Die Fenstergröße und Farbtiefe, sowie die Wunschliste unserer Video-Flags wird übergeben und wenn alles angeforderte auch möglich ist, erhalten wir von SDL ein {{INLINE_CODE|PSDL_Surface}} zurück mit der wir dann weiterarbeiten können (und auch werden) ;)

==OpenGL Initalisierung==

Die meisten Leute gehen von einem ziemlich komplexen, aufwendigen und vor allem schweren Vorfang aus, wenn sie hören dass jemand OpenGL initalisiert. Dabei ist OpenGL gar nicht schwer zu initalisieren. Das eigentliche Problem ist vielmehr an ein Fenster vom Betriebsystem zu kommen dass auch OpenGL unterstützt. Dies haben wir allerdings bereits erfolgreich im letzten Kapitel geschafft, so dass wir nun nur noch dafür sorgen müssen, dass wir Zugriff auf die OpenGL-Runtimes erhalten. Dies ist jedoch ziemlich leicht:

<source lang="pascal"> // Laden und Initalisieren von OpenGL
InitOpenGL;
ReadExtensions;
ReadImplementationProperties;</source>

Fertig! Schon steht nichts mehr zwischen uns und dem OpenGL-Render-Spass ;) Allerdings empfiehlt es sich immer noch einige grundlegende Dinge einzustellen, einfach weil es hübscher gerendert wird ;)

<source lang="pascal"> glClearColor(0.0, 0.0, 0.0, 1.0); // Bildschirm löschen (schwarz)
glClearDepth(1.0); // Depth Buffer Setup
glEnable(GL_DEPTH_TEST); // Aktiviert Depth Testing
glDepthFunc(GL_LEQUAL); // Bestimmt den Typ des Depth Testing
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);// Qualitativ bessere Koordinaten
// Interpolation</source>

Das wir OpenGL initalisiert haben ist sicher ein guter Anfang, allerdings wollen wir natürlich auch etwas sehen. Dafür ist es notwendig, dass wir unseren Viewport setzen und die Projektions-Matrix auf die entsprechende Größe transformieren. Aus taktischen Gründen schreiben wir uns dafür eine Funtion, die wir auch später beim Event-Handlung wiederverwenden können:

<source lang="pascal">function glResizeWindow( width : integer; height : integer ) : Boolean;
begin
// Verhindern von "Division by Zero"
if ( height = 0 ) then height := 1;

// Viewport und Projektions-Matrix aktualisieren
glViewport( 0, 0, width, height );

glMatrixMode( GL_PROJECTION );
glLoadIdentity;
gluPerspective( 45.0, width / height, 0.1, 100.0 );
glMatrixMode( GL_MODELVIEW );

// Rücksetzen der World-Matrix
glLoadIdentity;

// Vorgang erfolgreich
result := true;
end;</source>

All diese Vorgänge sollten für einen OpenGL-Programmierer nichts erschreckend neues sein. Damit der Viewport auch wirklich richtig gesetzt wird, rufen wir diese Funktion einfach einmal auf:

<source lang="pascal">// Anpassen der Fenstergröße
glResizeWindow( SCREEN_WIDTH, SCREEN_HEIGHT );</source>

==Tag, Post!==
===Die Idee===

Würden wir nun unser Programm in diesem Zustand starten, würden wir für den Bruchteil einer Sekunde ein Fenster angezeigt bekommen (das immerhin OpenGL-kompatibel ist! *g) und danach sofort wieder verschwindet. Überlegt man sich einmal ganz genau, was passiert, wird einem der Grund dafür schnell klar:

<source lang="pascal">begin
// Initalisierung
Init_SDL;
Init_OpenGL;

// Anpassen der Fenstergröße
glResizeWindow( SCREEN_WIDTH, SCREEN_HEIGHT );
end.</source>

Unser Hauptprogramm initalisiert SDL, danach OpenGL, passt das Ganze an der Fenstergröße an und beendet danach die Aufgabenliste. Für Windows bedeutet dies, dass das Programm seine Verarbeitung abgeschlossen hat und somit nicht mehr gebraucht wird und schon findet sich unsere SDL-Anwendung auf dem Müllhaufen. (Um Mißverständnisse zu vermeiden: Nicht der Papierkorb und nicht aufm Desktop *g*). Wir brauchen also eine Schleife die sich immer wieder im Programm wiederholt und dafür sorgt, dass diese nur unter einer ganz bestimmten Bedingung verlassen wird und somit das Programm auch beendet wird. Man spricht von dem Main-Loop oder auch Game-Loop:

<source lang="pascal">begin
// Initalisierung
Init_SDL;
Init_OpenGL;

// Anpassen der Fenstergröße
glResizeWindow( SCREEN_WIDTH, SCREEN_HEIGHT );

// Eintritt in Main-Loop
while ( Done <> -1 ) do
begin
glHandleEvents;
glDrawScene;
end;
end.</source>

Done ist in unserem Fall ein einfacher Integer-Wert. Sobald dieser im eigentlichen Programm auf -1 gesetzt wird, wird die Schleife nicht ein weiteres Mal durchlaufen. Wir sehen auch, dass in der Schleife zwei Funktionen aufgerufen werden. Dies bietet sich an um die Übersicht zu wahren!Natürlich können wir auch noch weitere Aufgaben in der Schleife verarbeiten!
GlDrawSzene ist die Funktion die die OpenGL-Befehle beinhaltet und sich um die grafische Ausgabe kümmert. Dieser Teil ist identisch mit der entsprechenden Funktion unter der WinAPI oder der VCL. Würden wir allerdings die Schleife immer nur mit dieser Funktion durchlaufen, so würde der Benutzer keine Interaktion mit dem Programm durchführen können, da immer nur die Schleife durchlaufen wird. Die Anwendung würde hängen. Es ist daher notwendig, dass diese auf Ereignisse des Betriebsystems oder des Anwenders reagiert.

===Event-Handling===

Um zu begreifen wie genau eine solche Ereignis-Reaktion aussieht, schauen wir uns die Funktion {{INLINE_CODE|glHandleEvents}} etwas genauer an:

<source lang="pascal">procedure glHandleEvents;
var event : TSDL_Event;
begin;
// Verarbeiten der Events
while ( SDL_PollEvent( @event ) = 1 ) do
begin
case event.type_ of

// Beenden der Applikation
SDL_QUITEV :
begin
Done := -1;
end;

// Taste wurde gedrückt
SDL_KEYDOWN :
begin
glHandleKeyPress( @event.key.keysym );
end;

// Fenster-Größe hat sich verändert
SDL_VIDEORESIZE :
begin
glResizeWindow( event.resize.w, event.resize.h );
end;
end;//case
end;//while
end;</source>

Mit {{INLINE_CODE|SDL_PollEvent}} fragen wir bei SDL an, ob Nachrichten für unsere Anwendung vorliegen. Ist dies der Fall, so durchlaufen wir alle diese Nachrichten nacheinander. Um die Art der Nachricht zu ermitteln übergeben wir eine Struktur vom Typ {{INLINE_CODE|TSDL_EVENT}} und nutzen {{INLINE_CODE|.type_}} um zu ermitteln, um was für eine Nachricht es sich handelt. In unserem Fall reagieren wir auf 3 Ereignisse.

===Sein oder nicht sein...===

<source lang="pascal"> // Beenden der Applikation
SDL_QUITEV :
begin
Done := -1;
end;</source>

Liegt ein Ereignis vom Typ {{INLINE_CODE|SDL_QUITEV}} vor, so hat die Anwendung die Meldung erhalten dass sie beendet werden soll. Der wahrscheinlichste Grund dafür wird sein, dass der Anwender auf das X im Fenstertitel geklickt hat. Es liegt nun an uns dafür zu sorgen, dass diesem Wunsch auch nachgekommen wird. Wie wir uns erinnern wird das Programm verlassen, sobald {{INLINE_CODE|done := -1;}} gesetzt ist. Also machen wir dies auch. Nachdem alle Nachrichten abgearbeitet sind und der Main-Loop betreten wird, ist die Bedingung für einen Programmabbruch erfüllt.

===Tastatur-Handling===

<source lang="pascal"> // Taste wurde gedrückt
SDL_KEYDOWN :
begin
glHandleKeyPress( @event.key.keysym );
end;</source>

Dieses Event wird dann ausgelöst, wenn eine Taste gedrückt wurde. Wir übergeben in diesem Fall das Ereignis weiter an eine Funktion, die sich dann mit der Auswertung beschäftigt:

<source lang="pascal">procedure glHandleKeyPress( keysym : PSDL_keysym );
begin;
case keysym.sym of
SDLK_ESCAPE : done := -1;
end;
end;</source>

Hierzu überprüfen wir, welche Taste gedrückt wurde. In diesem Fall handelt es sich um die Escape-Taste und sie soll beim Betätigen das Programm beenden. Würden wir abfragen wollen, ob die F1-Taste gedrückt wurde, so könnten wir dies mit {{INLINE_CODE|SDLK_F1}} machen. Weitesgehend entsprechen die SDLK-Konsten den VK-Konstanten der WINAPI. Wer über eine neuere Delphi-Version verfügt, kann ja auch mal STRG drücken und dann mit der linken Maustaste auf {{INLINE_CODE|SDLK_ESCAPE}} klicken. Delphi wird dann an die Stelle springen, wo die Konstanten definiert sind. Dort werdet ihr sicherlich auch recht schnell die anderen Tasten finden, die ihr sucht.

===Eine Frage der wahren Größe===

{{INLINE_CODE|SDL_VIDEORESIZE}} wird dann ausgelöst, wenn sich die Zeichenfläche in Ihrer Größe verändert hat. Zum Beispiel, weil der Anwender gerade das Fenster größer gezogen hat.

Durch diese Veränderung der Zeichenfläche werden unsere Projektions-Matrix und der Viewport ungültig. Wir müssen diese also neu anpassen. Wer sich gut erinnern kann, wird nun verstehen warum ich anfangs gesagt habe, dass wir uns die {{INLINE_CODE|glResizeWindow}}-Funktion so schreiben, dass wir sie in einem Event wieder verwenden können.

<source lang="pascal">glResizeWindow( event.resize.w, event.resize.h );</source>

Wir übergeben einfach die vom Event übergebene neue Größe unseres Fensters und passen die Projektions-Matrix neu an. Schon kann der Anwender nach belieben die Größe des Render-Fensters verändern. So einfach ist das...

==OpenGL? Überall gleich!==

Wie ich bereits erwähnt habe, ist in der Funktion glDrawScene nichts wirklich Neues anzufinden, was nicht in einer API oder VCL-Lösung anzutreffen wäre. Schließlich ist OpenGL eben dafür geschaffen worden so portabel wie möglich zu sein:

<source lang="pascal">procedure glDrawScene;
begin
// Screen- und Tiefenbuffer bereinigen
glClear( GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT );

glLoadIdentity;
glTranslatef( -1.5, 0.0, -6.0 );

// Zeichne Dreieck
glBegin( GL_TRIANGLES );
glVertex3f( 0.0, 1.0, 0.0 );
glVertex3f( 1.0, -1.0, 0.0 );
glVertex3f( -1.0, -1.0, 0.0 );
glEnd;

glTranslatef( 3.0, 0.0, 0.0 );

// Zeichne ein Quadrat
glBegin( GL_QUADS );
glVertex3f( -1.0, 1.0, 0.0 );
glVertex3f( 1.0, 1.0, 0.0 );
glVertex3f( 1.0, -1.0, 0.0 );
glVertex3f( -1.0, -1.0, 0.0 );
glEnd;

// Buffer-Wechseln ==> Anzeigen
SDL_GL_SwapBuffers;
end;</source>

Einzig und alleine die letzte Zeile ist anders. Hat unter der WINAPI an dieser Stelle noch eine WGL-Funktion ihren Dienst verrichtet, so macht dies hier eine SDL-Funktion. WGL steht unter Linux nicht zur Verfügung und man würde sich ansonsten auf Windows-Systeme festlegen. Technisch geschieht hier aber nichts anders als auch bei der WGL-Funktion nämlich das der hintere Framebuffer nach "vorne" geholt wird, sprich auf dem Bildschirm angezeigt wird. Ohne diesen Aufruf würde OpenGL zwar brav im Hintergrund rendern, aber niemals etwas anzeigen. Das kann auch nicht in unserem Interesse sein, oder? ;)

==Time to say goodbye!==

Ich weiß ja wirklich nicht wie es Euch geht, aber ich bin immer wenn ich etwas wegschmeiße ziemlich sensibel drauf. Und wenn ich mich hier im Zimmer umsehe, habe ich auch das Gefühl dass ich mich nie wirklich von einem meiner Computer getrennt habe O_o (habe sie halt immer noch alle ziemlich lieb *schnief). Aber es gibt eben Momente bei denen man sich von etwas was man gerne hat auch wieder trennt und wenn es sich nicht mehr vermeiden läßt, sollte man den Moment wenigstens in Ehre halten.

Nein, wer nun erwartet dass ich für euch große unsinkbare Schiffe versenke, wird enttäuscht sein ;) Wir schreiben einfach eine kleine Prozedur die unsere Anwendung umweltfreundlich entsorgt. Diese Prozedur können wir auch dann einsetzen wenn ein Fehler augetreten ist. Sicher könnte man den ganzen Kram auch einfach seinem Schicksal (Windows) überlassen, aber zu einem sauberen Code gehört es sich eben, dass freizugeben was man auch angefordert hat. Ich denke nicht dass der Code wirklich einer näheren Erklärung bedarf!

<source lang="pascal">//----------------------------------------------------------------------------
// Terminieren der SDL-Anwendung
//----------------------------------------------------------------------------
procedure Quit_App;
begin;
// Freigeben der Ressourcen
SDL_QUIT;
Halt(0);
end;</source>

==Nachwort==

Das war also bereits unser kleiner Crash-Kurs in die Welt des SDL. Ich hoffe sehrmdass dieses Tutorial verständlich genug war um SDL auch künftig einzusetzen. Es ist meiner Meinung nach wichtig ein Gegengewicht zu Microsoft in der Welt zu haben und der Programmierer soll ja ökonomisch denken. Was spricht also dagegen seine Anwendung so zu gestalten, dass man sie ohne Probleme auch nach Linux übersetzen könnte?Gerade in Verbindung mit OpenGL entfaltet sich ein richtges Dream-Team. Der eine für die Fensterverwaltung, der andere für die grafische Ausgabe. Jeder der bereits (oder immer noch?!) mit GLUT arbeitet, sollte schleunigst davon weg kommen und auf SDL umsteigen. Weil es einfach besser ist ;)

Sicherlich werden nun nicht unbedingt SDL-Anwendungen aus dem Boden schießen, aber der eine oder andere hat ja vielleicht schon ein wenig Blut geleckt und möchte etwas weiter damit herum spielen? Habe ich bereits erwähnt, dass SDL auch etwas für Joysticks, Mäuse und Sound zur Verfügung stellt? Auch ein abstraktes System für mehre Threads ist mit von der Partie, sowie einige Funktionen zum Benutzen von Audio-CDs. Wer Lust auf mehr SDL hat, sollte unbedingt einmal einen Blick in die SDL-Hilfe werfen. Das Projekt ist jung, aber motiviert und hat eine Menge Potenzial!Die Delphi-Portierung wird von den JEDIs selbst unter der Projekt-Führung von Dominique Louis durchgeführt. Wer bereits seit DelphiX-Zeiten in der Szene unterwegs ist wird wissen, was es bedeutet! Gute Arbeit und Sicherheit für die Zukunft ;)
In diesem Sinne ... viel Spaß ;)

Euer
:'''Phobeus'''

{{TUTORIAL_NAVIGATION|-|[[Tutorial_SDL_RWops]]}}

[[Kategorie:Tutorial|SDL_Einstieg]]

Control Shader

2012-08-10T09:50:00Z

End: Die Seite wurde neu angelegt: „Der Tessellation Control Shader (DirectX: Hull Shader) berechnet für eine detailarme Oberfläche (ein grobes Dreiecksnetz) eine Reihe von Kontrollpunkten, mit…“

Der Tessellation Control Shader (DirectX: Hull Shader) berechnet für eine detailarme Oberfläche (ein grobes Dreiecksnetz) eine Reihe von Kontrollpunkten, mit deren Hilfe der Tessellator im Anschluss daran die Oberfläche in ein feingliedrigeres Dreiecksnetz unterteilt (Subdivision).

Evaluation Shader

2012-08-10T09:49:25Z

End: Die Seite wurde neu angelegt: „Der Tessellation Evaluation Shader (DirectX: Domain Shader) kommt nach dem Tessellator zum Einsatz und berechnet die Positionen der durch die Tessellation neu …“

Der Tessellation Evaluation Shader (DirectX: Domain Shader) kommt nach dem Tessellator zum Einsatz und berechnet die Positionen der durch die Tessellation neu erzeugten Vertices. Auf diese Weise lassen sich einem 3D-Modell neue Oberflächendetails hinzufügen.

Datei:Pipeline.png

2012-08-10T09:44:55Z

End: lud eine neue Version von „Datei:Pipeline.png“ hoch: rote kästen...

Die OpenGL Renderingpipeline.

Datei:Pipeline.png

2012-08-10T09:42:28Z

End: lud eine neue Version von „Datei:Pipeline.png“ hoch: Andere Grafik inklusive der Neuerungen von der neuen 4.3 Spezifikation (Compute-Shader, etc.) aus dem Dokument: http://www.g-truc.net/doc/OpenGL4.3review.pdf

Die OpenGL Renderingpipeline.

Framecounter

2012-07-18T08:44:40Z

End: /* Methode 1 */

==Problemstellung==
Die Bildwiederholrate in Frames per Seconds ist ein in Computerspielen oftmals verwendeter Wert, der eine Aussage über die Leistungsfähigkeit des Computersystems geben kann. 
Wenn man in seinem Programm die [[Frames|Frame]] pro Sekunde (FPS) anzeigen lassen möchte, so gibt es verschiedene Lösungswege.

==Ansätze==
===Methode 1===

Am Anfang der Renderschleife "misst" man die Zeit und speichert sie in einer Variable.
Dafür kann man die von Windows bereitgestellten Methoden [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp "Gettickcount"] (gibt in Millisekunden an, wie lange Windows läuft) oder [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Timers/TimerReference/TimerFunctions/QueryPerformanceCounter.asp "QueryPerformanceCounter"] und unter SDL SDL_GetTicks verwenden.
Für unsere Zwecke reichen diese Funktionen vollkommen aus.

Als zweiten Schritt rendert man seine Szene, verarbeitet Tastatureingaben usw.
Also alles, was in der Renderschleife passiert.

Am Ende der Renderschleife stoppt man dann ein zweites Mal die Zeit und erhält nun eine Zeitdifferenz.

Die FPS erhält man nun durch folgende Berechnung:
<source lang="pascal">FPS = 1000 / Zeitdifferenz;</source>

Wobei Zeitdifferenz bei dieser Formel auch in Millisekunden angegeben sein muss.

===Methode 2===

Diese Methode unterscheidet sich kaum von Methode 1.
Wieder wird:
#Startzeit bestimmt
#gerendert
#Endzeit bestimmt
#Zeitdifferenz berechnet

Anschließend wird die Zeitdifferenz auf eine Variable TimeCount addiert. Außerdem wird eine Zählvariable für die Frames erhöht.

Wenn die Variable Timecount größer-gleich 1000 wird (es ist mindestens 1 sec vergangen) wird die Frameanzahl berechnet und ausgegeben.

Die Methode 2 hat gegenüber Methode 1 den Vorteil, dass die Frameanzahl nicht nach jedem Frame sondern maximal nur einmal pro Sekunde berechnet wird.

==Implementierung==

Der folgende Code (passend zu Methode 2) wird im OnIdle-Event des OpenGL Formulars ausgeführt. Die Anzahl der Frames wird in der Beschriftung (Caption) des Fensters ausgegeben.

<source lang="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;
Dec(TimeCount, 1000);
FrameCount:= 0;

Caption:= InttoStr(Frames) + 'FPS';
end;

Done:= false;
end;</source>
==Siehe auch==
[[Frameratenbegrenzung]]

[[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

Framecounter

2012-07-18T08:44:21Z

End: /* Methode 1 */

==Problemstellung==
Die Bildwiederholrate in Frames per Seconds ist ein in Computerspielen oftmals verwendeter Wert, der eine Aussage über die Leistungsfähigkeit des Computersystems geben kann. 
Wenn man in seinem Programm die [[Frames|Frame]] pro Sekunde (FPS) anzeigen lassen möchte, so gibt es verschiedene Lösungswege.

==Ansätze==
===Methode 1===

Am Anfang der Renderschleife "misst" man die Zeit und speichert sie in einer Variable.
Dafür kann man die von Windows bereitgestellten Methoden [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp "Gettickcount"] (gibt in Millisekunden an, wie lange Windows läuft) oder [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Timers/TimerReference/TimerFunctions/QueryPerformanceCounter.asp "QueryPerformanceCounter"] und unter SDL SDL_GetTicks verwenden.
Für unsere Zwecke reichen diese beiden Funktionen vollkommen aus.

Als zweiten Schritt rendert man seine Szene, verarbeitet Tastatureingaben usw.
Also alles, was in der Renderschleife passiert.

Am Ende der Renderschleife stoppt man dann ein zweites Mal die Zeit und erhält nun eine Zeitdifferenz.

Die FPS erhält man nun durch folgende Berechnung:
<source lang="pascal">FPS = 1000 / Zeitdifferenz;</source>

Wobei Zeitdifferenz bei dieser Formel auch in Millisekunden angegeben sein muss.

===Methode 2===

Diese Methode unterscheidet sich kaum von Methode 1.
Wieder wird:
#Startzeit bestimmt
#gerendert
#Endzeit bestimmt
#Zeitdifferenz berechnet

Anschließend wird die Zeitdifferenz auf eine Variable TimeCount addiert. Außerdem wird eine Zählvariable für die Frames erhöht.

Wenn die Variable Timecount größer-gleich 1000 wird (es ist mindestens 1 sec vergangen) wird die Frameanzahl berechnet und ausgegeben.

Die Methode 2 hat gegenüber Methode 1 den Vorteil, dass die Frameanzahl nicht nach jedem Frame sondern maximal nur einmal pro Sekunde berechnet wird.

==Implementierung==

Der folgende Code (passend zu Methode 2) wird im OnIdle-Event des OpenGL Formulars ausgeführt. Die Anzahl der Frames wird in der Beschriftung (Caption) des Fensters ausgegeben.

<source lang="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;
Dec(TimeCount, 1000);
FrameCount:= 0;

Caption:= InttoStr(Frames) + 'FPS';
end;

Done:= false;
end;</source>
==Siehe auch==
[[Frameratenbegrenzung]]

[[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

Frameratenbegrenzung

2012-07-18T08:42:56Z

End:

==Problemstellung==
Bei vielen 3D-Anwendungen erfolgt die Bildausgabe so schnell hintereinander, wie die Hardware dies ermöglicht. Das bedeutet aber auch, dass die Auslastung des Computersystems auf 100% ansteigt. Das wiederum benötigt jede Menge Strom. Unser Auge wiederum nimmt eine Bewegung ab ca. 20 Bildern pro Sekunde als flüssig wahr - es bringt also nicht sehr viel, wenn unsere Anwendung mit mehr als 1000FPS läuft - wir bekommen davon sowieso nichts mit, außer niedriger Akkulaufzeit und hoher Stromrechnung. Die Lösung für dieses Problem ist eine Frameratenbegrenzung, die die Bildwiederholrate auf einen gewissen Wert limitiert und unsere Anwendung in der Zeit, in der nichts getan werden muss schlafen legt.

==Ansatz==

===Die naive Lösung===
Die einfachste Realisierung der Frameratenbegrenzung ist ein einfaches Hinzufügen der "Sleep" Anweisung in die Hauptschleife. Gehen wir von Sleep(5) aus, so haben wir eine Maximale Framerate von 200FPS. Diese Lösung ist jedoch etwas suboptimal. Gehen wir davon aus, dass das Zeichnen der Inhalte an sich schon 5 Millisekunden dauert, so haben wir nur noch eine Framerate von 100FPS. Auf einem älterem Rechner könnte diese Berechnung auch länger dauern und die erreichte Framerate sich daher noch mehr von unserem anvisierten Wert entfernen.

===Die intelligente Lösung===
Schlauer ist es, von der Zeit, die unser Programm pausiert, die Dauer des Rendervorgangs abzuziehen. Dazu ist es nötig, die Zeit, die zwischen zwei Frames vergeht zu messen. Um die Schlafenszeit nicht in dieser Messung zu haben, müssen wir uns diese natürlich merken und vorher abziehen. Mit diesem Ansatz passt sich die CPU-Auslastung an die Leistung des Systems an: Auf einem High-End PC wird sie automatisch niedriger als auf einem Rechner aus dem letztem Jahrhundert - so gehört es sich schließlich auch.

==Implementierung==
<source lang="pascal">
var
FMaximumFrameRate: double;
FLastSleep: double = 0;

procedure LimitFrameRate(atd: double); //"atd" ist die Zeitdifferenz zwischen zwei Frames - inklusive der "Sleeptime"
var
sleeptime: Double;
begin
sleeptime := 1000 / FMaximumFrameRate - (atd - FLastSleep);
if sleeptime > 0 then
begin
//statt sleep kann unter SDL auch SDL_Delay verwendet werden
Sleep(trunc(sleeptime));
FLastSleep := sleeptime;
end else
FLastSleep := 0;
end;
</source>

==Siehe auch==
[[Framecounter]]

[[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

Kuchenstück

2011-07-11T09:27:32Z

End:

== Kuchenstück ==

Ein Kuchen- oder Käsestück ist generell ein Stück eines flachen, breiten Zylinders. D. h. man weiß, wenn man in Mathe (9. Klasse) in Geometrie aufgepasst hat, dass der Kuchen/der Käse durch folgende Variablen beschrieben ist:

{| border="1" rules="all"
! r
| der Radius der beiden Kreise, welche die Grund- und Deckflächen des Kuchens bilden.
|-
! h
| die Höhe des Kuchens.
|}

Nun brauchen wir aber Vertices, um den Kreis in [[OpenGL]] darstellen zu können. Wir brauchen also zwei Kreise. Die Vertices eines Kreises lassen sich einfach berechnen:

:X = r * cos α

:Y = r * sin α

Nun einmal in einer for-Schleife den ganzen Kreis in einer beliebigen Auflösung durchgehen (zum Beispiel bis 360° durchlaufen lassen) und in ein dynamisches Array of TPoint abspeichern. Beim Kuchenstück lässt man die Schleife nur bis α durchlaufen. Um den Wert für α auszurechen, kann man folgende Formeln nutzen:

:α = Ui / U * 360°

:U = 2 * π * r

(Ui ist der Umfang des Kreissektors des Kuchenstückes.)

Damit hättet ihr jetzt das nötige Wissen für ein Kuchenstück. Beim Käse kommen zwar normalerweise noch Löcher rein, aber das ist Stoff für etwas anderes. Bis dahin nutzt ihr am besten einfach Texturen mit Löchern darauf.

Kuchenstück

2011-07-11T08:44:37Z

End: Die Seite wurde neu angelegt: „== Kuchenstück == Ein Kuchen- oder Käsestück ist generell ein Stück eines flachen, breiten Zylinders. D. h. weiß man, wenn man in Mathe (9. Klasse) in Geome…“

== Kuchenstück ==

Ein Kuchen- oder Käsestück ist generell ein Stück eines flachen, breiten Zylinders. D. h. weiß man, wenn man in Mathe (9. Klasse) in Geometrie aufgepasst hat, dass der Kuchen/der Käse durch folgende Variablen beschrieben ist:

r der Radius der beiden Kreise, die die Grundfläche des Kuchens bilden.

h die Höhe des Kuchens.

Nun brauchen wir aber Vertices, um den Kreis in OpenGL darstellen zu können. Wir brauchen also zwei Kreise. Die Vertices eines Kreises lassen sich einfach berechnen:

Y = sin α * r

X = cos α * r

Nun einmal in einer for-Schleife den ganzen Kreis in einer beliebigen Auflösung durchgehen (zum Beispiel bis 360° durchlaufen lassen) und in ein dynamisches Array of TPoint abspeichern. Und beim Kuchenstück halt nur bis α durchlaufen lassen. Um α rauszukriegen gibt es übrigens diese Formeln:

α = Ui / U * 360°

U = 2 * pi * r

Ui ist der Umfang des Kreis-Sektors des Kuchenstückes.
Damit hättet ihr jetzt das nötige Wissen für ein Kuchenstück. Beim Käse kommen zwar normalerweise noch Löcher rein, aber das ist Stoff für was anderes...bis dahin nutzt ihr am besten einfach Texturen mit Löchern drauf. ^^