{{Hinweis| '''Delphi is already shipping with an OpenGL header, but that header is ''outdated and also buggy''. Therefore we ''urge everyone to NOT use that header, especially as it lacks most of OpenGL's current functionality.'''''}}

=The DelphiGL header=
So to compensate for the flaws of the outdated and buggy default header that is shipped with Delphi, the [http://www.delphigl.com (german) Delphi OpenGL Community] is providing it's own header that's permanently updated to provide steady support for new OpenGL features and functionality. This makes updating to a new header version easily (usually backwards compatibility is preserved), and it's even possible to use the header with other pascal compilers like Freepascal.

It includes all OpenGL functions (currently up-to and including OpenGL 3.0) as well as all GLU ('''OpenGL Utility Libary''') functions and supports all ARB, EXT, NV and ATI extensions. It also includes additional, though lesser common extensions from other vendors like Apple, HP and SGI.

A special feature of this header are boolean variables for each included extensions that are flagged upon initialisation (those boolean vars carry the same as their corresponding extensions), so you can quickly check wether an extension is support or not (instead of checking the strings returned by [[glGetString/en]]).

==Licence/Terms of use==
The '''dglOpenGL.pas''' is distributed unter the terms and conditions of the '''Mozilla Public License Version 1.1'''. You can grab a copy of that licence [http://www.mozilla.org/MPL/MPL-1.1.html here].

<code>The contents of the dglOpenGL.pas are used with permission, subject to<br>
the Mozilla Public License Version 1.1 (the "License"); you may<br>
not use this file except in compliance with the License. You may<br>
obtain a copy of the License at<br>
http://www.mozilla.org/MPL/MPL-1.1.html<br>
<br>
Software distributed under the License is distributed on an<br>
"AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or<br>
implied. See the License for the specific language governing<br>
rights and limitations under the License.</code>

==.NET support==
Due to lack of interest, .NET support has been removed as of header version 2.1!

{{Hinweis|The .Net header won't be developed any further, but reported errors may be fixed. So new OpenGL functionality can only be found in the normal header.}}

==Initializing function pointers (crucial, see readme)==
Along with the removal of .NET support, support for loading methods dynamically has also been removed and is no longer possible with the standard header. So it's crucial to call either ''AtivateRenderingContext'' or ''ReadExtensions'' alongside with ''ReadImplementationProperties'' in your application before accessing any of the OpenGL functions. Otherwise you'll likely be prompted with an access violation at address 0x00000000.

''So if you get such an access violation please check if you called the above functions!''

== History ==
<pascal>Version 1.0 - Initial Release

Version 1.1 - Added PPointer in Tpyessection for compatiblity with Delphi
versions lower than 7 (SW)
- Added a function named RaiseLastOSError including a comment
on how to make it run under Delphi versions lower than 7 (SW)
- Added some data types according to the GL-Syntax (SW)

Version 1.2 - Fixed some problems with getting the addresses of some
Extensions (e.g. glTexImage3D) where the EXT/ARB did work
but not the core-functions (SW)

Version 1.3 - A second call to ReadimplementationProperties won't
revert to the default libs anymore (MW)
- Libraries now will be released if necessary (MW)

Version 1.3a - Small fixes for glSlang-functions (SW)

Version 1.3b - Fixed a small bug with GL_ARB_shader_objects, that lead
lead to that extension not loaded correctly (SW)

Version 1.3c - More GL 1.5 compliance by FOG_COORD_xx and
ARB-less VBO and occlusion query routines (MW)

Version 1.3d - Fixed linebreaks (should now be corrected under D5) (SW)

Version 1.4 - Changed header to correspond to the OpenGL-Shading
- Language specification 1.10 :
- Added new GL_SAMPLER_*-Constants
- Added Constant GL_SHADING_LANGUAGE_VERSION_ARB
- Added Constant GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB
- Added Constant GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB (SW)

Version 1.4a - Fixed a missing stdcall for glBindAttribLocationARB (SW)

Version 1.4b - Fixed declaration for glUniform*(f/i)vARB (added count) (MW)
- glCompileShaderARB changed from function to procedure (MW)

Version 1.5 - Added support for FreePascal (BR)
- Added type TGLVectorf3/TGLVector3f (SW)

Version 1.6 - Added Extension GL_EXT_framebuffer_object (SX)

Version 1.7 - Added Extension GL_ARB_fragment_program_shadow (SX)
- Added Extension GL_ARB_draw_buffers (SX)
- Added Extension GL_ARB_texture_rectangle (SX)
- Added Extension GL_ARB_color_buffer_float (SX)
- Added Extension GL_ARB_half_float_pixel (SX)
- Added Extension GL_ARB_texture_float (SX)
- Added Extension GL_ARB_pixel_buffer_object (SX)
- Added Extension GL_EXT_depth_bounds_test (SX)
- Added Extension GL_EXT_texture_mirror_clamp (SX)
- Added Extension GL_EXT_blend_equation_separate (SX)
- Added Extension GL_EXT_pixel_buffer_object (SX)
- Added Extension GL_EXT_texture_compression_dxt1 (SX)
- Added Extension GL_NV_fragment_program_option (SX)
- Added Extension GL_NV_fragment_program2 (SX)
- Added Extension GL_NV_vertex_program2_option (SX)
- Added Extension GL_NV_vertex_program3 (SX)

Version 1.8 - Added explicit delegate type definitions (LM)
- Added .Net 1.1 Support (LM)
- Added .Net overloaded functions (LM)
- Added delayed extension loading and stubs (LM)
- Added automatic InitOpenGL call in CreateRenderingContext(LM)
- Added extra Read_* function (LM)

Version 2.0 - fixed some Problem with version string and damn drivers.
String 1.15 identified as OpenGL 1.5 not as OpenGL 1.1 (SX)
- Removed unexisting extension GL_ARB_texture_mirror_repeat(SX)
- Added Extension WGL_ARB_pixel_format_float (SX)
- Added Extension GL_EXT_stencil_clear_tag (SX)
- Added Extension GL_EXT_texture_rectangle (SX)
- Added Extension GL_EXT_texture_edge_clamp (SX)
- Some 1.5 Core Consts added (now completed) (SX)
- gluProject need pointer for not .net (SX)
- gluUnProject need pointer for not .net (SX)
- wglUseFontOutlines* need pointer for not .net (SX)
- wglSwapMultipleBuffers need pointer for not .net (SX)
- Bug with wglGetExtensionsStringEXT removed
different type for .net (SX)
- Added OpenGL 2.0 Core (SX)

Version 2.0.1 - fixed some problems with glGetActiveAttrib in 2.0 Core (SX)
- fixes some problems with gluProject (SX)
- fixes some problems with gluUnProject (SX)
- fixes some problems with gluTessVertex (SX)
- fixes some problems with gluLoadSamplingMatrices (SX)

Version 2.1 - Removed .NET Support (SX)
- Better support for Linux (SX)
- Better Codeformation (SX)
- Added some more Vector/Matrix types (SX)
- Added OpenGL 2.1 Core (SX)
- Added Extension GL_EXT_packed_depth_stencil (SX)
- Added Extension GL_EXT_texture_sRGB (SX)
- Added Extension GL_EXT_framebuffer_blit (SX)
- Added Extension GL_EXT_framebuffer_multisample (SX)
- Added Extension GL_EXT_timer_query (SX)
- Added Extension GL_EXT_gpu_program_parameters (SX)
- Added Extension GL_EXT_bindable_uniform (SX)
- Added Extension GL_EXT_draw_buffers2 (SX)
- Added Extension GL_EXT_draw_instanced (SX)
- Added Extension GL_EXT_framebuffer_sRGB (SX)
- Added Extension GL_EXT_geometry_shader4 (SX)
- Added Extension GL_EXT_gpu_shader4 (SX)
- Added Extension GL_EXT_packed_float (SX)
- Added Extension GL_EXT_texture_array (SX)
- Added Extension GL_EXT_texture_buffer_object (SX)
- Added Extension GL_EXT_texture_compression_latc (SX)
- Added Extension GL_EXT_texture_compression_rgtc (SX)
- Added Extension GL_EXT_texture_integer (SX)
- Added Extension GL_EXT_texture_shared_exponent (SX)
- Added Extension GL_NV_depth_buffer_float (SX)
- Added Extension GL_NV_fragment_program4 (SX)
- Added Extension GL_NV_framebuffer_multisample_coverage (SX)
- Added Extension GL_NV_geometry_program4 (SX)
- Added Extension GL_NV_gpu_program4 (SX)
- Added Extension GL_NV_parameter_buffer_object (SX)
- Added Extension GL_NV_transform_feedback (SX)
- Added Extension GL_NV_vertex_program4 (SX)

Version 3.0 - fixed some const of GL_EXT_texture_shared_exponent (SX)
- possible better support for mac (SX)
- Added OpenGL 3.0 Core (SX)
- Added Extension GL_ARB_depth_buffer_float (SX)
- Added Extension GL_ARB_draw_instanced (SX)
- Added Extension GL_ARB_framebuffer_object (SX)
- Added Extension GL_ARB_framebuffer_sRGB (SX)
- Added Extension GL_ARB_geometry_shader4 (SX)
- Added Extension GL_ARB_half_float_vertex (SX)
- Added Extension GL_ARB_instanced_arrays (SX)
- Added Extension GL_ARB_map_buffer_range (SX)
- Added Extension GL_ARB_texture_buffer_object (SX)
- Added Extension GL_ARB_texture_compression_rgtc (SX)
- Added Extension GL_ARB_texture_rg (SX)
- Added Extension GL_ARB_vertex_array_object (SX)
- Added Extension GL_NV_conditional_render (SX)
- Added Extension GL_NV_present_video (SX)
- Added Extension GL_EXT_transform_feedback (SX)
- Added Extension GL_EXT_direct_state_access (SX)
- Added Extension GL_EXT_vertex_array_bgra (SX)
- Added Extension GL_EXT_texture_swizzle (SX)
- Added Extension GL_NV_explicit_multisample (SX)
- Added Extension GL_NV_transform_feedback2 (SX)
- Added Extension WGL_ARB_create_context (SX)
- Added Extension WGL_NV_present_video (SX)
- Added Extension WGL_NV_video_out (SX)
- Added Extension WGL_NV_swap_group (SX)
- Added define DGL_TINY_HEADER to suppress automatic
function loading (SX)
- glProcedure renamed to dglGetProcAddress and now it's
visible from outside the unit to custom load functions (SX)
- dglCheckExtension added to check if an extension exists (SX)
- Read_GL_ARB_buffer_object renamed to
Read_GL_ARB_vertex_buffer_object (SX)

Version 3.0.1 - fixed an problem with fpc (SX)

Version 3.0.2 - fixed an problem with WGL_ARB_create_context (SX)
</pascal>

==Download==

<div align="center">
'''[http://files.delphigl.com/download/dglOpenGL.zip Current dglOpenGL.pas] (Supports ''OpenGL 3.0'', works with Delphi 4 and up and Freepascal))'''

'''[http://files.delphigl.com/download/dglOpenGL_net.zip Last dglOpenGL.pas wit .NET support] (Supports ''OpenGL 2.1'')'''

'''For Delphi 3 users :'''
''[[Benutzer:Mars|Mars]] has posted a version of the dglOpenGL.pas that will work with Delphi 3, you can get it here :<br>
[http://www.delphigl.com/forum/viewtopic.php?p=26697#25642 dglOpenGL.pas for Delphi 3] <br>
''(You need to be registered on the forums to download it)''

''There is also an inofficial version of this [http://www.delphigl.com/forum/viewtopic.php?t=4216 headers for C++].''
</div>

dglOpenGL.pas/en

2009-03-19T15:44:59Z

Sascha Willems:

dglOpenGL.pas/en

2009-03-19T15:43:39Z

Sascha Willems: Die Seite wurde neu angelegt: {{Hinweis| '''Delphi is already shipping with an OpenGL header, but that header is ''outdated and also buggy''. Therefore we ''urge everyone to NOT use that header, esp...

Techniken und Algorithmen

2009-03-09T19:55:19Z

Sascha Willems: /* Sonstiges */

Die Artikel dieses Wiki-Abschnittes sind im Gegensatz zu den [[Tutorial]]s meist kürzer. Dafür enthalten sie mitunter sehr viel Code der direkt verwendet werden, oder als Grundlage für die eigene Arbeit dienen kann.

== Was hier hinein gehört ==
Hier kommen, wie der Name vermuten lässt '''Erklärungen''' zu, in der 3D-Echtzeitprogrammierung verwendeten, '''Techniken''' hin. Z.B. verschiedene Schattentechniken, Bump-Mapping, etc.

[[Hintergrundwissen]] gehört hier nicht rein. Sachen wie ''"was ist ein Tiefenpuffer und wofür ist er gut"'' haben hier nichts zu suchen.<br>
Sollte es für eine Technik/Thematik (siehe unten für Beispiel) mehrere "Lösungswege" geben, sollte eine kleine Überschrift eingefügt werden.

Wenn ihr einen Technik oder Algorithmus Artikel erstellt, so solltet ihr unter den Artikel ein
<nowiki>[[Kategorie:Technik_oder_Algorithmus]]</nowiki>
stellen. Damit wird der Artikel der [[:Kategorie:Technik_oder_Algorithmus]] zugeordnet.
Falls dieser Artikel nicht nur erklärt was der Begriff bedeutet, sondern auch noch eine Anleitung ist, wie man die entsprechende Technik realisiert, so könnt ihr den Artikel auch noch der Kategorie [[:Kategorie:Anleitung|Anleitung]] zuweisen.

== Übersicht ==
=== Sammlungen ===
* [[Materialsammlung]] (Enthält Materialien für [[glMaterial]].)
* [[Shadersammlung]] (Enthält Shader.)

=== Nützliche Helfer ===
In dieser Rubrik findet sich all das, was ein OpenGL/Graphikprogrammierer immer brauch oder schnell mal zur Hand haben muss:
* [[Framecounter]] (Wie schnell läuft mein Programm?)
* [[Frameratenbegrenzung]] (Beschränken der Bildwiederholrate und sparen von CPU-Leistung und Strom)
* [[Texture Loader]] (Laden und verwalten von Texturen)
* [[Model Loader]] (Laden von Modellen die mit Programmen wie 3D Studio Max, Lightwave, Milkshape usw. erstellt wurden.)
* Eine Möglichkeit zum [[Text ausgeben]]
* [[Kamera]]
** [[Kamera (1)]] (Szene in drei Ebenen verschieben und drehen, jetzt mit Beispielprogramm)
** [[Kamera (2)]] (Kamera Source, letztes Update 1.10.2006)
** [[Kamera (3)]] (Für die Kamera benötigte Utilities)
* [[Extensionausgabe]] (Ausgabe der unterstützten Extensions und sonstiger Eigenschaften)
* [[Techniken_zur_Matrixinversion|Techniken zur Matrixinversion]]

=== Mathematisches ===
==== Geometrie Objekte ====
In dieser Rubrik findet ihr Code zum erzeugen von komplexen geometrischen Objekten, denn nicht immer ist die Kapselung die z.B. eine [[Quadrik]] bietet das was man sucht.

* [[Zweifach_Parametrisierte_Geometrie|Geometrie durch zwei Parameter]]
* [[Geometrie_durch_Kurven|Geometrie durch Kurven]]
* [[Rotationskörper]]
* [[Kreis]]
* [[Kuchenstück]]
* [[Kugel]]
* [[Scheibe]]
* [[Würfel]]
* [[Zylinder]]

==== Rechenhilfen ====
* [[Matrixmultiplikation]]

=== Licht und Schatten ===
Das Beleuchtungsmodell von OpenGL besitzt von Haus aus keine Möglichkeit zur Darstellung von Schatten (nicht zuletzt weil es dafür immernoch keine einheitliche Methode gibt), allerdings haben sich über die Jahre hinweg einige Techniken mehr oder weniger durchgesetzt :<br><ul>
<li>[[Lightmaps]]</li>
<li>[[Projezierte Shadowmaps]] / [[Projezierte Textur]]en</li>
<li>[[Volumetrische Stencilschatten]]{{excIcon}}</li>
<li>[[Silhouette]] {{icpIcon}}</li>
<li>[[Bloom(pseudo-HDR)]] {{icpIcon}}</li></ul>

=== Statische Umgebungen ===
Besonders in Aussenszenen ist es oft nötig dem Betrachter den Eindruck zu vermitteln, er befinde sich in einer unendlich großen Umgebung. Da man dies jedoch schlecht über speziell dafür erstellte Geometrie lösen kann (weil das schlichtweg zu viel Aufwand und zu leistungsintensiv wäre), haben sich einige Techniken eingebürgert, mit denen man dem Betrachter eine solche unendliche Landschaft mit wenig Geometrie und einigen Tricks vorgaugeln kann :<br><ul>
<li>[[Skyboxen]]</li>
<li>[[Skydome]]</li>
<li>[[Skysphere]]</li>
</ul>

=== Dynamische Effekte ===
Das Auge ißt bekanntlich mit. Auch bei 3D Anwendungen, vor allem in der Unterhaltungsindustrie, spielen gigantische Effekte, die dem User ein "Ohhh" und "Ahhh" und vor allem "Wow!" entlocken eine immer größere Rolle. Wie man solche Effekte am besten implementiert finden Sie in den Artikeln dieses Abschnitts.<br>
(Befassen Sie sich zuerst mit den Grundlagen von [[Partikelsysteme|Partikelsystemen]].)
<ul>
<li>[[Explosionen]] (Allseits gern gesehen. Außer in direkter Nachbarschaft)</li>
<li>[[Lichtsäulen]] (Bekannt für die magischen Momente in diversen Rollenspielen.) </li>
<li>[[Partikelsysteme]] {{excIcon}} (Grundlage für viele Effekte) </li>
</ul>

=== Natürliche Phänomene ===
Ziel vieler Echtzeit 3D-Anwendung (auch wenn genau der gegenteilige Trend manchmal interessant sein dürfte) ist eine zumindest optische Annäherung an die Realität, also Szenen möglichst "naturgetreu" (auch urbane Szenen können "naturgetreu" sein, auch wenn diese wenig natürlich sind) darzustellen. Dazu gehören auch natürliche Phänomene, wie z.B. realistisch spiegelndes Wasser, Wetterbedingungen (Regen, Schnee, Nebel), Feuer, etc. Oft gibt es für ein natürliches Phänomen recht fortgeschrittene Umsetzungsmöglichkeiten, manchmal liegt die Lösung aber auch recht nahe :<br><ul>
<li>[[Prozeduale Bäume|Bäume]]</li>
<li>[[Blitz]]</li>
<li>[[Feuer]]</li>
<li>[[Himmel]]</li>
<li>[[Nebel]]</li>
<li>[[Staub]]</li>
<li>[[Wasser]]</li>
<li>[[Wettereffekt]]e (Regen, Schnee)</li>
<li>[[Wolken]] (als Ergänzung zu den statischen Umgebungen)</li>
</ul>

=== Raumunterteilungstechniken ===
Moderne 3D-Anwendungen müssen immer größere und komplexere 3D-Umgebungen darstellen, wobei oft jedoch große Teile eben dieser nicht sichtbar sind, aber ohne entsprechende Optimierungen trotzdem über den Datenbus geschoben (und von der Grafikkarte geclippt) werden müssen. Deshalb finden diverse Raumunterteilungstechniken (die u.a. aus anderen Bereichen stammen) in modernen 3D-Programmen Anwendung :<br>
<ul>
<li>[[BSP-Bäume]] (Binary Space Partitioning = Binäre Raumunterteilung)</li>
<li>[[Octree]]s (Dreidimensionale Erweiterung eines Quadtrees)</li>
<li>[[Portal]]e (Logische Sichtbegrenzung an Durchgängen)</li>
<li>[[PVS]] (Potentially Visible Sets = Mögliche sichtbare Sets)</li>
</ul>

=== Terrain Darstellung ===
In vielen 3D Anwendungen, vom Flugsimulator über Egoshooter bis zum Strategiespiel, muss die Umgebung visualisiert werden. Welche Techniken bei der Speicherung (siehe auch '''Raumunterteilungstechniken'''), Bildaufbau und Texturierung zum Einsatz kommen, findet ihr hier:<br>
:'''[[LOD|Level of Detail]] Algorithmen für Landschaften'''

*[[VDPM]] ('''V'''iew-'''D'''ependent '''P'''rogressive '''M'''eshes)
*[[ROAM]] ('''R'''eal-time '''O'''ptimally '''A'''dapting '''M'''eshes)
*[[Tutorial_Terrain3|Röttger Algorithmus]]
*[[Geometrical Mipmapping]]
*[[VIPMs]] ('''V'''iew '''I'''ndependent '''P'''rogressive '''M'''eshe'''s''')

:'''Texturierung'''

*[[Texture Splatting]] (Kombination von Texturen mittels [[Blenden|Blending]] und [[Multitexturing]])
*[[Texture Backing]] (Dynamisches erstellen von Texturen)

=== Prozeduale Grafiken ===
Prozeduale Grafiken werden häufig verwendet um
*eine vielfältige Umgebung zu gewährleisten
*Speicherplatz auf der Festplatte zu sparen
*den Grafikern die Arbeit zu erleichtern (und teilweise sogar erst zu ermöglichen)
Die Algorithmen und Möglichkeiten die sich dabei bieten sind hier aufgelistet:<br><ul>
<li>[[Perlin Noise]] {{excIcon}} (Algorithmus für Texturen, Landschaft und vieles mehr)</li>
<li>[[L-Systems]] (aus wenig mach viel, Landschaftsgenerierung, Baumgenerierung, ...)</li>
<li>[[Fault Formation]] (primär zur Landschaftsgenerierung)</li>
<li>[[Prozeduale Landschaft]] (Spezielle Hinweise und Techniken zur Landschaftsgenerierung</li>
<li>[[Midpoint Displacement]] (primär zur Landschaftsgenerierung)</li>
<li>[[Hügel_Algorithmen]] (primär zur Landschaftsgenerierung)</li>
<li>[[Prozeduale Bäume]] (Techniken und Algorithmen speziell zur Baumgenerierung)</li>
<li>[[Prozeduale Texturen]] (Spezielle Hinweise zu Wasser, Lava und ähnliches)</li>
</ul>

=== Pathfinding ===
Pathfinding ist einer der grundlegenden Bereiche der Künstlichen Intelligenz, und aus diesem Grund für Spiele mit Computergegnern meistens unumgänglich.
<ul>
<li>[[Tiefensuche]]</li>
<li>[[Breitensuche]]</li>
<li>[[A-Stern]]</li>
<li>[[Dijkstra]]</li>
<li>[[Floyd Warshall]]</li>
<li>[[Navigation Meshes]]</li>
<li>[[Pathfinding-Level of Detail]]</li>
</ul>

=== Sonstiges ===

* [[Bilder als Ressourcen]] speichern und laden
* [[Blenderscript|Exportscript für Blender]]
* [[Blenderexporter|Blenderexport ausführliche Anleitung]]
* [[GUI_Leitfaden|Leitfaden Graphisches Nutzerinterface]]
* [[Interpolation]]
* [[Lokalisierung]]
* [[Pixelweise Bildbearbeitung]]
* [[Physik und 3D|Wie verbinde ich Physikberechnung und 3D Rendering?]]
* [[Screenshot]]s von OpenGL Ausgaben
* [[Tesselierung|Polygone tesselieren]]
* [[TGA Bilder laden]]
* [[Zielen auf bewegte Gegner]]

== Externe Links ==
Weitere Links zum Thema "Effekte unter OpenGL" findet ihr in der [[Link]]-Sammlung unter [[Link#Effekte_und_Techniken_mit_OpenGL|Effekte und Techniken mit OpenGL]].

GUI Leitfaden

2009-03-09T19:51:18Z

Sascha Willems:

==Einleitung==
Wer ein etwas komplexeres Spiel mit einer 3D-API entwickelt wird früher oder später an dem Punkt angelangt sein, an dem er eine graphische Benutzeroberfläche (engl. "GUI" - Graphical user interface) benötigt um dem Spieler wichtige Daten zu präsentieren, und um diesen mit dem Spiel interagieren zu lassen. Mit steigender Spielkomplexität wird eine gute GUI immer wichtiger, denn während z.B. ein Jump'n'Run (Beispiele wären hier Sonic, Mario) nur wenige GUI-Elemente benötigt (Punkte, Leben, Lebensenergie) die zudem meist nur als Anzeigen dienen (also keine Nutzerinteraktion erwarten), benötigen komplexe Spiele wie z.B. Strategiespiele komplexe Nutzeroberflächen um alle wichtigen Daten in ansprechender Form präsentieren zu können, und v.a. um den Spieler auch mit dem Spiel interagieren lassen zu können.

In diesem Artikel (es handelt sich hier nicht um ein Tutorial per se) werde ich mein Erfahrungen, die ich während der Entwicklung einer GUI für [http://www.saschawillems.de/?page_id=114 Projekt "W"] gesammelt habe (und immernoch tue, das Projekt wird ja weiterentwickelt), zusammenfassen und so versuchen eine Leitfaden für die Erstellung einer komplexen Spiele-GUI zu geben. Der Artikel soll nicht als Anleitung gesehen werden, sondern wie gesagt als Leitfaden an dem man sich bei der Erstellung der eigenen GUI orientieren kann, nicht soll. Er soll v.a. zeigen welche Dinge es bei der Erstellung einer solchen GUI zu beachten gibt.

==Warum eine eigene GUI?==
Zum einen weil OpenGL keine eigene GUI-Bibliothek bietet, und zum anderen weil man für ein Spiel das eine 3D-API nutzt letztendlich nicht die Standard UI-Elemente des Betriebssystems nutzen kann. Diese sehen nicht nur langweilig aus, sondern deren Aussehen kann auch nur sehr rudimentär angepasst werden. Ausserdem ist nicht garantiert dass diese auch über dem Renderkontext gezeichnet werden. Fertige OpenGL GUI-Bibliotheken gibts es zudem auch kaum, und für Delphi/Pascal (momentan, siehe [[DGLGUI_Pflichtenheft|DGLGUI]]) erst recht nicht.

Zudem trägt die Benutzeroberfläche viel zum ''"Look and Feel"'' eines Spiels bei, weshalb man hier je nach Komplexität letztendlich sowieso eine eigene Lösung entwickeln muss.

[[Bild:wiki_gui_ingame.jpg]]

(Finale GUI aus Projekt "W" - "Phase 2")

==Gedanken zur GUI==
''Hinweis : ''Dieser Abschnitt ist stark von meinem persönlichen Programmierstil gekennzeichnet. Riesige UML-Diagramme oder umfangreiche Planung ist nicht mein Stil, ich programmiere gerne "on-the-fly".

===Objektorientiert entwickeln===

Eigentlich ein "überflüssiger" Punkt, da selbstverständlich. Bei kaum einem anderen Projekt lässt sich OOP so schön und effektiv anwenden wie bei einer GUI. Es sollte ein Basisobjekt geben ('''TGLGUIItem''') welches alle grundlegenden Eigenschaften (''Größe, Position, evtl. auch weiterführende Dinge wie Schriftart'') und Funktionen (''Speichern und Laden, Zeichnen, dort wo nötig mit '''virtual''' arbeiten'') besitzt die siche alle GUI-Element teilen. Hier sollte man aber nicht immer den kleinsten gemeinsamen Nenner suchen, also auch ruhig die ein oder andere Eigenschaft bzw. Funktion ins Grundelement verlegen die nur von zwei oder drei abgeleiteten Elementen genutzt wird. Das kostet zwar ein wenig mehr Speicher, spart aber viel Arbeit.
Zusätzlich zu den Elementen der GUI gibt es dann als Grundelement noch das Fenster '''TGLWindow''') welches letzendlich ein Kontainer für eben diese Objekt ist und ein paar zusätzliche Funktionen zur Nutzerinteraktion bereitstellt.

===Nicht zu sehr an der Windows-UI orientieren===
Auch wenn es naheliegend wäre die eigene GUI an der UI von Windows (oder Linux) zu orientieren sollte man davon Abstand halten. Während die Benutzeroberfläche von Windows für Anwendungen (dazu noch mehrere gleichzeitig) ausgelegt ist, soll die eigene GUI ja auch zum "Look-and-Feel" des Spiels beitragen und auch einfach zu nutzen sein. Die Windows UI ist sehr abstrakt gehalten, da es für sie keinen direkt definierten Einsatzbereich gibt, ist also entsprechend komplex. Bei der GUI für das eigene Spiel (die dann wenn überhaupt nur in weiteren eigenen Spielen genutzt wird) muss man nichtg krampfhaft versuchen diese Funktionalität nachzubauen. Das kostet viel Zeit und Arbeit die man besser in andere Bereiche investiert (Gameplay, Grafik).
Zudem wird man je nach Spiel auch GUI-Elemente benötigen die es so nicht in Windows gibt. In Projekt "W" gibt es z.B. ein Element namens ''TGLSkinnedControl'' welches neben einer Hintergrundtextur Unterelemente besitzt die auf einer polygonalen Auswahlkontur basieren. So hat man ein GUI-Element das quasi jede Form annehmen kann und für grafisch aufwendige GUI-Elemente genutzt werden kann die keiner Standardform entsprechend. Man könnte ein solches Element von der Funktionalität her natürlich auch mit normalen GUI-Elementen (z.B. Buttons) nachbilden, rein optisch wäre dass dann aber weniger schön und würde den "Look-and-Feel" des Spiels stark stören.

===Die GUI parallel zum Spiel entwickeln===
Dieser Punkt ergänzt quasi den oberen Punkt. Wer von Anfang an eine GUI plant die alle möglichen Elemente beinhaltet und alles möglich kann macht sich unnötig viel Arbeit. GUI-Elemente sollte man dann implementieren wenn man diese benötigt, die GUI also nur erweitern wenn dies für das Spiel benötigt wird. Man implementiert zuerst also nur einen Grundstock von Elementen die definitiv benötigt werden, z.B. Fenster, Buttons, Panels, Memos, Listboxen und erweitert dann nach und nach. Da man ja ein Grundelement hat ('''TGLGUIItem''') ist es relativ einfach die GUI um neue Elemente zu erweitern. Das ist letztendlich weitaus effizienter als von Anfang an alle möglichen GUI-Elemente zu implementieren die man dann letztendlich nicht benötigt.

===Keine Unterscheidung zwischen Fenster und GUI===
In einer frühen Version der GUI für Projekt "W" wurde noch zwischen einer Vollbild-GUI (z.B. Hauptmenü, Spielendeschirm) und den normalen Fenstern unterschieden. So etwas soltle man nicht machen, und in der aktuellen Version der GUI für PjW nutzen auch Vollbild-GUI Schirme ein Fenster als Grundlage. Allerdings ist dieses Fenster nicht bewegbar, nicht sichtbar und immer so groß wie der Viewport des Spiels. Dadurch spart man sich viel Arbeit, da man ansonsten vieles doppelt implementieren muss. Also von Anfang an gleich alles auf Fensterbasis entwickeln.

===Ein erweiterbares Format verwenden===
Wie im vorgen Punkt erwähnt wächst die GUI mit dem Spiel, und selbst wenn man abstrakt entwickelt und von Anfang an alles implementiert wird man irgendwann an einen Punkt kommen an dem man die GUI erweitern muss, sei es um neue Elemente, oder einfach nur eine neue Eigenschaft für ein bestehendes Element. Spätestens dann wird es sich auszahlen wenn man ein erweiterbares Format gewählt hat, denn während eigene binäre Format nur schwer zu erweitern sind lassen sich mit einem Format wie XML (für das es in Delphi direkten Support gibt) leicht Veränderungen an der GUI realisieren. Statt sein eigenes Format erweitern zu müssen kann man in XML einfach einen neuen Attribut an einen bestehenden Knoten anhängen oder einfach neue Knoten hinzufügen. Zusätzlich ist XML (wenn man ordentlich Attribut- und Knotennamen vergibt) auch noch vom Menschen lesbar, man kann dort also schnell Fehler finden bzw. es sogar selbst von Hand erweitern.

===Unterstützung für mehrere Sprachen===
Hier sind natürlich nicht Programmiersprachen gemeint, sondern gesprochene Sprachen. Auch wenn man sein Projekt erstmal nur in einer Sprache veröffentlichen will sollte man trotzdem Unterstützung für mehrere Sprachen von Anfang ein einplanen. So etwas direkt einzubinden ist kaum Aufwand, dies später nachzurüsten kann aber durchaus in Arbeit ausarten. Einfachste Methode (die ich auch in Projekt "W" verwende) ist es für alle benötigten Elemente (z.B. die Beschriftung eines Labels oder Buttons) statt eines Strings ein ''String array'' zu verwenden (eine ''TStringList'' wäre hier zu aufwendig). Wenn man dann auch noch ein erweiterbares Dateiformat wie XML verwendet, ist es mit dieser einfachen Methode kein Problem später weitere Sprachen hinzuzufügen. Zur Ausgabe von Text o.ä. greift man dann nicht mehr direkt auf die Variable zu, sondern nutzt eine Funktion (z.B. ''TGLLabel.GetCaption'') die dann je nach eingestellter Sprache (in Projekt "W" wird die eingestellte Sprache in einer Eigenschaft von ''TLocalizationDB'' gespeichert, einer Klasse die sich um das Laden und wechseln der Sprachen kümmert) die passende Beschriftung zurückgibt.

===Von Anfang an einen GUI-Editor mitentwickeln===
Auch wenn man anfänglich noch das ein oder andere Fenster seiner GUI von Hand erstellen kann (dank XML kein Problem), so sollte man doch direkt mit der Entwicklung eines GUI-Editors beginnen. Spätestens wenn man komplexere Fenster erstellen will übersteigt der Zeitaufwand fürs manuelle Erstellen direkt in XML den Zeitaufwand für die Entwicklung eines GUI-Editors. Also am besten gleichzeitig mit der GUI auch den passenden Editor entwickeln.
Hilfreich wäre es zudem wenn direkt in der GUI einige Flags für den Editormodus implementiert werden. Rein optisch wird es zwischen der Darstellung der GUI im Editor und Spiel bis auf Sichtbarkeit einiger Elemente keine Unterschiede geben, aber z.B. bei der Auswahl von Elementen sieht es im Editormodus anders aus als im Spielmodus, und während man im Spiel oft Elemente komplett ausblendet sollten diese im Editor zumindest via Knopfdruck sichtbar zu machen sein.

===Optische Anpassbarkeit und Flexibilität===
In diesem Punkt wird sich die eigene GUI i.d.R. sehr stark von der des Betriebssystems abheben. Zwar bietet z.B. Windows inzwischen Unterstützung für Themes, diese gelten aber global und sind nicht wirklich flexibel. Da die eigene GUI aber oft selbst innerhalb eines einzigen Spiels optisch anpassbar sein sollte (wird sie in mehreren Spielen verwendet ist dies natürlich mandatorisch), muss entsprechende Funktionalität direkt in ihr verankert werden. Grundlegend sind hier sog. ''"Skins"''. Ein ''"Skin"'' (einen passenden deutschen Begriff gibt es hierfür leider nicht) ist im Prinzip eine Textur die alle graphischen Teile der GUI beinhaltet (Fensterrahmen, Buttonteile, Pfeile, etc.) die dann später mittels Texturemapping aus dieser Datei gesampelt werden. Da die eigenen GUI-Elemente in Einzelteilen gerendert werden müssen die entsprechenden Teile nicht 1:1 in der Textur abgelegt werden, sondern werden dann entsprechend beim Rendern des Elements mehrfach oder gestreckt aus dieser Textur gerendert.

[[Bild:wiki_gui_skin.jpg]][[Bild:wiki_gui_skinnedcontrol.jpg]]

Ausserdem sollte die GUI nicht komplett statisch sein, sprich ein Button sollte beginnen sich optisch abzuheben wenn man den Cursor darauf positioniert. Dank OpenGL sollte dies kein Problem sein und hier sind vielfältige Effekte denkbar. In Projekt "W" z.B. ändern sich Buttons beim Mouseover (im "Skin" gibt es für Buttons je einen normalen Teil und einen hervorgehobene), Teile einer TGLSkinnedControl hingegen werden weich eingeblendet und vergrößert und vice versa. Hier sind also kaum Grenzen gesetzt, man könnte dies sogar mit einem [[Partikelsystem]] verbinden dass z.B. Funken sprühen lässt wenn man einen Button selektiert, oder gar Flammen um diesen herum erscheinen lässt. Animationen sind natürlich auch denkbar. Auch hier sollte man sich keinesfalls an Windows orientieren, sondern die Möglichkeiten nutzen die OpenGl bietet. Die GUI für ein Spiel muss nicht immer rein praktischer Natur sein (je nach Spiel darf sie das auch garnicht sein, man denke an Spiele die die GUI direkt ins Gameplay integrieren), hier kann man ruhig mal etwas verspieltes machen.

===Nachrichtenbehandlung (aka ''Messagehandling'')===
In diesem Punkt darf man sich ruhig ein wenig an Windows orientieren, allerdings nicht zu sehr, eine Nachrichtenbehandlung für die eigene GUI muss selten so komplex sein wie eines Betriebssystems. Denn die eigene GUI muss nur auf die Ereignisse einer einzelnen Anwendung reagieren, und nicht auf dutzende geöffnete Anwendungen verteilen. Daher ist diese recht einfach zu implementieren. Im Normalfall sollte es reichen wenn eine Nachricht an alle offenen Fenster weitergereicht wird (in Projekt "W" geschieht dies über einen Callback, siehe weiter unten). Wenn also ein Button gedrückt wird, erzeugt dieser eine Nachricht die dann an einen globalen Verteiler (''TGUI.GlobalWindowMessage'') übergeben wird der diese dann an die Fenster weiterleitet. Innerhalb des entsprechenden Callbacks (''TGLWindow.MessageCallBack'') wird dann überpfüft ob die Nachricht für dieses Fenster vorgesehen ist und wenn ja, wird diese auch hier verarbeitet. Klingt sehr einfach und ist es auch. Mehr wird man aber selten benötigen.

===Callbacks verwenden===
Besonders Anfänger haben gerne mal Probleme mit sog. ''Callbacks'', aber wer etwas fortgeschritten ist lernt diese zu schätzen, tragen sie doch stark zur Flexibilität einer Programmiersprache bei und erlauben es z.B. Zirkelbezüge (zwei Units die gegenseitig auf sich zugreifen wollen) zu umschiffen. Für größere Projekte also fast unumgänglich, und in einer GUI für ein Spiel quasi ein Muss. Warum? Weil man nur so die benötigte (optische) Flexibiliät bekommt die man benötigt, denn nicht immer reicht es wenn man z.B. eine Iconbox (in meinem Falle ein Objekt ähnlich einer Listbox, nur mit Texturen statt Einträgen) einfach alle Texturen rendern lässt. In bestimmten Fällen will man evtl. noch zusätzliche Informationen anzeigen. Ein gutes Beispiel ist die Liste der Spione auf dem Screenshot am Anfang des Artikels. Dahinter steckt eine ''TGLIconBox'' die normalerweise nur die Personalbilder darstellen würde. Dank eines Callbacks der (wenn zugewiesen) bei jedem Rendern eines solchen Bildes aufgerufen wird kann man aber bequem mehr Informationen rendern (Erfahrung, Zusatzsymbole, Name). Ohne Callbacks wäre das kaum, bzw. nur über Umwege machbar. Aber nicht nur für optische Anpassungen sollten Callback verwendet werden, sondern auch um auf Ereignisse zu reagieren. In Projekt "W" hat jedes Fenster einen festen Satz von Callbacks :
<pascal> TGLWindow = class
...
BeforeItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen bevor GUI Elemente gezeichnet werden
AfterItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen nachdem alle GUI Elemente gezeichnet wurden
MessageCallBack : TGLWindowGUIMessageCallBack; // Verarbeitet Nachrichten (also z.B. die Nachricht die von einem gedrückten Button gesendet wird)
UpdateCallBack : TGLWindowUpdateCallBack; // Wird aufgerufen wenn der Inhalt des Fensters aktualisiert werden soll, i.d.R. durch einen globalen Aufruf (''TGLGUI.GlobalWindowUpdate'')
...
end;
</pascal>

===Gruppensichtbarkeit===
In einer komplexen GUI wird man irgendwann bestimmte Objekte ein- bzw. ausblenden müssen. Ein Beispiel aus Projekt "W" : Im Spionageschirm können Spion unterschiedlichen Typs angezeigt werden, und je nach gewähltem Spiontyp müssen z.B. diverse Panels und Labels gezeigt oder auch verstekct werden. In der GUI von Projekt "W" hat daher jedes GUI-Element eine Eigenschaft namens ''GroupID'' über dass die Elemente bestimmten Sichtbarkeitsgruppen zugeordnet werden. Die GUI bietet dann eine Funktion namens ''ToggleVisibility'' mit der man ganze Gruppen ein- und ausblenden kann. Leicht zu implementieren und äusserst praktisch.

==Der GUI-Editor==
Eine komplexe GUI benötigt wie bereits angesprochen einen entsprechenden Editor mit dem man seine Fenster erstellen kann, und da ich im Forum bereits mehrfach darauf angesprochen wurde werde ich anhand des Editors von Projekt "W" aufzeigen wie ich einen GUI-Editor aufgebaut habe. Natürlich ist dieser auch auf meine GUI angepasst (deshalb auch keine Veröffentlichung), aber sicherlich findet hier jeder den ein oder anderen Punkt den er auch gerne in seinem eigenen Editor sehen würde.

[[Bild:wiki_gui_editor.jpg]]

===Echtzeitvorschau===
Die vermutlich wichtigste Komponente des Editors. Sie stellt das aktuelle geladene Fenster bzw. die GUI so dar wie man es im Spiel sieht. Bei Bedarf werden natürlich noch ein paar Dinge eingeblendet, wie z.B. Debuglinien oder Auswahlrahmen. Für den Editor muss man hier noch auf Klicks reagieren um Objekte auszuwählen, diese Funktionalität sollte man aber direkt in der GUI verankern.

===Eigenschaftseditor===
Natürlich muss man die Eigenschaften der gewählten GUI-Elemente irgendwie verändern können. Ähnlich wie in Delphi bietet sich hier ein ''TValueListEditor'' an, der sehr flexibel ist. Neben einfachen Werteingaben kann man hier auch Dropdownlisten für vorgegebene Werte, oder sogar Buttons einfügen die dann einen externen Editor (z.B. für die Punkte einer Region oder den Text eines Memos) aufrufen lässt.
Neben dem Eigenschaftseditor für GUI-Elemente benötigt man natürlich auch einen für das aktuelle Fenster. Hier kann man dann Fenstertitel, Größe und ein paar andere Kleinigkeiten anpassen.

===Möglichkeit direkt neue GUI-Elemente zu erstellen===
Hier gibts nicht viel zu erzählen. Ein GUI-Editor wäre natürlich kaum nützlich wenn man keine neuen GUI-Elemente hinzufügen könnte. Wie man das präsentiert ist dem persönlichen Geschmack überlassen. Mir reicht eine einfache Liste mit allen verfügbaren GUI-Elemente, schöner wären natürlich Icons wie in Delphi. Die Implementation ist hier auch recht einfach, denn die GUI an sich sollte bereits eine Möglichkeit bieten einem Fenster neue Elemente hinzuzufügen (z.B. ''TGLWindow.AddButton(...)''). Dann wird im Editor letztendlich nur (je nach ausgewählten Element) die entsprechende Funktion aus der GUI aufgerufen.

===Umschalten zwischen Editor- und Ingame-GUI===
Eher von praktischem Nutzen ist die Möglichkeit zwischen Editor und der Ingame-GUI umzuschalten. So kann man im Editor schnell sehen wie die GUI im Spiel letztendlich aussieht und reagiert. Denn während im Editormodus i.d.R. alle Elemente angezeigt werden gibt es im Ingame-Modus z.B. graphische Buttons die nur beim Mouseover angezeigt werden sollen.

===Debugmodus===
Wo würde der Debugmodus besser reinpassen als direkt in den Editor? Im Spiel würde er kaum Sinn machen, denn besonders bei Spielen die lange Laden und komplex sind würde es immer ewig dauern bis man den Debugmodus zu Gesicht bekäme. Daher sollte der Editor eine Möglichkeit bieten eben diesen Modus aktivieren zu können. So kann man schnell sehen ob bzw. was nicht stimmt. In der GUI für Projekt "W" ist dieser Modus besonders für das ''TGLSkinnedControl'' sehr nützlich, so kann man direkt sehen wenn z.B. der polygonale Selektionsbereich an der falschen Stelle liegt.
[[Bild:wiki_gui_editor_debug.jpg]]

===Gruppensichtbarkeit===
Die entsprechende Funktionalität ist ja bereits in der GUI selbst vorhanden, und da man im Editor durchaus mehrere Objekte direkt an der selben Stelle liegen hat (siehe Beispiel mit den verschiedenen Spiontypen) ist eine Möglichkeit die Gruppensichtbarkeit einzustellen sehr praktisch. Hierzu iteriert man am besten durch alle GUI-Elemente des Fensters und packt alle Gruppen in eine ''TCheckListBox''. Dort kann man dann per Haken wählen welche Gruppen gerade sichtbar sein sollen. Am besten sollte man direkt in der GUI einen Zeiger auf diese ''TGLCheckListBox'' unterbringen, und beim Rendern in einem Fenster prüft man auf den Editiermodus (Flag in der GUI-Unit) und checkt dann gegen diese Liste welche GUI-Elemente gerendert werden sollen.

===Mehrfachauswahl===
Der Editor sollte die Möglichkeit bieten mehrere GUI-Elemente gleichzetig auswählen zu können. So kann man mehrere Objekte gleichzeitig bearbeiten. Hier muss man dann natürlich Funktionalität implementieren die die geimeinsamen Eigenschaften der gewählten GUI-Elemente ermittelt und diese dann in den Objekteditor schreibt.

===Kleinigkeiten===
Damit sind weniger wichtige Funktionen gemeint die das Arbeiten mit dem GUI-Editor erleichtern oder erweitern. Im Falle des Editors für Projekt "W" gibt es da einige kleine Helfer :
*Hintergrundbild laden (sehr pratkisch um zu sehen wie die GUI auf Spielhintergrund aussieht)
*GUI-Elemente sortieren (sortiert die Elemente der GUI nach Z-Wert neu, u.a. nützlich wenn man Alphatestprobleme hat)
*GUI-Elemente nach Gruppe auswählen (wenn man z.B. ne ganze Objektgruppe auf einmal verschieben oder anpassen will)

GUI Leitfaden

2009-03-09T19:23:03Z

Sascha Willems: /* Der GUI-Editor */

{{Offline}}

''Nach Anregung im Forum entsteht hier ein Artikel zum Thema GUI plus Editor für Spiele. KEIN Tutorial, es wird also weder Code geben noch wird es eine direkte Anleitung. Mehr eine Gedankensammlung und ein Leitfaden aus Erfahrungen mit meiner eigenen GUI.''
--[[Benutzer:Sascha Willems|Sascha Willems]] 12:33, 8. Mär. 2009 (UTC)

==Einleitung==
Wer ein etwas komplexeres Spiel mit einer 3D-API entwickelt wird früher oder später an dem Punkt angelangt sein, an dem er eine graphische Benutzeroberfläche (engl. "GUI" - Graphical user interface) benötigt um dem Spieler wichtige Daten zu präsentieren, und um diesen mit dem Spiel interagieren zu lassen. Mit steigender Spielkomplexität wird eine gute GUI immer wichtiger, denn während z.B. ein Jump'n'Run (Beispiele wären hier Sonic, Mario) nur wenige GUI-Elemente benötigt (Punkte, Leben, Lebensenergie) die zudem meist nur als Anzeigen dienen (also keine Nutzerinteraktion erwarten), benötigen komplexe Spiele wie z.B. Strategiespiele komplexe Nutzeroberflächen um alle wichtigen Daten in ansprechender Form präsentieren zu können, und v.a. um den Spieler auch mit dem Spiel interagieren lassen zu können.

In diesem Artikel (es handelt sich hier nicht um ein Tutorial per se) werde ich mein Erfahrungen, die ich während der Entwicklung einer GUI für [http://www.saschawillems.de/?page_id=114 Projekt "W"] gesammelt habe (und immernoch tue, das Projekt wird ja weiterentwickelt), zusammenfassen und so versuchen eine Leitfaden für die Erstellung einer komplexen Spiele-GUI zu geben. Der Artikel soll nicht als Anleitung gesehen werden, sondern wie gesagt als Leitfaden an dem man sich bei der Erstellung der eigenen GUI orientieren kann, nicht soll. Er soll v.a. zeigen welche Dinge es bei der Erstellung einer solchen GUI zu beachten gibt.

==Warum eine eigene GUI?==
Zum einen weil OpenGL keine eigene GUI-Bibliothek bietet, und zum anderen weil man für ein Spiel das eine 3D-API nutzt letztendlich nicht die Standard UI-Elemente des Betriebssystems nutzen kann. Diese sehen nicht nur langweilig aus, sondern deren Aussehen kann auch nur sehr rudimentär angepasst werden. Ausserdem ist nicht garantiert dass diese auch über dem Renderkontext gezeichnet werden. Fertige OpenGL GUI-Bibliotheken gibts es zudem auch kaum, und für Delphi/Pascal (momentan, siehe [[DGLGUI_Pflichtenheft|DGLGUI]]) erst recht nicht.

Zudem trägt die Benutzeroberfläche viel zum ''"Look and Feel"'' eines Spiels bei, weshalb man hier je nach Komplexität letztendlich sowieso eine eigene Lösung entwickeln muss.

[[Bild:wiki_gui_ingame.jpg]]

(Finale GUI aus Projekt "W" - "Phase 2")

==Gedanken zur GUI==
''Hinweis : ''Dieser Abschnitt ist stark von meinem persönlichen Programmierstil gekennzeichnet. Riesige UML-Diagramme oder umfangreiche Planung ist nicht mein Stil, ich programmiere gerne "on-the-fly".

===Objektorientiert entwickeln===

Eigentlich ein "überflüssiger" Punkt, da selbstverständlich. Bei kaum einem anderen Projekt lässt sich OOP so schön und effektiv anwenden wie bei einer GUI. Es sollte ein Basisobjekt geben ('''TGLGUIItem''') welches alle grundlegenden Eigenschaften (''Größe, Position, evtl. auch weiterführende Dinge wie Schriftart'') und Funktionen (''Speichern und Laden, Zeichnen, dort wo nötig mit '''virtual''' arbeiten'') besitzt die siche alle GUI-Element teilen. Hier sollte man aber nicht immer den kleinsten gemeinsamen Nenner suchen, also auch ruhig die ein oder andere Eigenschaft bzw. Funktion ins Grundelement verlegen die nur von zwei oder drei abgeleiteten Elementen genutzt wird. Das kostet zwar ein wenig mehr Speicher, spart aber viel Arbeit.
Zusätzlich zu den Elementen der GUI gibt es dann als Grundelement noch das Fenster '''TGLWindow''') welches letzendlich ein Kontainer für eben diese Objekt ist und ein paar zusätzliche Funktionen zur Nutzerinteraktion bereitstellt.

===Nicht zu sehr an der Windows-UI orientieren===
Auch wenn es naheliegend wäre die eigene GUI an der UI von Windows (oder Linux) zu orientieren sollte man davon Abstand halten. Während die Benutzeroberfläche von Windows für Anwendungen (dazu noch mehrere gleichzeitig) ausgelegt ist, soll die eigene GUI ja auch zum "Look-and-Feel" des Spiels beitragen und auch einfach zu nutzen sein. Die Windows UI ist sehr abstrakt gehalten, da es für sie keinen direkt definierten Einsatzbereich gibt, ist also entsprechend komplex. Bei der GUI für das eigene Spiel (die dann wenn überhaupt nur in weiteren eigenen Spielen genutzt wird) muss man nichtg krampfhaft versuchen diese Funktionalität nachzubauen. Das kostet viel Zeit und Arbeit die man besser in andere Bereiche investiert (Gameplay, Grafik).
Zudem wird man je nach Spiel auch GUI-Elemente benötigen die es so nicht in Windows gibt. In Projekt "W" gibt es z.B. ein Element namens ''TGLSkinnedControl'' welches neben einer Hintergrundtextur Unterelemente besitzt die auf einer polygonalen Auswahlkontur basieren. So hat man ein GUI-Element das quasi jede Form annehmen kann und für grafisch aufwendige GUI-Elemente genutzt werden kann die keiner Standardform entsprechend. Man könnte ein solches Element von der Funktionalität her natürlich auch mit normalen GUI-Elementen (z.B. Buttons) nachbilden, rein optisch wäre dass dann aber weniger schön und würde den "Look-and-Feel" des Spiels stark stören.

===Die GUI parallel zum Spiel entwickeln===
Dieser Punkt ergänzt quasi den oberen Punkt. Wer von Anfang an eine GUI plant die alle möglichen Elemente beinhaltet und alles möglich kann macht sich unnötig viel Arbeit. GUI-Elemente sollte man dann implementieren wenn man diese benötigt, die GUI also nur erweitern wenn dies für das Spiel benötigt wird. Man implementiert zuerst also nur einen Grundstock von Elementen die definitiv benötigt werden, z.B. Fenster, Buttons, Panels, Memos, Listboxen und erweitert dann nach und nach. Da man ja ein Grundelement hat ('''TGLGUIItem''') ist es relativ einfach die GUI um neue Elemente zu erweitern. Das ist letztendlich weitaus effizienter als von Anfang an alle möglichen GUI-Elemente zu implementieren die man dann letztendlich nicht benötigt.

===Keine Unterscheidung zwischen Fenster und GUI===
In einer frühen Version der GUI für Projekt "W" wurde noch zwischen einer Vollbild-GUI (z.B. Hauptmenü, Spielendeschirm) und den normalen Fenstern unterschieden. So etwas soltle man nicht machen, und in der aktuellen Version der GUI für PjW nutzen auch Vollbild-GUI Schirme ein Fenster als Grundlage. Allerdings ist dieses Fenster nicht bewegbar, nicht sichtbar und immer so groß wie der Viewport des Spiels. Dadurch spart man sich viel Arbeit, da man ansonsten vieles doppelt implementieren muss. Also von Anfang an gleich alles auf Fensterbasis entwickeln.

===Ein erweiterbares Format verwenden===
Wie im vorgen Punkt erwähnt wächst die GUI mit dem Spiel, und selbst wenn man abstrakt entwickelt und von Anfang an alles implementiert wird man irgendwann an einen Punkt kommen an dem man die GUI erweitern muss, sei es um neue Elemente, oder einfach nur eine neue Eigenschaft für ein bestehendes Element. Spätestens dann wird es sich auszahlen wenn man ein erweiterbares Format gewählt hat, denn während eigene binäre Format nur schwer zu erweitern sind lassen sich mit einem Format wie XML (für das es in Delphi direkten Support gibt) leicht Veränderungen an der GUI realisieren. Statt sein eigenes Format erweitern zu müssen kann man in XML einfach einen neuen Attribut an einen bestehenden Knoten anhängen oder einfach neue Knoten hinzufügen. Zusätzlich ist XML (wenn man ordentlich Attribut- und Knotennamen vergibt) auch noch vom Menschen lesbar, man kann dort also schnell Fehler finden bzw. es sogar selbst von Hand erweitern.

===Unterstützung für mehrere Sprachen===
Hier sind natürlich nicht Programmiersprachen gemeint, sondern gesprochene Sprachen. Auch wenn man sein Projekt erstmal nur in einer Sprache veröffentlichen will sollte man trotzdem Unterstützung für mehrere Sprachen von Anfang ein einplanen. So etwas direkt einzubinden ist kaum Aufwand, dies später nachzurüsten kann aber durchaus in Arbeit ausarten. Einfachste Methode (die ich auch in Projekt "W" verwende) ist es für alle benötigten Elemente (z.B. die Beschriftung eines Labels oder Buttons) statt eines Strings ein ''String array'' zu verwenden (eine ''TStringList'' wäre hier zu aufwendig). Wenn man dann auch noch ein erweiterbares Dateiformat wie XML verwendet, ist es mit dieser einfachen Methode kein Problem später weitere Sprachen hinzuzufügen. Zur Ausgabe von Text o.ä. greift man dann nicht mehr direkt auf die Variable zu, sondern nutzt eine Funktion (z.B. ''TGLLabel.GetCaption'') die dann je nach eingestellter Sprache (in Projekt "W" wird die eingestellte Sprache in einer Eigenschaft von ''TLocalizationDB'' gespeichert, einer Klasse die sich um das Laden und wechseln der Sprachen kümmert) die passende Beschriftung zurückgibt.

===Von Anfang an einen GUI-Editor mitentwickeln===
Auch wenn man anfänglich noch das ein oder andere Fenster seiner GUI von Hand erstellen kann (dank XML kein Problem), so sollte man doch direkt mit der Entwicklung eines GUI-Editors beginnen. Spätestens wenn man komplexere Fenster erstellen will übersteigt der Zeitaufwand fürs manuelle Erstellen direkt in XML den Zeitaufwand für die Entwicklung eines GUI-Editors. Also am besten gleichzeitig mit der GUI auch den passenden Editor entwickeln.
Hilfreich wäre es zudem wenn direkt in der GUI einige Flags für den Editormodus implementiert werden. Rein optisch wird es zwischen der Darstellung der GUI im Editor und Spiel bis auf Sichtbarkeit einiger Elemente keine Unterschiede geben, aber z.B. bei der Auswahl von Elementen sieht es im Editormodus anders aus als im Spielmodus, und während man im Spiel oft Elemente komplett ausblendet sollten diese im Editor zumindest via Knopfdruck sichtbar zu machen sein.

===Optische Anpassbarkeit und Flexibilität===
In diesem Punkt wird sich die eigene GUI i.d.R. sehr stark von der des Betriebssystems abheben. Zwar bietet z.B. Windows inzwischen Unterstützung für Themes, diese gelten aber global und sind nicht wirklich flexibel. Da die eigene GUI aber oft selbst innerhalb eines einzigen Spiels optisch anpassbar sein sollte (wird sie in mehreren Spielen verwendet ist dies natürlich mandatorisch), muss entsprechende Funktionalität direkt in ihr verankert werden. Grundlegend sind hier sog. ''"Skins"''. Ein ''"Skin"'' (einen passenden deutschen Begriff gibt es hierfür leider nicht) ist im Prinzip eine Textur die alle graphischen Teile der GUI beinhaltet (Fensterrahmen, Buttonteile, Pfeile, etc.) die dann später mittels Texturemapping aus dieser Datei gesampelt werden. Da die eigenen GUI-Elemente in Einzelteilen gerendert werden müssen die entsprechenden Teile nicht 1:1 in der Textur abgelegt werden, sondern werden dann entsprechend beim Rendern des Elements mehrfach oder gestreckt aus dieser Textur gerendert.

[[Bild:wiki_gui_skin.jpg]][[Bild:wiki_gui_skinnedcontrol.jpg]]

Ausserdem sollte die GUI nicht komplett statisch sein, sprich ein Button sollte beginnen sich optisch abzuheben wenn man den Cursor darauf positioniert. Dank OpenGL sollte dies kein Problem sein und hier sind vielfältige Effekte denkbar. In Projekt "W" z.B. ändern sich Buttons beim Mouseover (im "Skin" gibt es für Buttons je einen normalen Teil und einen hervorgehobene), Teile einer TGLSkinnedControl hingegen werden weich eingeblendet und vergrößert und vice versa. Hier sind also kaum Grenzen gesetzt, man könnte dies sogar mit einem [[Partikelsystem]] verbinden dass z.B. Funken sprühen lässt wenn man einen Button selektiert, oder gar Flammen um diesen herum erscheinen lässt. Animationen sind natürlich auch denkbar. Auch hier sollte man sich keinesfalls an Windows orientieren, sondern die Möglichkeiten nutzen die OpenGl bietet. Die GUI für ein Spiel muss nicht immer rein praktischer Natur sein (je nach Spiel darf sie das auch garnicht sein, man denke an Spiele die die GUI direkt ins Gameplay integrieren), hier kann man ruhig mal etwas verspieltes machen.

===Nachrichtenbehandlung (aka ''Messagehandling'')===
In diesem Punkt darf man sich ruhig ein wenig an Windows orientieren, allerdings nicht zu sehr, eine Nachrichtenbehandlung für die eigene GUI muss selten so komplex sein wie eines Betriebssystems. Denn die eigene GUI muss nur auf die Ereignisse einer einzelnen Anwendung reagieren, und nicht auf dutzende geöffnete Anwendungen verteilen. Daher ist diese recht einfach zu implementieren. Im Normalfall sollte es reichen wenn eine Nachricht an alle offenen Fenster weitergereicht wird (in Projekt "W" geschieht dies über einen Callback, siehe weiter unten). Wenn also ein Button gedrückt wird, erzeugt dieser eine Nachricht die dann an einen globalen Verteiler (''TGUI.GlobalWindowMessage'') übergeben wird der diese dann an die Fenster weiterleitet. Innerhalb des entsprechenden Callbacks (''TGLWindow.MessageCallBack'') wird dann überpfüft ob die Nachricht für dieses Fenster vorgesehen ist und wenn ja, wird diese auch hier verarbeitet. Klingt sehr einfach und ist es auch. Mehr wird man aber selten benötigen.

===Callbacks verwenden===
Besonders Anfänger haben gerne mal Probleme mit sog. ''Callbacks'', aber wer etwas fortgeschritten ist lernt diese zu schätzen, tragen sie doch stark zur Flexibilität einer Programmiersprache bei und erlauben es z.B. Zirkelbezüge (zwei Units die gegenseitig auf sich zugreifen wollen) zu umschiffen. Für größere Projekte also fast unumgänglich, und in einer GUI für ein Spiel quasi ein Muss. Warum? Weil man nur so die benötigte (optische) Flexibiliät bekommt die man benötigt, denn nicht immer reicht es wenn man z.B. eine Iconbox (in meinem Falle ein Objekt ähnlich einer Listbox, nur mit Texturen statt Einträgen) einfach alle Texturen rendern lässt. In bestimmten Fällen will man evtl. noch zusätzliche Informationen anzeigen. Ein gutes Beispiel ist die Liste der Spione auf dem Screenshot am Anfang des Artikels. Dahinter steckt eine ''TGLIconBox'' die normalerweise nur die Personalbilder darstellen würde. Dank eines Callbacks der (wenn zugewiesen) bei jedem Rendern eines solchen Bildes aufgerufen wird kann man aber bequem mehr Informationen rendern (Erfahrung, Zusatzsymbole, Name). Ohne Callbacks wäre das kaum, bzw. nur über Umwege machbar. Aber nicht nur für optische Anpassungen sollten Callback verwendet werden, sondern auch um auf Ereignisse zu reagieren. In Projekt "W" hat jedes Fenster einen festen Satz von Callbacks :
<pascal> TGLWindow = class
...
BeforeItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen bevor GUI Elemente gezeichnet werden
AfterItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen nachdem alle GUI Elemente gezeichnet wurden
MessageCallBack : TGLWindowGUIMessageCallBack; // Verarbeitet Nachrichten (also z.B. die Nachricht die von einem gedrückten Button gesendet wird)
UpdateCallBack : TGLWindowUpdateCallBack; // Wird aufgerufen wenn der Inhalt des Fensters aktualisiert werden soll, i.d.R. durch einen globalen Aufruf (''TGLGUI.GlobalWindowUpdate'')
...
end;
</pascal>

===Gruppensichtbarkeit===
In einer komplexen GUI wird man irgendwann bestimmte Objekte ein- bzw. ausblenden müssen. Ein Beispiel aus Projekt "W" : Im Spionageschirm können Spion unterschiedlichen Typs angezeigt werden, und je nach gewähltem Spiontyp müssen z.B. diverse Panels und Labels gezeigt oder auch verstekct werden. In der GUI von Projekt "W" hat daher jedes GUI-Element eine Eigenschaft namens ''GroupID'' über dass die Elemente bestimmten Sichtbarkeitsgruppen zugeordnet werden. Die GUI bietet dann eine Funktion namens ''ToggleVisibility'' mit der man ganze Gruppen ein- und ausblenden kann. Leicht zu implementieren und äusserst praktisch.

==Der GUI-Editor==
Eine komplexe GUI benötigt wie bereits angesprochen einen entsprechenden Editor mit dem man seine Fenster erstellen kann, und da ich im Forum bereits mehrfach darauf angesprochen wurde werde ich anhand des Editors von Projekt "W" aufzeigen wie ich einen GUI-Editor aufgebaut habe. Natürlich ist dieser auch auf meine GUI angepasst (deshalb auch keine Veröffentlichung), aber sicherlich findet hier jeder den ein oder anderen Punkt den er auch gerne in seinem eigenen Editor sehen würde.

[[Bild:wiki_gui_editor.jpg]]

===Echtzeitvorschau===
Die vermutlich wichtigste Komponente des Editors. Sie stellt das aktuelle geladene Fenster bzw. die GUI so dar wie man es im Spiel sieht. Bei Bedarf werden natürlich noch ein paar Dinge eingeblendet, wie z.B. Debuglinien oder Auswahlrahmen. Für den Editor muss man hier noch auf Klicks reagieren um Objekte auszuwählen, diese Funktionalität sollte man aber direkt in der GUI verankern.

===Eigenschaftseditor===
Natürlich muss man die Eigenschaften der gewählten GUI-Elemente irgendwie verändern können. Ähnlich wie in Delphi bietet sich hier ein ''TValueListEditor'' an, der sehr flexibel ist. Neben einfachen Werteingaben kann man hier auch Dropdownlisten für vorgegebene Werte, oder sogar Buttons einfügen die dann einen externen Editor (z.B. für die Punkte einer Region oder den Text eines Memos) aufrufen lässt.
Neben dem Eigenschaftseditor für GUI-Elemente benötigt man natürlich auch einen für das aktuelle Fenster. Hier kann man dann Fenstertitel, Größe und ein paar andere Kleinigkeiten anpassen.

===Möglichkeit direkt neue GUI-Elemente zu erstellen===
Hier gibts nicht viel zu erzählen. Ein GUI-Editor wäre natürlich kaum nützlich wenn man keine neuen GUI-Elemente hinzufügen könnte. Wie man das präsentiert ist dem persönlichen Geschmack überlassen. Mir reicht eine einfache Liste mit allen verfügbaren GUI-Elemente, schöner wären natürlich Icons wie in Delphi. Die Implementation ist hier auch recht einfach, denn die GUI an sich sollte bereits eine Möglichkeit bieten einem Fenster neue Elemente hinzuzufügen (z.B. ''TGLWindow.AddButton(...)''). Dann wird im Editor letztendlich nur (je nach ausgewählten Element) die entsprechende Funktion aus der GUI aufgerufen.

===Umschalten zwischen Editor- und Ingame-GUI===
Eher von praktischem Nutzen ist die Möglichkeit zwischen Editor und der Ingame-GUI umzuschalten. So kann man im Editor schnell sehen wie die GUI im Spiel letztendlich aussieht und reagiert. Denn während im Editormodus i.d.R. alle Elemente angezeigt werden gibt es im Ingame-Modus z.B. graphische Buttons die nur beim Mouseover angezeigt werden sollen.

===Debugmodus===
Wo würde der Debugmodus besser reinpassen als direkt in den Editor? Im Spiel würde er kaum Sinn machen, denn besonders bei Spielen die lange Laden und komplex sind würde es immer ewig dauern bis man den Debugmodus zu Gesicht bekäme. Daher sollte der Editor eine Möglichkeit bieten eben diesen Modus aktivieren zu können. So kann man schnell sehen ob bzw. was nicht stimmt. In der GUI für Projekt "W" ist dieser Modus besonders für das ''TGLSkinnedControl'' sehr nützlich, so kann man direkt sehen wenn z.B. der polygonale Selektionsbereich an der falschen Stelle liegt.
[[Bild:wiki_gui_editor_debug.jpg]]

===Gruppensichtbarkeit===
Die entsprechende Funktionalität ist ja bereits in der GUI selbst vorhanden, und da man im Editor durchaus mehrere Objekte direkt an der selben Stelle liegen hat (siehe Beispiel mit den verschiedenen Spiontypen) ist eine Möglichkeit die Gruppensichtbarkeit einzustellen sehr praktisch. Hierzu iteriert man am besten durch alle GUI-Elemente des Fensters und packt alle Gruppen in eine ''TCheckListBox''. Dort kann man dann per Haken wählen welche Gruppen gerade sichtbar sein sollen. Am besten sollte man direkt in der GUI einen Zeiger auf diese ''TGLCheckListBox'' unterbringen, und beim Rendern in einem Fenster prüft man auf den Editiermodus (Flag in der GUI-Unit) und checkt dann gegen diese Liste welche GUI-Elemente gerendert werden sollen.

===Mehrfachauswahl===
Der Editor sollte die Möglichkeit bieten mehrere GUI-Elemente gleichzetig auswählen zu können. So kann man mehrere Objekte gleichzeitig bearbeiten. Hier muss man dann natürlich Funktionalität implementieren die die geimeinsamen Eigenschaften der gewählten GUI-Elemente ermittelt und diese dann in den Objekteditor schreibt.

===Kleinigkeiten===
Damit sind weniger wichtige Funktionen gemeint die das Arbeiten mit dem GUI-Editor erleichtern oder erweitern. Im Falle des Editors für Projekt "W" gibt es da einige kleine Helfer :
*Hintergrundbild laden (sehr pratkisch um zu sehen wie die GUI auf Spielhintergrund aussieht)
*GUI-Elemente sortieren (sortiert die Elemente der GUI nach Z-Wert neu, u.a. nützlich wenn man Alphatestprobleme hat)
*GUI-Elemente nach Gruppe auswählen (wenn man z.B. ne ganze Objektgruppe auf einmal verschieben oder anpassen will)

Datei:wiki gui editor debug.jpg

2009-03-09T19:08:30Z

GUI Leitfaden

2009-03-09T18:55:46Z

Sascha Willems:

{{Offline}}

''Nach Anregung im Forum entsteht hier ein Artikel zum Thema GUI plus Editor für Spiele. KEIN Tutorial, es wird also weder Code geben noch wird es eine direkte Anleitung. Mehr eine Gedankensammlung und ein Leitfaden aus Erfahrungen mit meiner eigenen GUI.''
--[[Benutzer:Sascha Willems|Sascha Willems]] 12:33, 8. Mär. 2009 (UTC)

==Einleitung==
Wer ein etwas komplexeres Spiel mit einer 3D-API entwickelt wird früher oder später an dem Punkt angelangt sein, an dem er eine graphische Benutzeroberfläche (engl. "GUI" - Graphical user interface) benötigt um dem Spieler wichtige Daten zu präsentieren, und um diesen mit dem Spiel interagieren zu lassen. Mit steigender Spielkomplexität wird eine gute GUI immer wichtiger, denn während z.B. ein Jump'n'Run (Beispiele wären hier Sonic, Mario) nur wenige GUI-Elemente benötigt (Punkte, Leben, Lebensenergie) die zudem meist nur als Anzeigen dienen (also keine Nutzerinteraktion erwarten), benötigen komplexe Spiele wie z.B. Strategiespiele komplexe Nutzeroberflächen um alle wichtigen Daten in ansprechender Form präsentieren zu können, und v.a. um den Spieler auch mit dem Spiel interagieren lassen zu können.

In diesem Artikel (es handelt sich hier nicht um ein Tutorial per se) werde ich mein Erfahrungen, die ich während der Entwicklung einer GUI für [http://www.saschawillems.de/?page_id=114 Projekt "W"] gesammelt habe (und immernoch tue, das Projekt wird ja weiterentwickelt), zusammenfassen und so versuchen eine Leitfaden für die Erstellung einer komplexen Spiele-GUI zu geben. Der Artikel soll nicht als Anleitung gesehen werden, sondern wie gesagt als Leitfaden an dem man sich bei der Erstellung der eigenen GUI orientieren kann, nicht soll. Er soll v.a. zeigen welche Dinge es bei der Erstellung einer solchen GUI zu beachten gibt.

==Warum eine eigene GUI?==
Zum einen weil OpenGL keine eigene GUI-Bibliothek bietet, und zum anderen weil man für ein Spiel das eine 3D-API nutzt letztendlich nicht die Standard UI-Elemente des Betriebssystems nutzen kann. Diese sehen nicht nur langweilig aus, sondern deren Aussehen kann auch nur sehr rudimentär angepasst werden. Ausserdem ist nicht garantiert dass diese auch über dem Renderkontext gezeichnet werden. Fertige OpenGL GUI-Bibliotheken gibts es zudem auch kaum, und für Delphi/Pascal (momentan, siehe [[DGLGUI_Pflichtenheft|DGLGUI]]) erst recht nicht.

Zudem trägt die Benutzeroberfläche viel zum ''"Look and Feel"'' eines Spiels bei, weshalb man hier je nach Komplexität letztendlich sowieso eine eigene Lösung entwickeln muss.

[[Bild:wiki_gui_ingame.jpg]]

(Finale GUI aus Projekt "W" - "Phase 2")

==Gedanken zur GUI==
''Hinweis : ''Dieser Abschnitt ist stark von meinem persönlichen Programmierstil gekennzeichnet. Riesige UML-Diagramme oder umfangreiche Planung ist nicht mein Stil, ich programmiere gerne "on-the-fly".

===Objektorientiert entwickeln===

Eigentlich ein "überflüssiger" Punkt, da selbstverständlich. Bei kaum einem anderen Projekt lässt sich OOP so schön und effektiv anwenden wie bei einer GUI. Es sollte ein Basisobjekt geben ('''TGLGUIItem''') welches alle grundlegenden Eigenschaften (''Größe, Position, evtl. auch weiterführende Dinge wie Schriftart'') und Funktionen (''Speichern und Laden, Zeichnen, dort wo nötig mit '''virtual''' arbeiten'') besitzt die siche alle GUI-Element teilen. Hier sollte man aber nicht immer den kleinsten gemeinsamen Nenner suchen, also auch ruhig die ein oder andere Eigenschaft bzw. Funktion ins Grundelement verlegen die nur von zwei oder drei abgeleiteten Elementen genutzt wird. Das kostet zwar ein wenig mehr Speicher, spart aber viel Arbeit.
Zusätzlich zu den Elementen der GUI gibt es dann als Grundelement noch das Fenster '''TGLWindow''') welches letzendlich ein Kontainer für eben diese Objekt ist und ein paar zusätzliche Funktionen zur Nutzerinteraktion bereitstellt.

===Nicht zu sehr an der Windows-UI orientieren===
Auch wenn es naheliegend wäre die eigene GUI an der UI von Windows (oder Linux) zu orientieren sollte man davon Abstand halten. Während die Benutzeroberfläche von Windows für Anwendungen (dazu noch mehrere gleichzeitig) ausgelegt ist, soll die eigene GUI ja auch zum "Look-and-Feel" des Spiels beitragen und auch einfach zu nutzen sein. Die Windows UI ist sehr abstrakt gehalten, da es für sie keinen direkt definierten Einsatzbereich gibt, ist also entsprechend komplex. Bei der GUI für das eigene Spiel (die dann wenn überhaupt nur in weiteren eigenen Spielen genutzt wird) muss man nichtg krampfhaft versuchen diese Funktionalität nachzubauen. Das kostet viel Zeit und Arbeit die man besser in andere Bereiche investiert (Gameplay, Grafik).
Zudem wird man je nach Spiel auch GUI-Elemente benötigen die es so nicht in Windows gibt. In Projekt "W" gibt es z.B. ein Element namens ''TGLSkinnedControl'' welches neben einer Hintergrundtextur Unterelemente besitzt die auf einer polygonalen Auswahlkontur basieren. So hat man ein GUI-Element das quasi jede Form annehmen kann und für grafisch aufwendige GUI-Elemente genutzt werden kann die keiner Standardform entsprechend. Man könnte ein solches Element von der Funktionalität her natürlich auch mit normalen GUI-Elementen (z.B. Buttons) nachbilden, rein optisch wäre dass dann aber weniger schön und würde den "Look-and-Feel" des Spiels stark stören.

===Die GUI parallel zum Spiel entwickeln===
Dieser Punkt ergänzt quasi den oberen Punkt. Wer von Anfang an eine GUI plant die alle möglichen Elemente beinhaltet und alles möglich kann macht sich unnötig viel Arbeit. GUI-Elemente sollte man dann implementieren wenn man diese benötigt, die GUI also nur erweitern wenn dies für das Spiel benötigt wird. Man implementiert zuerst also nur einen Grundstock von Elementen die definitiv benötigt werden, z.B. Fenster, Buttons, Panels, Memos, Listboxen und erweitert dann nach und nach. Da man ja ein Grundelement hat ('''TGLGUIItem''') ist es relativ einfach die GUI um neue Elemente zu erweitern. Das ist letztendlich weitaus effizienter als von Anfang an alle möglichen GUI-Elemente zu implementieren die man dann letztendlich nicht benötigt.

===Keine Unterscheidung zwischen Fenster und GUI===
In einer frühen Version der GUI für Projekt "W" wurde noch zwischen einer Vollbild-GUI (z.B. Hauptmenü, Spielendeschirm) und den normalen Fenstern unterschieden. So etwas soltle man nicht machen, und in der aktuellen Version der GUI für PjW nutzen auch Vollbild-GUI Schirme ein Fenster als Grundlage. Allerdings ist dieses Fenster nicht bewegbar, nicht sichtbar und immer so groß wie der Viewport des Spiels. Dadurch spart man sich viel Arbeit, da man ansonsten vieles doppelt implementieren muss. Also von Anfang an gleich alles auf Fensterbasis entwickeln.

===Ein erweiterbares Format verwenden===
Wie im vorgen Punkt erwähnt wächst die GUI mit dem Spiel, und selbst wenn man abstrakt entwickelt und von Anfang an alles implementiert wird man irgendwann an einen Punkt kommen an dem man die GUI erweitern muss, sei es um neue Elemente, oder einfach nur eine neue Eigenschaft für ein bestehendes Element. Spätestens dann wird es sich auszahlen wenn man ein erweiterbares Format gewählt hat, denn während eigene binäre Format nur schwer zu erweitern sind lassen sich mit einem Format wie XML (für das es in Delphi direkten Support gibt) leicht Veränderungen an der GUI realisieren. Statt sein eigenes Format erweitern zu müssen kann man in XML einfach einen neuen Attribut an einen bestehenden Knoten anhängen oder einfach neue Knoten hinzufügen. Zusätzlich ist XML (wenn man ordentlich Attribut- und Knotennamen vergibt) auch noch vom Menschen lesbar, man kann dort also schnell Fehler finden bzw. es sogar selbst von Hand erweitern.

===Unterstützung für mehrere Sprachen===
Hier sind natürlich nicht Programmiersprachen gemeint, sondern gesprochene Sprachen. Auch wenn man sein Projekt erstmal nur in einer Sprache veröffentlichen will sollte man trotzdem Unterstützung für mehrere Sprachen von Anfang ein einplanen. So etwas direkt einzubinden ist kaum Aufwand, dies später nachzurüsten kann aber durchaus in Arbeit ausarten. Einfachste Methode (die ich auch in Projekt "W" verwende) ist es für alle benötigten Elemente (z.B. die Beschriftung eines Labels oder Buttons) statt eines Strings ein ''String array'' zu verwenden (eine ''TStringList'' wäre hier zu aufwendig). Wenn man dann auch noch ein erweiterbares Dateiformat wie XML verwendet, ist es mit dieser einfachen Methode kein Problem später weitere Sprachen hinzuzufügen. Zur Ausgabe von Text o.ä. greift man dann nicht mehr direkt auf die Variable zu, sondern nutzt eine Funktion (z.B. ''TGLLabel.GetCaption'') die dann je nach eingestellter Sprache (in Projekt "W" wird die eingestellte Sprache in einer Eigenschaft von ''TLocalizationDB'' gespeichert, einer Klasse die sich um das Laden und wechseln der Sprachen kümmert) die passende Beschriftung zurückgibt.

===Von Anfang an einen GUI-Editor mitentwickeln===
Auch wenn man anfänglich noch das ein oder andere Fenster seiner GUI von Hand erstellen kann (dank XML kein Problem), so sollte man doch direkt mit der Entwicklung eines GUI-Editors beginnen. Spätestens wenn man komplexere Fenster erstellen will übersteigt der Zeitaufwand fürs manuelle Erstellen direkt in XML den Zeitaufwand für die Entwicklung eines GUI-Editors. Also am besten gleichzeitig mit der GUI auch den passenden Editor entwickeln.
Hilfreich wäre es zudem wenn direkt in der GUI einige Flags für den Editormodus implementiert werden. Rein optisch wird es zwischen der Darstellung der GUI im Editor und Spiel bis auf Sichtbarkeit einiger Elemente keine Unterschiede geben, aber z.B. bei der Auswahl von Elementen sieht es im Editormodus anders aus als im Spielmodus, und während man im Spiel oft Elemente komplett ausblendet sollten diese im Editor zumindest via Knopfdruck sichtbar zu machen sein.

===Optische Anpassbarkeit und Flexibilität===
In diesem Punkt wird sich die eigene GUI i.d.R. sehr stark von der des Betriebssystems abheben. Zwar bietet z.B. Windows inzwischen Unterstützung für Themes, diese gelten aber global und sind nicht wirklich flexibel. Da die eigene GUI aber oft selbst innerhalb eines einzigen Spiels optisch anpassbar sein sollte (wird sie in mehreren Spielen verwendet ist dies natürlich mandatorisch), muss entsprechende Funktionalität direkt in ihr verankert werden. Grundlegend sind hier sog. ''"Skins"''. Ein ''"Skin"'' (einen passenden deutschen Begriff gibt es hierfür leider nicht) ist im Prinzip eine Textur die alle graphischen Teile der GUI beinhaltet (Fensterrahmen, Buttonteile, Pfeile, etc.) die dann später mittels Texturemapping aus dieser Datei gesampelt werden. Da die eigenen GUI-Elemente in Einzelteilen gerendert werden müssen die entsprechenden Teile nicht 1:1 in der Textur abgelegt werden, sondern werden dann entsprechend beim Rendern des Elements mehrfach oder gestreckt aus dieser Textur gerendert.

[[Bild:wiki_gui_skin.jpg]][[Bild:wiki_gui_skinnedcontrol.jpg]]

Ausserdem sollte die GUI nicht komplett statisch sein, sprich ein Button sollte beginnen sich optisch abzuheben wenn man den Cursor darauf positioniert. Dank OpenGL sollte dies kein Problem sein und hier sind vielfältige Effekte denkbar. In Projekt "W" z.B. ändern sich Buttons beim Mouseover (im "Skin" gibt es für Buttons je einen normalen Teil und einen hervorgehobene), Teile einer TGLSkinnedControl hingegen werden weich eingeblendet und vergrößert und vice versa. Hier sind also kaum Grenzen gesetzt, man könnte dies sogar mit einem [[Partikelsystem]] verbinden dass z.B. Funken sprühen lässt wenn man einen Button selektiert, oder gar Flammen um diesen herum erscheinen lässt. Animationen sind natürlich auch denkbar. Auch hier sollte man sich keinesfalls an Windows orientieren, sondern die Möglichkeiten nutzen die OpenGl bietet. Die GUI für ein Spiel muss nicht immer rein praktischer Natur sein (je nach Spiel darf sie das auch garnicht sein, man denke an Spiele die die GUI direkt ins Gameplay integrieren), hier kann man ruhig mal etwas verspieltes machen.

===Nachrichtenbehandlung (aka ''Messagehandling'')===
In diesem Punkt darf man sich ruhig ein wenig an Windows orientieren, allerdings nicht zu sehr, eine Nachrichtenbehandlung für die eigene GUI muss selten so komplex sein wie eines Betriebssystems. Denn die eigene GUI muss nur auf die Ereignisse einer einzelnen Anwendung reagieren, und nicht auf dutzende geöffnete Anwendungen verteilen. Daher ist diese recht einfach zu implementieren. Im Normalfall sollte es reichen wenn eine Nachricht an alle offenen Fenster weitergereicht wird (in Projekt "W" geschieht dies über einen Callback, siehe weiter unten). Wenn also ein Button gedrückt wird, erzeugt dieser eine Nachricht die dann an einen globalen Verteiler (''TGUI.GlobalWindowMessage'') übergeben wird der diese dann an die Fenster weiterleitet. Innerhalb des entsprechenden Callbacks (''TGLWindow.MessageCallBack'') wird dann überpfüft ob die Nachricht für dieses Fenster vorgesehen ist und wenn ja, wird diese auch hier verarbeitet. Klingt sehr einfach und ist es auch. Mehr wird man aber selten benötigen.

===Callbacks verwenden===
Besonders Anfänger haben gerne mal Probleme mit sog. ''Callbacks'', aber wer etwas fortgeschritten ist lernt diese zu schätzen, tragen sie doch stark zur Flexibilität einer Programmiersprache bei und erlauben es z.B. Zirkelbezüge (zwei Units die gegenseitig auf sich zugreifen wollen) zu umschiffen. Für größere Projekte also fast unumgänglich, und in einer GUI für ein Spiel quasi ein Muss. Warum? Weil man nur so die benötigte (optische) Flexibiliät bekommt die man benötigt, denn nicht immer reicht es wenn man z.B. eine Iconbox (in meinem Falle ein Objekt ähnlich einer Listbox, nur mit Texturen statt Einträgen) einfach alle Texturen rendern lässt. In bestimmten Fällen will man evtl. noch zusätzliche Informationen anzeigen. Ein gutes Beispiel ist die Liste der Spione auf dem Screenshot am Anfang des Artikels. Dahinter steckt eine ''TGLIconBox'' die normalerweise nur die Personalbilder darstellen würde. Dank eines Callbacks der (wenn zugewiesen) bei jedem Rendern eines solchen Bildes aufgerufen wird kann man aber bequem mehr Informationen rendern (Erfahrung, Zusatzsymbole, Name). Ohne Callbacks wäre das kaum, bzw. nur über Umwege machbar. Aber nicht nur für optische Anpassungen sollten Callback verwendet werden, sondern auch um auf Ereignisse zu reagieren. In Projekt "W" hat jedes Fenster einen festen Satz von Callbacks :
<pascal> TGLWindow = class
...
BeforeItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen bevor GUI Elemente gezeichnet werden
AfterItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen nachdem alle GUI Elemente gezeichnet wurden
MessageCallBack : TGLWindowGUIMessageCallBack; // Verarbeitet Nachrichten (also z.B. die Nachricht die von einem gedrückten Button gesendet wird)
UpdateCallBack : TGLWindowUpdateCallBack; // Wird aufgerufen wenn der Inhalt des Fensters aktualisiert werden soll, i.d.R. durch einen globalen Aufruf (''TGLGUI.GlobalWindowUpdate'')
...
end;
</pascal>

===Gruppensichtbarkeit===
In einer komplexen GUI wird man irgendwann bestimmte Objekte ein- bzw. ausblenden müssen. Ein Beispiel aus Projekt "W" : Im Spionageschirm können Spion unterschiedlichen Typs angezeigt werden, und je nach gewähltem Spiontyp müssen z.B. diverse Panels und Labels gezeigt oder auch verstekct werden. In der GUI von Projekt "W" hat daher jedes GUI-Element eine Eigenschaft namens ''GroupID'' über dass die Elemente bestimmten Sichtbarkeitsgruppen zugeordnet werden. Die GUI bietet dann eine Funktion namens ''ToggleVisibility'' mit der man ganze Gruppen ein- und ausblenden kann. Leicht zu implementieren und äusserst praktisch.

==Der GUI-Editor==
Eine komplexe GUI benötigt wie bereits angesprochen einen entsprechenden Editor mit dem man seine Fenster erstellen kann, und da ich im Forum bereits mehrfach darauf angesprochen wurde werde ich anhand des Editors von Projekt "W" aufzeigen wie ich einen GUI-Editor aufgebaut habe. Natürlich ist dieser auch auf meine GUI angepasst (deshalb auch keine Veröffentlichung), aber sicherlich findet hier jeder den ein oder anderen Punkt den er auch gerne in seinem eigenen Editor sehen würde.

[[Bild:wiki_gui_editor.jpg]]

===Echtzeitvorschau===
Die vermutlich wichtigste Komponente des Editors. Sie stellt das aktuelle geladene Fenster bzw. die GUI so dar wie man es im Spiel sieht. Bei Bedarf werden natürlich noch ein paar Dinge eingeblendet, wie z.B. Debuglinien oder Auswahlrahmen. Für den Editor muss man hier noch auf Klicks reagieren um Objekte auszuwählen, diese Funktionalität sollte man aber direkt in der GUI verankern.

===Eigenschaftseditor===
Natürlich muss man die Eigenschaften der gewählten GUI-Elemente irgendwie verändern können. Ähnlich wie in Delphi bietet sich hier ein ''TValueListEditor'' an, der sehr flexibel ist. Neben einfachen Werteingaben kann man hier auch Dropdownlisten für vorgegebene Werte, oder sogar Buttons einfügen die dann einen externen Editor (z.B. für die Punkte einer Region oder den Text eines Memos) aufrufen lässt.
Neben dem Eigenschaftseditor für GUI-Elemente benötigt man natürlich auch einen für das aktuelle Fenster. Hier kann man dann Fenstertitel, Größe und ein paar andere Kleinigkeiten anpassen.

===Möglichkeit direkt neue GUI-Elemente zu erstellen===
Hier gibts nicht viel zu erzählen. Ein GUI-Editor wäre natürlich kaum nützlich wenn man keine neuen GUI-Elemente hinzufügen könnte. Wie man das präsentiert ist dem persönlichen Geschmack überlassen. Mir reicht eine einfache Liste mit allen verfügbaren GUI-Elemente, schöner wären natürlich Icons wie in Delphi. Die Implementation ist hier auch recht einfach, denn die GUI an sich sollte bereits eine Möglichkeit bieten einem Fenster neue Elemente hinzuzufügen (z.B. ''TGLWindow.AddButton(...)''). Dann wird im Editor letztendlich nur (je nach ausgewählten Element) die entsprechende Funktion aus der GUI aufgerufen.

===Umschalten zwischen Editor- und Ingame-GUI===
Eher von praktischem Nutzen ist die Möglichkeit zwischen Editor und der Ingame-GUI umzuschalten. So kann man im Editor schnell sehen wie die GUI im Spiel letztendlich aussieht und reagiert. Denn während im Editormodus i.d.R. alle Elemente angezeigt werden gibt es im Ingame-Modus z.B. graphische Buttons die nur beim Mouseover angezeigt werden sollen.

===Gruppensichtbarkeit===
Die entsprechende Funktionalität ist ja bereits in der GUI selbst vorhanden, und da man im Editor durchaus mehrere Objekte direkt an der selben Stelle liegen hat (siehe Beispiel mit den verschiedenen Spiontypen) ist eine Möglichkeit die Gruppensichtbarkeit einzustellen sehr praktisch. Hierzu iteriert man am besten durch alle GUI-Elemente des Fensters und packt alle Gruppen in eine ''TCheckListBox''. Dort kann man dann per Haken wählen welche Gruppen gerade sichtbar sein sollen. Am besten sollte man direkt in der GUI einen Zeiger auf diese ''TGLCheckListBox'' unterbringen, und beim Rendern in einem Fenster prüft man auf den Editiermodus (Flag in der GUI-Unit) und checkt dann gegen diese Liste welche GUI-Elemente gerendert werden sollen.

GUI Leitfaden

2009-03-09T12:42:47Z

Sascha Willems: /* Gedanken zur GUI */

{{Offline}}

''Nach Anregung im Forum entsteht hier ein Artikel zum Thema GUI plus Editor für Spiele. KEIN Tutorial, es wird also weder Code geben noch wird es eine direkte Anleitung. Mehr eine Gedankensammlung und ein Leitfaden aus Erfahrungen mit meiner eigenen GUI.''
--[[Benutzer:Sascha Willems|Sascha Willems]] 12:33, 8. Mär. 2009 (UTC)

==Einleitung==
Wer ein etwas komplexeres Spiel mit einer 3D-API entwickelt wird früher oder später an dem Punkt angelangt sein, an dem er eine graphische Benutzeroberfläche (engl. "GUI" - Graphical user interface) benötigt um dem Spieler wichtige Daten zu präsentieren, und um diesen mit dem Spiel interagieren zu lassen. Mit steigender Spielkomplexität wird eine gute GUI immer wichtiger, denn während z.B. ein Jump'n'Run (Beispiele wären hier Sonic, Mario) nur wenige GUI-Elemente benötigt (Punkte, Leben, Lebensenergie) die zudem meist nur als Anzeigen dienen (also keine Nutzerinteraktion erwarten), benötigen komplexe Spiele wie z.B. Strategiespiele komplexe Nutzeroberflächen um alle wichtigen Daten in ansprechender Form präsentieren zu können, und v.a. um den Spieler auch mit dem Spiel interagieren lassen zu können.

In diesem Artikel (es handelt sich hier nicht um ein Tutorial per se) werde ich mein Erfahrungen, die ich während der Entwicklung einer GUI für [http://www.saschawillems.de/?page_id=114 Projekt "W"] gesammelt habe (und immernoch tue, das Projekt wird ja weiterentwickelt), zusammenfassen und so versuchen eine Leitfaden für die Erstellung einer komplexen Spiele-GUI zu geben. Der Artikel soll nicht als Anleitung gesehen werden, sondern wie gesagt als Leitfaden an dem man sich bei der Erstellung der eigenen GUI orientieren kann, nicht soll. Er soll v.a. zeigen welche Dinge es bei der Erstellung einer solchen GUI zu beachten gibt.

==Warum eine eigene GUI?==
Zum einen weil OpenGL keine eigene GUI-Bibliothek bietet, und zum anderen weil man für ein Spiel das eine 3D-API nutzt letztendlich nicht die Standard UI-Elemente des Betriebssystems nutzen kann. Diese sehen nicht nur langweilig aus, sondern deren Aussehen kann auch nur sehr rudimentär angepasst werden. Ausserdem ist nicht garantiert dass diese auch über dem Renderkontext gezeichnet werden. Fertige OpenGL GUI-Bibliotheken gibts es zudem auch kaum, und für Delphi/Pascal (momentan, siehe [[DGLGUI_Pflichtenheft|DGLGUI]]) erst recht nicht.

Zudem trägt die Benutzeroberfläche viel zum ''"Look and Feel"'' eines Spiels bei, weshalb man hier je nach Komplexität letztendlich sowieso eine eigene Lösung entwickeln muss.

[[Bild:wiki_gui_ingame.jpg]]

(Finale GUI aus Projekt "W" - "Phase 2")

==Gedanken zur GUI==
''Hinweis : ''Dieser Abschnitt ist stark von meinem persönlichen Programmierstil gekennzeichnet. Riesige UML-Diagramme oder umfangreiche Planung ist nicht mein Stil, ich programmiere gerne "on-the-fly".

===Objektorientiert entwickeln===

Eigentlich ein "überflüssiger" Punkt, da selbstverständlich. Bei kaum einem anderen Projekt lässt sich OOP so schön und effektiv anwenden wie bei einer GUI. Es sollte ein Basisobjekt geben ('''TGLGUIItem''') welches alle grundlegenden Eigenschaften (''Größe, Position, evtl. auch weiterführende Dinge wie Schriftart'') und Funktionen (''Speichern und Laden, Zeichnen, dort wo nötig mit '''virtual''' arbeiten'') besitzt die siche alle GUI-Element teilen. Hier sollte man aber nicht immer den kleinsten gemeinsamen Nenner suchen, also auch ruhig die ein oder andere Eigenschaft bzw. Funktion ins Grundelement verlegen die nur von zwei oder drei abgeleiteten Elementen genutzt wird. Das kostet zwar ein wenig mehr Speicher, spart aber viel Arbeit.
Zusätzlich zu den Elementen der GUI gibt es dann als Grundelement noch das Fenster '''TGLWindow''') welches letzendlich ein Kontainer für eben diese Objekt ist und ein paar zusätzliche Funktionen zur Nutzerinteraktion bereitstellt.

===Nicht zu sehr an der Windows-UI orientieren===
Auch wenn es naheliegend wäre die eigene GUI an der UI von Windows (oder Linux) zu orientieren sollte man davon Abstand halten. Während die Benutzeroberfläche von Windows für Anwendungen (dazu noch mehrere gleichzeitig) ausgelegt ist, soll die eigene GUI ja auch zum "Look-and-Feel" des Spiels beitragen und auch einfach zu nutzen sein. Die Windows UI ist sehr abstrakt gehalten, da es für sie keinen direkt definierten Einsatzbereich gibt, ist also entsprechend komplex. Bei der GUI für das eigene Spiel (die dann wenn überhaupt nur in weiteren eigenen Spielen genutzt wird) muss man nichtg krampfhaft versuchen diese Funktionalität nachzubauen. Das kostet viel Zeit und Arbeit die man besser in andere Bereiche investiert (Gameplay, Grafik).
Zudem wird man je nach Spiel auch GUI-Elemente benötigen die es so nicht in Windows gibt. In Projekt "W" gibt es z.B. ein Element namens ''TGLSkinnedControl'' welches neben einer Hintergrundtextur Unterelemente besitzt die auf einer polygonalen Auswahlkontur basieren. So hat man ein GUI-Element das quasi jede Form annehmen kann und für grafisch aufwendige GUI-Elemente genutzt werden kann die keiner Standardform entsprechend. Man könnte ein solches Element von der Funktionalität her natürlich auch mit normalen GUI-Elementen (z.B. Buttons) nachbilden, rein optisch wäre dass dann aber weniger schön und würde den "Look-and-Feel" des Spiels stark stören.

===Die GUI parallel zum Spiel entwickeln===
Dieser Punkt ergänzt quasi den oberen Punkt. Wer von Anfang an eine GUI plant die alle möglichen Elemente beinhaltet und alles möglich kann macht sich unnötig viel Arbeit. GUI-Elemente sollte man dann implementieren wenn man diese benötigt, die GUI also nur erweitern wenn dies für das Spiel benötigt wird. Man implementiert zuerst also nur einen Grundstock von Elementen die definitiv benötigt werden, z.B. Fenster, Buttons, Panels, Memos, Listboxen und erweitert dann nach und nach. Da man ja ein Grundelement hat ('''TGLGUIItem''') ist es relativ einfach die GUI um neue Elemente zu erweitern. Das ist letztendlich weitaus effizienter als von Anfang an alle möglichen GUI-Elemente zu implementieren die man dann letztendlich nicht benötigt.

===Keine Unterscheidung zwischen Fenster und GUI===
In einer frühen Version der GUI für Projekt "W" wurde noch zwischen einer Vollbild-GUI (z.B. Hauptmenü, Spielendeschirm) und den normalen Fenstern unterschieden. So etwas soltle man nicht machen, und in der aktuellen Version der GUI für PjW nutzen auch Vollbild-GUI Schirme ein Fenster als Grundlage. Allerdings ist dieses Fenster nicht bewegbar, nicht sichtbar und immer so groß wie der Viewport des Spiels. Dadurch spart man sich viel Arbeit, da man ansonsten vieles doppelt implementieren muss. Also von Anfang an gleich alles auf Fensterbasis entwickeln.

===Ein erweiterbares Format verwenden===
Wie im vorgen Punkt erwähnt wächst die GUI mit dem Spiel, und selbst wenn man abstrakt entwickelt und von Anfang an alles implementiert wird man irgendwann an einen Punkt kommen an dem man die GUI erweitern muss, sei es um neue Elemente, oder einfach nur eine neue Eigenschaft für ein bestehendes Element. Spätestens dann wird es sich auszahlen wenn man ein erweiterbares Format gewählt hat, denn während eigene binäre Format nur schwer zu erweitern sind lassen sich mit einem Format wie XML (für das es in Delphi direkten Support gibt) leicht Veränderungen an der GUI realisieren. Statt sein eigenes Format erweitern zu müssen kann man in XML einfach einen neuen Attribut an einen bestehenden Knoten anhängen oder einfach neue Knoten hinzufügen. Zusätzlich ist XML (wenn man ordentlich Attribut- und Knotennamen vergibt) auch noch vom Menschen lesbar, man kann dort also schnell Fehler finden bzw. es sogar selbst von Hand erweitern.

===Unterstützung für mehrere Sprachen===
Hier sind natürlich nicht Programmiersprachen gemeint, sondern gesprochene Sprachen. Auch wenn man sein Projekt erstmal nur in einer Sprache veröffentlichen will sollte man trotzdem Unterstützung für mehrere Sprachen von Anfang ein einplanen. So etwas direkt einzubinden ist kaum Aufwand, dies später nachzurüsten kann aber durchaus in Arbeit ausarten. Einfachste Methode (die ich auch in Projekt "W" verwende) ist es für alle benötigten Elemente (z.B. die Beschriftung eines Labels oder Buttons) statt eines Strings ein ''String array'' zu verwenden (eine ''TStringList'' wäre hier zu aufwendig). Wenn man dann auch noch ein erweiterbares Dateiformat wie XML verwendet, ist es mit dieser einfachen Methode kein Problem später weitere Sprachen hinzuzufügen. Zur Ausgabe von Text o.ä. greift man dann nicht mehr direkt auf die Variable zu, sondern nutzt eine Funktion (z.B. ''TGLLabel.GetCaption'') die dann je nach eingestellter Sprache (in Projekt "W" wird die eingestellte Sprache in einer Eigenschaft von ''TLocalizationDB'' gespeichert, einer Klasse die sich um das Laden und wechseln der Sprachen kümmert) die passende Beschriftung zurückgibt.

===Von Anfang an einen GUI-Editor mitentwickeln===
Auch wenn man anfänglich noch das ein oder andere Fenster seiner GUI von Hand erstellen kann (dank XML kein Problem), so sollte man doch direkt mit der Entwicklung eines GUI-Editors beginnen. Spätestens wenn man komplexere Fenster erstellen will übersteigt der Zeitaufwand fürs manuelle Erstellen direkt in XML den Zeitaufwand für die Entwicklung eines GUI-Editors. Also am besten gleichzeitig mit der GUI auch den passenden Editor entwickeln.
Hilfreich wäre es zudem wenn direkt in der GUI einige Flags für den Editormodus implementiert werden. Rein optisch wird es zwischen der Darstellung der GUI im Editor und Spiel bis auf Sichtbarkeit einiger Elemente keine Unterschiede geben, aber z.B. bei der Auswahl von Elementen sieht es im Editormodus anders aus als im Spielmodus, und während man im Spiel oft Elemente komplett ausblendet sollten diese im Editor zumindest via Knopfdruck sichtbar zu machen sein.

===Optische Anpassbarkeit und Flexibilität===
In diesem Punkt wird sich die eigene GUI i.d.R. sehr stark von der des Betriebssystems abheben. Zwar bietet z.B. Windows inzwischen Unterstützung für Themes, diese gelten aber global und sind nicht wirklich flexibel. Da die eigene GUI aber oft selbst innerhalb eines einzigen Spiels optisch anpassbar sein sollte (wird sie in mehreren Spielen verwendet ist dies natürlich mandatorisch), muss entsprechende Funktionalität direkt in ihr verankert werden. Grundlegend sind hier sog. ''"Skins"''. Ein ''"Skin"'' (einen passenden deutschen Begriff gibt es hierfür leider nicht) ist im Prinzip eine Textur die alle graphischen Teile der GUI beinhaltet (Fensterrahmen, Buttonteile, Pfeile, etc.) die dann später mittels Texturemapping aus dieser Datei gesampelt werden. Da die eigenen GUI-Elemente in Einzelteilen gerendert werden müssen die entsprechenden Teile nicht 1:1 in der Textur abgelegt werden, sondern werden dann entsprechend beim Rendern des Elements mehrfach oder gestreckt aus dieser Textur gerendert.

[[Bild:wiki_gui_skin.jpg]][[Bild:wiki_gui_skinnedcontrol.jpg]]

Ausserdem sollte die GUI nicht komplett statisch sein, sprich ein Button sollte beginnen sich optisch abzuheben wenn man den Cursor darauf positioniert. Dank OpenGL sollte dies kein Problem sein und hier sind vielfältige Effekte denkbar. In Projekt "W" z.B. ändern sich Buttons beim Mouseover (im "Skin" gibt es für Buttons je einen normalen Teil und einen hervorgehobene), Teile einer TGLSkinnedControl hingegen werden weich eingeblendet und vergrößert und vice versa. Hier sind also kaum Grenzen gesetzt, man könnte dies sogar mit einem [[Partikelsystem]] verbinden dass z.B. Funken sprühen lässt wenn man einen Button selektiert, oder gar Flammen um diesen herum erscheinen lässt. Animationen sind natürlich auch denkbar. Auch hier sollte man sich keinesfalls an Windows orientieren, sondern die Möglichkeiten nutzen die OpenGl bietet. Die GUI für ein Spiel muss nicht immer rein praktischer Natur sein (je nach Spiel darf sie das auch garnicht sein, man denke an Spiele die die GUI direkt ins Gameplay integrieren), hier kann man ruhig mal etwas verspieltes machen.

===Nachrichtenbehandlung (aka ''Messagehandling'')===
In diesem Punkt darf man sich ruhig ein wenig an Windows orientieren, allerdings nicht zu sehr, eine Nachrichtenbehandlung für die eigene GUI muss selten so komplex sein wie eines Betriebssystems. Denn die eigene GUI muss nur auf die Ereignisse einer einzelnen Anwendung reagieren, und nicht auf dutzende geöffnete Anwendungen verteilen. Daher ist diese recht einfach zu implementieren. Im Normalfall sollte es reichen wenn eine Nachricht an alle offenen Fenster weitergereicht wird (in Projekt "W" geschieht dies über einen Callback, siehe weiter unten). Wenn also ein Button gedrückt wird, erzeugt dieser eine Nachricht die dann an einen globalen Verteiler (''TGUI.GlobalWindowMessage'') übergeben wird der diese dann an die Fenster weiterleitet. Innerhalb des entsprechenden Callbacks (''TGLWindow.MessageCallBack'') wird dann überpfüft ob die Nachricht für dieses Fenster vorgesehen ist und wenn ja, wird diese auch hier verarbeitet. Klingt sehr einfach und ist es auch. Mehr wird man aber selten benötigen.

===Callbacks verwenden===
Besonders Anfänger haben gerne mal Probleme mit sog. ''Callbacks'', aber wer etwas fortgeschritten ist lernt diese zu schätzen, tragen sie doch stark zur Flexibilität einer Programmiersprache bei und erlauben es z.B. Zirkelbezüge (zwei Units die gegenseitig auf sich zugreifen wollen) zu umschiffen. Für größere Projekte also fast unumgänglich, und in einer GUI für ein Spiel quasi ein Muss. Warum? Weil man nur so die benötigte (optische) Flexibiliät bekommt die man benötigt, denn nicht immer reicht es wenn man z.B. eine Iconbox (in meinem Falle ein Objekt ähnlich einer Listbox, nur mit Texturen statt Einträgen) einfach alle Texturen rendern lässt. In bestimmten Fällen will man evtl. noch zusätzliche Informationen anzeigen. Ein gutes Beispiel ist die Liste der Spione auf dem Screenshot am Anfang des Artikels. Dahinter steckt eine ''TGLIconBox'' die normalerweise nur die Personalbilder darstellen würde. Dank eines Callbacks der (wenn zugewiesen) bei jedem Rendern eines solchen Bildes aufgerufen wird kann man aber bequem mehr Informationen rendern (Erfahrung, Zusatzsymbole, Name). Ohne Callbacks wäre das kaum, bzw. nur über Umwege machbar. Aber nicht nur für optische Anpassungen sollten Callback verwendet werden, sondern auch um auf Ereignisse zu reagieren. In Projekt "W" hat jedes Fenster einen festen Satz von Callbacks :
<pascal> TGLWindow = class
...
BeforeItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen bevor GUI Elemente gezeichnet werden
AfterItemDrawCallBack : TGLWindowContentCallBack; // Wird aufgerufen nachdem alle GUI Elemente gezeichnet wurden
MessageCallBack : TGLWindowGUIMessageCallBack; // Verarbeitet Nachrichten (also z.B. die Nachricht die von einem gedrückten Button gesendet wird)
UpdateCallBack : TGLWindowUpdateCallBack; // Wird aufgerufen wenn der Inhalt des Fensters aktualisiert werden soll, i.d.R. durch einen globalen Aufruf (''TGLGUI.GlobalWindowUpdate'')
...
end;
</pascal>

==Der GUI-Editor==
Eine komplexe GUI benötigt wie bereits angesprochen einen entsprechenden Editor mit dem man seine Fenster erstellen kann, und da ich im Forum bereits mehrfach darauf angesprochen wurde werde ich anhand des Editors von Projekt "W" aufzeigen wie ich einen GUI-Editor aufgebaut habe. Natürlich ist dieser auch auf meine GUI angepasst (deshalb auch keine Veröffentlichung), aber sicherlich findet hier jeder den ein oder anderen Punkt den er auch gerne in seinem eigenen Editor sehen würde.

[[Bild:wiki_gui_editor.jpg]]

===Echtzeitvorschau===
Die vermutlich wichtigste Komponente des Editors. Sie stellt das aktuelle geladene Fenster bzw. die GUI so dar wie man es im Spiel sieht. Bei Bedarf werden natürlich noch ein paar Dinge eingeblendet, wie z.B. Debuglinien oder Auswahlrahmen.

GUI Leitfaden

2009-03-08T16:01:59Z

Sascha Willems:

GUI Leitfaden

2009-03-08T15:48:32Z

Sascha Willems: /* Gedanken zur GUI */

GUI Leitfaden

2009-03-08T15:48:09Z

Sascha Willems: /* Von Anfang an einen GUI-Editor mitentwickeln */

GUI Leitfaden

2009-03-08T15:41:41Z

Sascha Willems:

Datei:wiki gui skinnedcontrol.jpg

2009-03-08T15:33:14Z

Datei:wiki gui skin.jpg

2009-03-08T15:25:54Z

Datei:wiki gui editor.jpg

2009-03-08T15:00:38Z

GUI Leitfaden

2009-03-08T14:59:50Z

Sascha Willems: /* Warum eine eigene GUI? */

{{Offline}}

''Nach Anregung im Forum entsteht hier ein Artikel zum Them GUI plus Editor für Spiele. KEIN Tutorial, es wird also weder Code geben noch wird es eine direkte Anleitung. Mehr eine Gedankensammlung und ein Leitfaden aus Erfahrungen mit meiner eigenen GUI.''
--[[Benutzer:Sascha Willems|Sascha Willems]] 12:33, 8. Mär. 2009 (UTC)

==Einleitung==
Wer ein etwas komplexeres Spiel mit einer 3D-API entwickelt wird früher oder später an dem Punkt angelangt sein, an dem er eine graphische Benutzeroberfläche (engl. "GUI" - Graphical user interface) benötigt um dem Spieler wichtige Daten zu präsentieren, und um diesen mit dem Spiel interagieren zu lassen. Mit steigender Spielkomplexität wird eine gute GUI immer wichtiger, denn während z.B. ein Jump'n'Run (Beispiele wären hier Sonic, Mario) nur wenige GUI-Elemente benötigt (Punkte, Leben, Lebensenergie) die zudem meist nur als Anzeigen dienen (also keine Nutzerinteraktion erwarten), benötigen komplexe Spiele wie z.B. Strategiespiele komplexe Nutzeroberflächen um alle wichtigen Daten in ansprechender Form präsentieren zu können, und v.a. um den Spieler auch mit dem Spiel interagieren lassen zu können.

In diesem Artikel (es handelt sich hier nicht um ein Tutorial per se) werde ich mein Erfahrungen, die ich während der Entwicklung einer GUI für [http://www.saschawillems.de/?page_id=114 Projekt "W"] gesammelt habe (und immernoch tue, das Projekt wird ja weiterentwickelt), zusammenfassen und so versuchen eine Leitfaden für die Erstellung einer komplexen Spiele-GUI zu geben. Der Artikel soll nicht als Anleitung gesehen werden, sondern wie gesagt als Leitfaden an dem man sich bei der Erstellung der eigenen GUI orientieren kann, nicht soll. Er soll v.a. zeigen welche Dinge es bei der Erstellung einer solchen GUI zu beachten gibt.

==Warum eine eigene GUI?==
Zum einen weil OpenGL keine eigene GUI-Bibliothek bietet, und zum anderen weil man für ein Spiel das eine 3D-API nutzt letztendlich nicht die Standard UI-Elemente des Betriebssystems nutzen kann. Diese sehen nicht nur langweilig aus, sondern deren Aussehen kann auch nur sehr rudimentär angepasst werden. Ausserdem ist nicht garantiert dass diese auch über dem Renderkontext gezeichnet werden. Fertige OpenGL GUI-Bibliotheken gibts es zudem auch kaum, und für Delphi/Pascal (momentan, siehe [[DGLGUI_Pflichtenheft|DGLGUI]]) erst recht nicht.

Zudem trägt die Benutzeroberfläche viel zum ''"Look and Feel"'' eines Spiels bei, weshalb man hier je nach Komplexität letztendlich sowieso eine eigene Lösung entwickeln muss.

[[Bild:wiki_gui_ingame.jpg]]

(Finale GUI aus Projekt "W" - "Phase 2")

==Gedanken zur GUI==
''Hinweis : ''Dieser Abschnitt ist stark von meinem persönlichen Programmierstil gekennzeichnet. Riesige UML-Diagramme oder umfangreiche Planung ist nicht mein Stil, ich programmiere gerne "on-the-fly".

===Objektorientiert entwickeln===

Eigentlich ein "überflüssiger" Punkt, da selbstverständlich. Bei kaum einem anderen Projekt lässt sich OOP so schön und effektiv anwenden wie bei einer GUI. Es sollte ein Basisobjekt geben ('''TGLGUIItem''') welches alle grundlegenden Eigenschaften (''Größe, Position, evtl. auch weiterführende Dinge wie Schriftart'') und Funktionen (''Speichern und Laden, Zeichnen, dort wo nötig mit '''virtual''' arbeiten'') besitzt die siche alle GUI-Element teilen. Hier sollte man aber nicht immer den kleinsten gemeinsamen Nenner suchen, also auch ruhig die ein oder andere Eigenschaft bzw. Funktion ins Grundelement verlegen die nur von zwei oder drei abgeleiteten Elementen genutzt wird. Das kostet zwar ein wenig mehr Speicher, spart aber viel Arbeit.
Zusätzlich zu den Elementen der GUI gibt es dann als Grundelement noch das Fenster '''TGLWindow''') welches letzendlich ein Kontainer für eben diese Objekt ist und ein paar zusätzliche Funktionen zur Nutzerinteraktion bereitstellt.

===Nicht zu sehr an der Windows-UI orientieren===
Auch wenn es naheliegend wäre die eigene GUI an der UI von Windows (oder Linux) zu orientieren sollte man davon Abstand halten. Während die Benutzeroberfläche von Windows für Anwendungen (dazu noch mehrere gleichzeitig) ausgelegt ist, soll die eigene GUI ja auch zum "Look-and-Feel" des Spiels beitragen und auch einfach zu nutzen sein. Die Windows UI ist sehr abstrakt gehalten, da es für sie keinen direkt definierten Einsatzbereich gibt, ist also entsprechend komplex. Bei der GUI für das eigene Spiel (die dann wenn überhaupt nur in weiteren eigenen Spielen genutzt wird) muss man nichtg krampfhaft versuchen diese Funktionalität nachzubauen. Das kostet viel Zeit und Arbeit die man besser in andere Bereiche investiert (Gameplay, Grafik).
Zudem wird man je nach Spiel auch GUI-Elemente benötigen die es so nicht in Windows gibt. In Projekt "W" gibt es z.B. ein Element namens ''TGLSkinnedControl'' welches neben einer Hintergrundtextur Unterelemente besitzt die auf einer polygonalen Auswahlkontur basieren. So hat man ein GUI-Element das quasi jede Form annehmen kann und für grafisch aufwendige GUI-Elemente genutzt werden kann die keiner Standardform entsprechend. Man könnte ein solches Element von der Funktionalität her natürlich auch mit normalen GUI-Elementen (z.B. Buttons) nachbilden, rein optisch wäre dass dann aber weniger schön und würde den "Look-and-Feel" des Spiels stark stören.

===Die GUI parallel zum Spiel entwickeln===
Dieser Punkt ergänzt quasi den oberen Punkt. Wer von Anfang an eine GUI plant die alle möglichen Elemente beinhaltet und alles möglich kann macht sich unnötig viel Arbeit. GUI-Elemente sollte man dann implementieren wenn man diese benötigt, die GUI also nur erweitern wenn dies für das Spiel benötigt wird. Man implementiert zuerst also nur einen Grundstock von Elementen die definitiv benötigt werden, z.B. Fenster, Buttons, Panels, Memos, Listboxen und erweitert dann nach und nach. Da man ja ein Grundelement hat ('''TGLGUIItem''') ist es relativ einfach die GUI um neue Elemente zu erweitern. Das ist letztendlich weitaus effizienter als von Anfang an alle möglichen GUI-Elemente zu implementieren die man dann letztendlich nicht benötigt.

===Ein erweiterbares Format verwenden===
Wie im vorgen Punkt erwähnt wächst die GUI mit dem Spiel, und selbst wenn man abstrakt entwickelt und von Anfang an alles implementiert wird man irgendwann an einen Punkt kommen an dem man die GUI erweitern muss, sei es um neue Elemente, oder einfach nur eine neue Eigenschaft für ein bestehendes Element. Spätestens dann wird es sich auszahlen wenn man ein erweiterbares Format gewählt hat, denn während eigene binäre Format nur schwer zu erweitern sind lassen sich mit einem Format wie XML (für das es in Delphi direkten Support gibt) leicht Veränderungen an der GUI realisieren. Statt sein eigenes Format erweitern zu müssen kann man in XML einfach einen neuen Attribut an einen bestehenden Knoten anhängen oder einfach neue Knoten hinzufügen. Zusätzlich ist XML (wenn man ordentlich Attribut- und Knotennamen vergibt) auch noch vom Menschen lesbar, man kann dort also schnell Fehler finden bzw. es sogar selbst von Hand erweitern.

===Von Anfang an einen GUI-Editor mitentwickeln===
Auch wenn man anfänglich noch das ein oder andere Fenster seiner GUI von Hand erstellen kann (dank XML kein Problem), so sollte man doch direkt mit der Entwicklung eines GUI-Editors beginnen. Spätestens wenn man komplexere Fenster erstellen will übersteigt der Zeitaufwand fürs manuelle Erstellen direkt in XML den Zeitaufwand für die Entwicklung eines GUI-Editors. Also am besten gleichzeitig mit der GUI auch den passenden Editor entwickeln.

GUI Leitfaden

Benutzer:Sascha Willems

2008-05-16T13:37:06Z

Sascha Willems:

[http://www.saschawillems.de Meine Homepage]<br>
OpenGL Demos und Tutorials, meine Projekte, und mehr.
----

''Ich bin der Geist, der stets verneint! Und das mit Recht; denn alles, was entsteht, ist wert, daß es zugrunde geht. Drum besser wär's, wenn nichts entstünde. So ist denn alles, was ihr Sünde, Zerstörung, kurz, das Böse nennt, mein eigentliches Element'' - [http://de.wikipedia.org/wiki/Mephistopheles Mephisto]

Modelformat

2008-05-15T13:56:14Z

Sascha Willems: Bruteforce durch Immediate (korrektere Bezeichnung ersetzt), Statement zu Displaliste vs. VBO angepasst, siehe u.a. Dokumente von NVidia und ATI

Es gibt einige Arten von Modelformaten: Textbasierende, binäre, sogar grafische (siehe parametrisierte Geometry Maps).
Die Formate sind auf bestimmte Ziele ausgerichtet und dementsprechend auch im Aufbau unterschiedlich.

In diesem Artikel möchte ich ein für OpenGL optimiertes Format vorstellen, welches als weiteres Kriterium eine sehr geringe CPU und Ladezeit in Anspruch nimmt. Also sollten wir uns erstmal die für OpenGL benötigten Daten angucken.

<cpp>typedef Vertex float x,y,z;
typedef Color float r,g,b;
typedef Normal float x,y,z;
typedef Texcoord float u,v;
typedef Index unsigned int i;</cpp>

OpenGL bietet mehrere Möglichkeiten diese Daten darzustellen.
*[[VBO]] (vertex buffer object)
*Immediate (direkter Modus)([[glBegin]]/glEnd)
*[[Vertexarray]]
*[[Displayliste]]
Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. In Sachen Geschwindigkeit sind Displaylisten immer noch die beste Möglichkeit (siehe z.B. [http://ati.amd.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf folgendes Dokument] von ATI für die GDC2006, Seite 14), haben aber in Sachen Flexibilität Nachteile (entweder müssen sie neu erstellt werden, oder im Shader angepasst werden). VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern. Entweder in Form mehrer Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.

Wozu der Index? Der Index zeigt auf einen Wert in der Vertex-, Color-, Normal-, ...-Stream. Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index mehrfach verwenden kann.
<cpp>struct Model
{
Vertex *Verticelist;
Normal *Normallist;
Color *Colorlist;
Texcoord *Texcoordlist;
Index *Indices;
};</cpp>

Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen wir Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexanzahl und ein Material zugewiesen. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
<cpp>struct Face
{
unsigned int Start;
unsigned int Count;
string MaterialName;
};</cpp>
<br>
Der Name ist allerdings ziemlich groß und würde in jeden Face wieder auftreten. Also speichern wir im Format eine Liste von Materialnamen und speichern im Face den Index in der Liste.
<cpp>struct Face
{
unsigned int Start;
unsigned int Count;
unsigned int MaterialIndex;
};

struct Model
{
Vertex *Verticelist;
Normal *Normallist;
Color *Colorlist;
Texcoord *Texcoordlist;
Index *Indices;
string *MaterialList[32]; //feste Strings sind besser zu laden
Face *Facelist;
};</cpp>
<br>
Für das Material File könnte z.B. ein Script oder eine XML Datei erstellt werden, die alle benötigten Texturen, Flags und Shader enthält. Wenn man Shader verwendet, dann könnte man die Tangenten mit dazu packen.

Okay, nun müssen wird die Daten auch noch speichern und das so, dass wir sie möglichst schnell wieder laden können. Hier kann man Serialisierung aufgreifen und die Daten und den Loader entsprechend anpassen. Bei diesem Ansatz wird jede dynamische Variable (arrays/pointer) überarbeitet. Alle Daten, die gleich bleiben, werden 1 zu 1 geschrieben, für die dynamischen Daten wird ein Bereich am Ende des Formates zur Verfügung gestellt und dorthin verschoben. Die Differenz zwischen Position des Pointers/Array und der Stelle der abgelegten Daten nennt man Offset. Dieser wird an der entsprechenden Stelle in die Liste geschrieben.
Ein Beispiel kann das wohl besser beschreiben:

<cpp>//eigentliche Struktur
struct Data
{
unsigned int VerticeCount;
Vertex* Vertice; //Array durch verticecount korrekt nutzbar (Delphi pVertex(Vertice+i)^ oder bei c++/freepascal Vertice[i])
};

//gut speicherbare und ladbare Version
struct SpeicherbareDaten
{
unsigned int VerticeCount;
#if defined(64BIT)//Pointer sind 64bit groß, der Offset liegt vor relocate an der Pointerstelle
Vertex* Vertice;
#else
#if defined(32BIT)//Pointer sind 32bit groß, der offset=pointer und die anderen 4 Byte sind toter speicher
Vertex* Vertice;
unsigned int unused;
#else
Die Bitarchitektur ist nicht vorgesehen.
#endif
#endif
};

void relocate(SpeicherbareDaten* Data)
{
Data->Vertice=(Vertex*)((char*)Data+(unsigned int)Data->Vertice);
}</cpp>
Aktuell hat keine Console oder PC eine größere Speicheradressierung als 64Bit.
Also werden die dynamischen Elemente mit offsets von 4byte und 4byte ungenutzt besetzt. Wir könnten die Daten nun mit einem read Aufruf laden und das relocate korrigiert den offset zu einem Pointer.

Die Probleme der meisten Formate liegen im Aufbau, wenn oft noch geparsed und in mehreren Etappen geladen werden muss (braucht CPU Zeit und verschwendet Zeit beim Festplattenzugriff) und in der unpassenden Datenbeschaffenheit (eventuell konvertieren oder noch schlimmer, Speicherreservierung und konvertieren). Das oben beschriebene Speicher- und Ladesystem braucht nur einen einzigen Read Aufruf und hat danach die Daten komplett im Speicher. Dann noch ein relocate und wir haben die fertigen Daten.
Der Vorteil des relocate ist, dass man lediglich für dynamische Elemente einmal eine Addition ausführt (10 Arrays = 10 Additionen).
Durch die Anpassung an das von OpenGL gewollte Datenformat kann man ganz einfach die Daten in den VRam laden lassen (VBO Streams lassen grüssen) und leitet das Laden des Materials an die entsprechende Stelle weiter.

Meine Umsetzung ist hier zu finden.
*[https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Ftrunk%2Finclude%2Fkar_model.hpp kar_model.hpp]
*[https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Ftrunk%2Fsrc%2Fkar_model.cpp kar_model.cpp]
*[https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Ftrunk%2Fdemos%2Fdata%2Fexporter.py exporter.py(Blender exporter Script)]
Ein weiterer Vorteil ist der Codeumfang, denn dieser ist in meiner Implementierung gerademal 205 Zeilen lang.
Mein Testmodel hatte ~15k Vertice, Normals, Texcoords, ~46k Indices, 15k Faces, 1Material und keine Properties.
Die Dateigröße betrug 1,5MB und wurde in 7ms ungecached (erster Aufruf der Datei) und 3ms gecached(die Datei wurde seit dem Start von Windows schonmal angefasst) geladen, Pointer angepasst, VBOs für alle Daten erstellt und der Ladeprozess für die Textur angestoßen (alles in stolzen 7ms).
Das Laden des ganzen Models mit der einer Textur (512x512 dxt5) hat knapp 20ms gedauert.
[http://karmarama.developer-alliance.org/upload/model.PNG Ein nicht ganz aktuelles Screenshot.]

Bei Fragen, Verbesserungsvorschlägen oder ähnlichem, mich([[Benutzer:TAK2004|TAK2004]]) einfach per PM im Forum ansprechen.

DGL Projekte

2007-09-07T12:41:30Z

Sascha Willems: Projekt "W" hinzugefügt, plus neue Kategorie "Strategie"

=DGL Projects Corner=

<div align="center">
Willkommen in der '''[[DelphiGL|DGL]] Projekte Ecke'''!
[[Bild:ProjekteEcke.jpg|center]]
Auf dieser Seite findet ihr Projekte von '''Mitgliedern von [http://DelphiGL.com DelphiGL.com]''' welche als '''abgeschlossen''' gewertet wurden.
</div>

==Spiele==
Viele, um nicht zu sagen die meisten, DGL-Mitglieder widmen sich dem Thema Spiele. Was dabei an respektablen Ergebnissen entstanden ist könnt ihr in dieser Rubrik sehen.

===3D Shooter und Labyrinth Spiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|''Noch keine Programme''
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!
|''Hier könnte dein Name stehen''
|}

===Action===

{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Thumb_asteroids.jpg|framed|center|Link: '''[[Projekt_Asteroids|Asteroids]]''']]

|Asteroids ist ein Remake des alten Klassikers "Comet". Ziel des Spiels ist es so viel Asteroiden wie möglich zu zerstören um dadurch möglichst viele Punkte zusammeln, ohne dabei von den herum fliegenden Trümmern getroffen zu werden.

An einem Spiel können bis zu 4 Spieler gleichzeitig teilnehmen.

|align="center"|[[Benutzer:Magellan|Magellan]]
|-
|-
|[[Bild:Thumb_napalmbomber.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=90 Napalmbomber3D Projektseite]''']]

|NapalmBomber3D ist wie der Titel schon vermuten lässt ein 3D-Klon des bekannten Bombermanspielprinzips.Dieses hochbrisante und fesselnde Spiel besticht durch seine tolle Grafik die natürlich mittels OpenGL realisiert wurde.

Zusätzlich zum Spiel gibt es natürlich auch noch einen Karteneditor mit dem sich in Windeseile eigenen Maps erstellen lassen.

Neben inzwischen über 50.000 Downloads (im Schnitt sind es immernoch > 400 pro Monat) und diversen sehr guten Reviews hat es das Spiel sogar auf die PC-Action Ausgabe 07/2004 geschafft.

|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]
|-
|}

===Brett-, Denk- und Kartenspiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Projekt_Hex_Change_Screenshot.jpg|thumb|center|168px|Link: '''[[Projekt_Hex-Change|Hex-Change]]''']]
|2 Spieler konkurrieren um die Felder auf einer Hexagon Fläche. Das Spiel enthält einen Einzelspieler- (gegen KI) und einen "Hot-Seat"-Mehrspielermodus.
|align="center"|[[Benutzer:H.A.S.E.|H.A.S.E.]]
|}

===Reaktions- und Geschicklichkeitsspiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Thumb_confusingball.jpg|framed|center|Link: '''[[Projekt_ConfusingBall|Confusing Ball]]''']]

|In "Confusing Ball" steuert man einen Ball durch ein 3D Labyrinth, in dem die Gesetze der Physik neu definiert werden müssen. Um ins Ziel eines Levels zu gelangen benötigt man einen gewissen Orientierungssinn und ein gutes räumliches Vorstellungsvermögen.
Nebenher muss man ja auch noch die Münzen einsammeln, und den Bomben aus dem Weg gehen. Frei verschiebbare Steine erhöhen den Schwierigkeitsgrad.

|align="center"|[[Benutzer:MatReno|MatReno]]
|-
|[[Bild:Thumb_beanmachine.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=86 Bean Machine Projektseite]''']]

|"Bean Machine" basiert auf dem Sega MegaDrive-Klassiker "Dr.Robotnik's Mean Bean Machine" (ausserhalb Europas auch als "Puyo Puyo" bekannt) und spielt sich somit ähnlich wie Tetris.
Auch dieses Klassikerremake spielt sich fast genauso wie die Vorlage, allerdings gibt es dank OpenGL recht aufwendige Grafiken, natürlich gewohnt komplett in 3D.

|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]
|-
|[[Bild:Heiliger Damm.jpg|thumb|center|168px|Link: '''[[Projekt Heiliger_Damm|Heiliger Damm]]''']]

|"Heiliger Damm" ist ein Geschicklichkeitsspiel passend zum G8-Treffen 2007 in Heiligendamm. Der Spieler übernimmt die Aufgabe, den "heiligen Damm" (eine Oase in der Wüste) vor den Globalisierungsgegner zu schützen. Dies erreicht er, indem er mit der Maus Linien (Zäune) zieht.

|align="center"|[[Benutzer:GTA-Place|Fabian Gärtner / GTA-Place]]
|}

===Manager===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:PBM2_Kdr.jpg|thumb|center|168px|Link: '''[[Projekt_PBM2|PBall Manager 2]]''']]

|Der PBall Manager 2 ist ein Sportmanager in welchem man in die Rolle des Trainers/Managers eines von 96 PBall Teams aus ganz Europa schlüpft. PBall selbst ist eine fiktive Sportart welche ähnlich Fußball ist.

Im Spiel hat man die Kontrolle über alle Abläufe: Von der Aufstellung über Spielerkäufe bis hin zum Stadionausbau liegt alles in der Hand des Spielers. Doch auch die eigene Karriere kann voran getrieben werden indem man zu anderen Clubs wechselt.

Das Ziel aller PBaller ist der Liga-Meister-Pokal indem die besten Clubs der 4 Europäischen Ligen um den Titel spielen.

|align="center"|[[Benutzer:Flash|Kevin Fleischer alias Flash]]
|-
|}

===Simulationen===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|''Noch keine Programme''
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!
|''Hier könnte dein Name stehen''
|}

===Strategie===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:projektw_wiki_projektecke.jpg|thumb|center|168px|Link: '''[http://www.saschawillems.de/?page_id=114 Projekt "W"]''']]

|Projekt "W" ist ein runden-basierendes Strategiespiel, dessen Ziel die Erlangung der Weltherrschaft ist. Der Spieler kann sich für eine der fünf neuen großen Nationen entscheiden, und muss diese dann zum Sieg über alle anderen Nationen führen.

Dazu muss man seine Regionen verwalten, dort Gebäude bauen und auf wichtige Faktoren achten. Man baut zudem militärische Einheiten und gliedert diese in Divisionen um damit das eigene Territorium zu verteidigen, bzw. gegnerische Regionen einzunehmen. Zusätzlich kann man Technologien erforschen, die u.A. neue Gebäude und Militäreinheiten freischalten. Auch Spionage und Sabotage spielen eine wichtige Rolle, so kann man z.B. mit Hilfe eines eingeschleusten Spions an wichtige Informationen gelangen oder die Stromversorgung einer Region lahmlegen.

Neben dem Einzelspielermodus, in dem man gegen die KI bestehen muss, gibt es auch einen Hotseatmodus, bei dem mehrere Spieler an einem Rechner gegeneinander antreten können. Präsentiert wirds wie gewohnt in schicker 3D-Grafik, und auf passender Hardware wird das Ganze noch mit Shadern garniert.

|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]
|-
|}

Datei:projektw wiki projektecke.jpg

2007-09-07T12:32:59Z

Sascha Willems: Projekt "W" Vorschaubild für die Projektecke

Projekt "W" Vorschaubild für die Projektecke

Diskussion:Selektion

2007-08-25T18:50:01Z

Sascha Willems: Die Seite wurde neu angelegt: Das Selektionsproblem besteht seit dem Release90 Treiber, und NVidia hat bisher nicht auf Anfragen bzw. Hinweise bezgl. dieser Problematik reagiert. Inzwischen sind wir...

Das Selektionsproblem besteht seit dem Release90 Treiber, und NVidia hat bisher nicht auf Anfragen bzw. Hinweise bezgl. dieser Problematik reagiert. Inzwischen sind wir beim Release160 (aktuell ist 163.44) und dort ist es immernoch enthalten. Anscheinend wird das also nicht mehr "gefixt" (Selektion läuft ja eh in Software), so dass man auf OpenGLs Selektionsfunktionen besser ganz verzichtet.
--[[Benutzer:Sascha Willems|Sascha Willems]] 20:50, 25. Aug. 2007 (CEST)

Tutorial Bomberman2

2007-05-24T22:20:37Z

Sascha Willems: /* Schlusswort */

[[Bild:Bomberman.gif|left]]
=Wir programmieren einen Bombermanklon! <br> <br> Teil 1 : Die Codebasis und der Editor=

==Vorwort==
Ave, und willkommen zum zweiten Tutorial der Bombermanserie!
Nachdem wir uns im ersten Tutorial mit der Programmierung eines Editor und der grundlegenden Codebasis beschäftigt haben, gehts nun ans Eingemachte, nämlich den 3D-Bombermanklon.

Da der Quellcode unseres Klons recht umfangreich ist, und in diesem Tutorial viele neue Techniken behandelt werden, wirds vielleicht etwas langatmig. Aber keine Angst, denn zum einen versuche ich alles recht ausführlich und auch für Neulinge verständlich zu erklären, und zum anderen werdet ihr am Ende dieses Tutorials einen kompletten Bombermanklon programmiert haben der euch (und eure Bekannten) mit stundenlangem Spielspaß belohnt!

Deshalb gibts zum Ansporn erstmal zwei nette Screenshots direkt aus dem Spiel :

<div align="center">[[Bild:Tutorial Bomberman2 nbomber1.jpg]][[Bild:Tutorial Bomberman2 nbomber2.jpg]]</div>

==Voraussetzungen==
Wie schon im ersten Tutorial vorausgesetzt, solltet ihr recht '''gute Kenntnisse in Object Pascal und OpenGL''' mitbringen.
Des Weiteren werde ich in unserem Quellcode starken Gebrauch von '''dynamischen Arrays''' machen, deren Nutzung und Verwaltung besonders für Personen die sich damit noch nicht beschäftigt haben recht verwirrend sein kann. Deshalb sind gute Kenntnisse zum Thema dynamische Arrays unentbehrlich. Aber keine Angst, denn alles was man zu diesem Thema braucht, findet sich in der Delphi-Hilfe.

Neben der programmiertechnischen Seite, erfordert das Erschaffen eines Spiels natürlich auch den Umgang mit diversen Anwendungen. Einige davon sind kleine Tools, die sich mit einem Klick bedienen lassen während andere Programme eine nicht unerheblich Einarbeitungszeit voraussetzen. Die von mir genutzten Anwendungen und Tools im Überblick :

<div align="center">
{|{{Prettytable_B1}}
!colspan="2"|Komerzielle Anwendungen
|-
|[[Bild:Tutorial Bomberman2 app 3dsmax.jpg]]
|'''3D Studio MAX'''
Dieses 3D-Modellierungs und Renderprogramm dürfte wohl jedem ein Begriff sein, ist es doch eines der meistgenutzten Programme in der Spielebranche, und man wird wohl kaum ohne grundlegende Kenntnisse in diesem Programm auskommen.

Wenn man sich erstmal (mittels des sehr gute Handbuches/mitgelieferten Tuts) eingearbeitet hat, dann geht das Erstellen von 3D-Modellen sehr leicht von der Hand. Den Hauptaktor unseres Bombermanklons hab ich in knapp 5 Min. erstellt.

''Alternativen :''<br>
Als Alternative kommen eigentlich alle Programme in Frage, die in der Lage sind in das 3DS-Format zu exportieren, wie z.B. :<br>
Blender, Milksphape3D, Maya
|-
|[[Bild:Tutorial Bomberman2 app photoshop.jpg]]
|'''Adobe Photoshop'''
Zu diesem Bildbearbeitungsprogramm muß ich wohl auch kaum was erzählen. Für alle die es nicht kennen : Das momentan wohl mächtigste Bildbearbeitungsprogramm. Die Einarbeitung ist nicht gerade einfach, doch wenn man sich mit diesem Programm erstmal auskennt, ist das Erstellen von guten Grafiken und Texturen schnell erledigt.

''Alternativen :''<br>
Micrografx Picture Publisher, Gimp, JASC Paintshop Pro
|-
!colspan="2"|Kostenlose Tools
|-
|[[Bild:Tutorial Bomberman2 tools explosion generator.jpg|center]]
|'''Explosion Generator'''
Dieses sehr praktische Tool rendert eine komplette Explosion in eine Textur, so daß man diese als Grundlage für eine Explosionsanimation ins einer Anwendung nutzen kann.
Nachteil der Sache ist, das sich das Erscheinungsbild der Explosion nur manuell über eine Textdatei anpassen lässt.

Link : www.positech.co.uk
|-
|[[Bild:Tutorial Bomberman2 tools bitmapfont builder.jpg]]
|'''Bitmapfont Builder'''
Mit diesem Programm lassen sich in Windeseile die für Bitmapfonts benötigten Fonttexturen auf Basis der in Windows verfügbaren Schriftarten erstellen.

Link : www.lmnopc.com
|-
|}
</div>

Soviel also zu den (von mir) genutzten Anwendungen und Tools. Natürlich steht euch die Wahl frei, und ihr könnt die Tools und Programme eurer Wahl nutzen.

==Ziel==
Wie schon kurz im Vorwort erwähnt, werden wir in diesem Tutorial einen kompletten Bombermanklon programmieren. Ziel dabei ist es, eine saubere Codebasis zu schreiben und euch grundlegende Techniken der Spieleprogrammierung beizubringen.

Außerdem möchte ich euch einen recht sauberen Programmierstil beibringen, der bei vielen missen lässt und Programmcodes für andere oft unnutzbar macht.

Folgendes wird euch im Tutorial erwarten, und euch auch bei zukünftigen Ausflügen in die Welt der Spieleprogrammierung von Nutzen sein :

[[Bild:Tutorial Bomberman2 superbomberman help.gif|left]]
:::::* Timebased Movement (Frameunabhängige Bewegungen)
:::::* Texturenfonts
:::::* Statemachine
:::::* Kollisionsabfrage
:::::* Sound (via [http://www.fmod.de FMOD])

==Projektstruktur==
Widmen wir uns nun kurz der Projektstruktur. Gemeint sind damit die genutzten Units, deren Funktion und Inhalt. Was genau wo gemacht wird, darüber werden wir uns später unterhalten.

Bei eurer Projektstruktur solltet ihr vor allem darauf achten, nicht alles in eine Unit zu packen. Zum einen kann das später nämlich eingige Probleme machen (ich sage nur Kreuzbezüge) und zum anderen schadet es der Portabilität. Damit sind z.B. wiederverwendbare Programmteile wie der Texturenmanager oder das Soundsystem gemeint, die wenn sie in eine externe Unit ausgelagert werden, später ohne großen Aufwand in andere Projekte eingebunden werden können. Dadurch spart man sich über die Zeit sehr viel Arbeit und baut sich nach und nach mit jedem Projekt eine größere Codebasis auf.

Wichtig ist natürlich (wie auch bei euren Variablen) die Namensgebung. Es scheint zwar verlockend, Objekt- oder Unitnamen so kurz wie möglich zu halten (besonders dann wenn man schreibfaul ist), aber das wird sich früher oder später rächen. Wenn man dann nämlich dutzende Units mit kryptischen Namen in denen dutzende Objekte mit noch kryptischeren Namen verteilt sind quer auf der Platte verteilt hat, fällt die Wiederverwendung und Zuordnung recht schwer!

===Projektunits===
Nachfolgend gebe ich einen kurzen Überblick über alle dem Projekt zugehörigen Units und deren Inhalt.

{{Unit|NapalmBomber3D_1.pas}}
:In dieser Unit befindet sich das Hauptformular unseres Bombermanklons. Hier findet neben der Initialisierung einiger wichtiger Variablen und Objekte nichts wirklich Interessantes statt.

{{Unit|BombermanGlobal.pas}}
:Dies ist wie der Name schon vermuten lässt der Sitz unserer Codebasis und somit auch die wichtigste Unit unseres Projektes. Im letzten Tutorial hieß sie noch global.pas, wurde jedoch aufgrund der besseren Übersicht umbenannt.

{{Unit|BombermanTextureManager.pas}}
:Naja, ich glaube es ist ein Einfaches anhand der Namensgebung herauszufinden was sich hinter dieser Unit versteckt. Im letzten Tutorial befand sich unser Texturenmanager noch in der globalen Unit. Allerdings will unser 3DS-Lader diesen Texturenmanager auch nutzen, und um Kreuzbezüge zu vermeiden habe ich ihn deshalb in eine extra Unit ausgelagert.
:Vorteil ist, neben der Tatsache das er nun von mehrern Units genutzt werden kann, auch noch die praktische Tatsache das man diese Unit unverändert für seine anderen Projekte nutzen kann. Also quasi ein Texturenmanager mit Zukunft.

{{Unit|BombermanSoundSystem.pas}}
:Auch hier sollte die Unitfunktion anhand der Namensgebung recht einfach zu erkennen sein. Hier befindet sich das (momentan noch recht einfache) Soundsystem. Vorteil der Auslagerung in eine estra Unit ist auch hier die Portabilität.

{{Unit|BombermanFont.pas}}
:In dieser Unit befindet sich unser Fontsystem zur Ausgabe von Bitmapfonts.Mehr dazu später.

{{Unit|BombermanLoad3DS.pas}}
:Diese Unit bietet einige einfache Methode um 3D-Modelle im 3DS-Format zu laden und in eine unter OpenGL darstellbare DisplayListe zu wandeln.
:Die Unit basiert ursprünglich auf dem 3DS-Loader von [http://www.lischke-online.de Mike Lischke], und wurde von mir vereinfacht. Deshalb wirds hierzu keine genaue Erklärung geben.

===Fremdunits===
Nachdem ich vorher alle dem Projekt zugehörigen Units aufgezählt habe, gibts hier noch einen ganz kurzen Überblick über die Fremdunits, die vom Projekt benötigt werden.

{{Unit|Utils3DS.pas,Const3DS.pas,File3DS.pas,Types3DS.pas}}
:Diese Units werden von unserem 3DS-Lader benötigt und stammen auch aus Mike Lischkes 3DS-Packet.

{{Unit|fmod.pas,fmodtypes.pas,fmoddyn.pas,fmoderros.pas,fmodpresets.pas}}
:Auch hier lässt die Namensgebung recht schnell auf die Units für die FMOD-Library schliessen, die als Grundlage für unser Soundsystem dient.

{{Unit|GLBmp.pas}}
:Zu dieser Unit muß ich wohl kaum noch viele Worte verlieren, haben wir diese doch schon im Editor zum Laden der Texturen genutzt.
:Quelle : http://delphigl.cfxweb.net

{{Unit|OpenGL12.pas}}
:Auch zu dieser Unit gibts nicht viel zu sagen. Sie beinhaltet alle nötigen Deklarationen und Funktionen zur Nutzung von OpenGL (1.2).

==Verwendete Techniken==
Bevor wir uns also in den Quellcode stürzen, werde ich hier kurz die verwendeten Techniken, deren Nutzen und deren Umsetzung erklären. Alle hier erwähnten Dinge werdet ihr in weiteren Projekten verwenden können und sind für das Gelingen größerer Projekte fast unerlässlich, also lest aufmerksam!

[[Bild:Tutorial Bomberman2 bombermanbomb.gif|left]]
===Timebased Movement===
Bisher werden viele von euch (wenn sie denn schonmal ein kleines Spiel programmiert haben) die Ereignisse wie z.B. Spielerbewegung oder das aktualisieren einer Animation am Ende eines jeweiligen Frames abgearbeitet haben. Das ist zwar eine einfache Lösung, hat jedoch den riesigen Nachteil, dass Bewegungen und Animationen je nach Rendergeschwindigkeit (sprich Anzahl der pro Sekunde berechneten Bilder) verschieden sind.
Daraus resultiert z.B., das sich eine Spielfigur auf einem schnellen Rechner unkontrollierbar schnell nach vorne bewegt, während sie auf einem langsamen Rechner kaum von der Stelle kommt. Besonders schlecht ist sowas in einem Netzwerkspiel, da der Spieler am langsamen Rechner durch die langsamere Bewegung einen großen Nachteil hat.
Abhilfe schafft hier das sog. "Timebased Movement" (zu Deutsch : Zeitbasierte Bewegung), welches für gleichmäßige Bewegungen bzw. Animationen sorgt, in dem es (im Gegensatz zum "Framebased Movement") diese mittels Zeitmessung auf einen festen Faktor angleicht.

Die Implementation dieser Technik ist zum Glück recht einfach, bietet uns Windows doch netterweise (über einen im Chipsatz integrierten Timer) einen Hochpräzisionstimer dessen Auflösung um ein Tausendfaches höher ist als die eines Systemtimers.
Damit wird es uns möglich die oft nur sehr geringen Zeitabstände zwischen dem Rendern der Frames zu berechnen. Ein kleines Beispiel :
Ein moderner Rechner schafft heute in einer nicht besonders Aufwendigen 3D-Szene ohne Probleme an die 300-400 Bilder pro Sekunde. Dies bedeutet, das er zum Berechnen und Ausgeben eines Bildes 2,5ms (=1000ms/400fps) benötigt. Ein normaler Systemtimer würde uns eine solche Messung mit seiner "Genauigkeit" von ~55ms gänzlich unmöglich machen.

Windows bietet uns nun zwei Funktionen zur Nutzung dieses Hochpräzisionstimer an :

*function QueryPerformanceFrequency(var lpFrequency : TLargeInteger): Bool;
:Diese Funktion liefert uns in ''lpPerformanceCount'' die Anzahl der Takte pro Sekunde zurück, also die Auflösung des Timers. Dieser Wert variiert von Chipsatz zu Chipsatz und '''muß''' deshalb unbedingt beim Programmstart abgefragt und in einer Variable abgelegt werden.
:Meine Hauptplatine auf Basis des nVidia nForce2-Chipsatz liefert z.B. den Wert 3579545, d.h. dass der Hochpräzisionstimer genau 3.579.545 mal pro Sekunde taktet.

*function QueryPerformanceCounter(var lpPerformanceCount : TLargeInteger): Bool;
:Obige Funktion liefert uns in ''lpPerformanceCount'' den aktuellen Stand des Hochpräzisionscounter, gemessen in Systemtakten zurück, und wird von uns zur genauen Zeitmessung genutzt.

====Ermitteln der Counterfrequenz====
Wie schon in der Funktionsbeschreibung erwähnt müssen wir vor der Nutzung des Hochpräzisionscounters erstmal dessen Frequenz ermitteln. Dies tun wir direkt beim Start unseres Programms im '''OnCreate'''-Ereignis des Hauptfensters :

<pascal>procedure TBomberManForm.FormCreate(Sender: TObject);
begin
QueryPerformanceFrequency(PerfCounterFreq);
[...]
end;</pascal>

Die Variable ''PerfCounterFreq'' wird in der Unit ''BombermanGlobal.pas'' deklariert und ist vom Typ ''Int64''. In dieser ist von nun an die Frequenz unseres Hochpräzisionstimers hinterlegt. Sofern dieser Wert größer 0 ist, läuft alles nach Plan. Solltet ihr hier wider Erwarten den Wert Null zurückgeliefert bekommen, unterstützt die Hardware dieses Timingverfahren nicht, was jedoch nur bei sehr alten CPUs so ist.

====Die Zeitmessung====
Nach der recht langen Präambel widmen wir uns nun dem eigentlich Kern des Timebased Movements, nämlich der Zeitmessung. Diese wird in in der ''DrawScene''-Prozedur unseres ''TBombermanGame''-Objektes (BombermanGlobal.pas) umgesetzt :

<pascal>procedure TBomberManGame.DrawScene;
var
QPCStartCount, QPCEndCount : Int64;
begin
QueryPerformanceCounter(QPCStartCount);
[...]
// Szene zeichnen
[...]
QueryPerformanceCounter(QPCEndCount);</pascal>

Der Quellcode spricht eigentlich für sich. Wir ermitteln insgesamt zwei Zeitwerte, zum einen '''vor''' dem Zeichnen der Szene und zum anderen '''nach''' dem Zeichnen der Szene, und speichern diese ab.
Danach berechnen wir über eine recht einfache Formel unseren Zeitfaktor :

<pascal>BomberManGame.TimeFactor := (QPCEndCount-QPCStartCount)/PerfCounterFreq*100;
end;</pascal>

Dieser Zeitfaktor entspricht dann der zum Rendern benötigten Zeit in ms/10 und kann dann beim aktualisieren der Bewegungen bzw. Animationen als Faktor genutzt werden.

====Kleine Rechenkunde====
Um denn Sinn und die Funktion des Timebased Movement besser verstehen zu können, gibts hier ein paar kleine Rechenbeispiele, die darlegen dass der Code nun frameunabhängig Funktioniert :

Rechner 1 braucht 7 ms um die Szene zu Rendern
:Zeitfaktor = 0.7
:Bewegung des Spieler = 0.05*0.7 = 0,035 Einheiten
:Bewegungen werden 142 mal pro Sekunde aktualisiert (142fps)
:Gesamtbewegung/s = 142*0,035 = 4,97 Einheiten
:Ohne Timebased Movement : Gesamtbewegung = 142*0,05 = 7,1 Einheiten

Rechner 2 braucht 11 ms um die Szene zu Rendern
:Zeitfaktor = 1.1
:Bewegung des Spieler = 0.05*1.1 = 0,055 Einheiten
:Bewegungen werden 90 mal pro Sekunde aktualisiert (90fps)
:Gesamtbewegung/s = 90*0,055 = 4,95 Einheiten
:Ohne Timebased Movement : Gesamtbewegung = 90*0,05 = 4,5 Einheiten

Ich hoffe mal, dass diese beiden Beispiele verdeutlichen, das sich der Spieler unter Zuhilfenahme des Timebased Movements auf verschieden schnellen Rechner (und in verschieden komplexen Szenen) mit gleicher Geschwindigkeit bewegt. Die Diskrepanz vin 0,02 Einheiten bei obigen Werten ist darauf zurückzuführen, dass ich mit abgerundeten Werten gerechnet habe.

Auch wenn dieser Teil des Tuts etwas theoretisch und trocken war, so ist das Timebased Movement, wie ihr sicher schon aus dem Text herauslesen konntet unerlässlich für moderne Spieletitel, und zwar ganz besonders dann wenn diese später auch im Netzwerk bzw. über das Internet spielbar sein sollen. Allerdings wird sich Bomberman drüber freuen, das er sich jetzt auf jedem System gleichschnell fortbewegen kann... [[Bild:Bomberman wait.gif]]

[[Bild:Tutorial Bomberman2 bombermanbomb.gif|left]]
===Statemachine===

Auch diesen Begriff dürften einige von euch schonmal irgendwo aufgeschnappt haben. Vermutlich war das aber in einem anderen und weitaus komplexerem Zusammenhang als dies bei unserer (recht primitiven) Statemachine der Fall ist.

Spiele bestehen ja bekannterweise aus verschiedenen Szene (=States) wie z.B. dem Hauptmenü und der 3D-Ansicht. Die Statemachine macht in unserem Falle nichts anderes als den in TBombermanGame.CurrentState gesetzten Status abzufragen und dann in die entsprechende Zeichenroutine zu verzweigen. So hat man die für die einzelnen Szenen erforderlichen Zeichneroutinen in verschiedene Prozeduren separiert und kann später bequem und ohne großen Aufwand neue Szenen hinzufügen.

Für jede Szene deklarieren wir in der Konstantensektion der globalen Unit eine eigene Konstanten, anhand derer sie eindeutig identifiziert werden kann :

<pascal> const
GSMainMenu = $00;
GSNewGame = $01;
GSInGame = $02;
GSMatchEnd = $03;</pascal>

Die Statemachine prüft dann in der Zeichenprozedur '''TBombermanGame.DrawScene''' in welchem Status sie sich befindet und verzweigt dann mittels einer einfachen Case-Anweisung zur entsprechenden Zeichneroutine :

<pascal> procedure TBomberManGame.DrawScene;
[...]
case CurrentState of
GSMainMenu : DrawScene_GSMainMenu;
GSNewGame : DrawScene_GSNewGame;
GSInGame : DrawScene_GSInGame;
GSMatchEnd : DrawScene_GSMatchEnd;
else
DrawScene_GSMainMenu;
end;
[...]</pascal>

Den Status unserer Statemachine setzen wir dann mittels der Prozedur '''TBombermanGame.SetState'''. Aber warum tun wir das nicht direkt über die Variable '''TBombermanGame.CurrentState'''? Dafür gibts einen ganz einfachen Grund : Es ist möglich, dass beim Wechsel zwischen zwei Zuständen verschiedene Variablen geändert oder gesetzt werden müssen. Wechseln wir den Status also über oben genannte Prozedur, so können wir vor dem finalen Wechsel noch prüfen in welchen Status gewechselt wird, und eventuell noch benötigte Variablen setzen oder verändern.

Auch wenn oben beschriebenes recht banal erscheinen mag, so ist eine Statemachine (egal wie primitiv) ein einfaches Mittel zur Verwaltung des Spielzustandes, die sich dazu noch recht leicht erweitern lässt.

[[Bild:Tutorial Bomberman2 bombermanbomb.gif|left]]
===Texturenfonts===

Was vielen ein Dorn im Auge ist, und sich hoffentlich bald ändert, ist das Fehlen von Routinen zur Fontdarstellung in OpenGL. Aber zum Glück haben sich einige findige Programmierer zu diesem Thema Gedanken gemacht und Methoden zur Schriftdarstellung mittels OpenGL entwickelt die recht einfach zu nutzen und gleichzeitig schnell sind. Eine davon sind Texturenfonts, die wie deren Name schon vermuten lässt, ihre Schriftzeichen aus einer Textur herausholen.

Ein Tool das diese Texturen erstellen kann, wurde von mir bereits am Anfang dieses Tutorials vorgestellt, nämlich der Bitmap Font Builder. Dieser erstellt auf der Basis einer Windowsschriftart eine Textur die alle nötigen Schriftzeichen enthält, und z.B. so aussehen könnte :

[[Bild:Tutorial Bomberman2 texfont.jpg|center]]

Das Erstellen und Ausgeben dieser Schrift erledigt für uns die Klasse '''TTexFont''' in der Unit '''TBombermanFont.pas'''. Dort finden sich am Anfang in der Konstantesektion die vorgenerierten Texturenkoordinaten für die einzelnen Buchstaben. Da grundlegende Kenntnisse zum Thema Texturemapping eine Voraussetzung für dieses Tut sind, gehe ich davon aus das ihr wisst was diese zu bedeuten haben und wie sie funktionieren.

Unsere '''TTexFont'''-Klasse tut jetzt bei der Initialiserung nichts anderes, als für jedes in der Textur hinterlegte Schriftzeichen anhand der in der Konstantesektion festgelegten Texturkoordinate eine Displayliste zu erstellen, die beim Ausgeben des Textes dann nur noch aufgerufen wird.

[[Bild:Tutorial Bomberman2 bombermanbomb.gif|left]]
===Animierte Texturen===

In unserem Bombermanklon nutzen wir für die Explosionen animierte Texturen. Diese animierten Explosionen lassen sich auf zwei Arten realisieren :

====Verschiedene Texturen====
Wir laden für jede Explosionsphase eine eigene Textur. Dazu benötigen wir also 16 Texturen, die auf der Festplatte recht viel Speicher beanschlagen. Je nach Explosionsphase binden wir nun vor dem Zeichnen des Explosionsquad die zur aktuellen Explosionsphare gehöhrende Textur.

Diese Methode ist zwar recht einfach zu implementieren, hat jedoch einige Nachteile : Da jede Animationsphase in einer eigenen Textur liegt wird sowohl auf der Festplatte als auch im Grafikspeicher recht viel Overhead erzeugt.

====Eine Textur====
Dies ist die Lösung die wir verwenden werden, da sie recht viele Vorteile beherbergt. Wir erstellen uns mittels eines Tools (z.b. den am Anfang des Tuts erwähnten [[Tutorial Bomberman2#Voraussetzungen|ExplosionsGenerator]]) '''eine Textur''' auf der in Reihen und Spalten '''alle Animationsphasen''' der Explosion dargestellt sind.

Nun binden wir für jedes Explosionsquad '''dieselbe Textur''' und verändern entsprechend der Animationsphase nur unsere '''Texturkoordinaten''', die wir in einem speziellen Array abgelegt haben :

<pascal>ExpTexCoord : array[0..15, 0..3] of Single =
((0, 0, 0.25, 0.25), (0.25, 0, 0.5, 0.25), (0.5, 0, 0.75, 0.25), (0.75, 0, 1, 0.25),
(0, 0.25, 0.25, 0.5), (0.25, 0.25, 0.5, 0.5), (0.5, 0.25, 0.75, 0.5), (0.75, 0.25, 1, 0.5),
(0, 0.5, 0.25, 0.75), (0.25, 0.5, 0.5, 0.75), (0.5, 0.5, 0.75, 0.75), (0.75, 0.5, 1, 0.75),
(0, 0.75, 0.25, 1), (0.25, 0.75, 0.5, 1), (0.5, 0.75, 0.75, 1), (0.75, 0.75, 1, 1));</pascal>

Wenn man sich dieses Array genauer betrachtet, dann kann man schon erahnen das unsere Explosionstextur in 4x4 Zellen aufgeteilt ist, und von links nach rechts verläuft. Links seht ihr die vom Explosionsgenerator erstellte Textur, und rechts selbige mit ein paar von mir eingetragenen Texturkoordinaten, die euch das Verständnis dieser Technik ein wenig erleichtern sollten :

<div align="center">[[Bild:Tutorial Bomberman2 explosion.jpg]][[Bild:Explosion det.jpg]]</div>

Wer also weiß wie man mit Texturkoordinaten umgeht dürfte hier absolut keine Verständnisprobleme haben. Unser Quad zeichnen wir dann wie folgt (siehe '''TMap.Draw''') :

<pascal>glBegin(GL_QUADS);
glTexCoord2f(ExpTexCoord[Round(ExplosionPhase)][0], -ExpTexCoord[Round(ExplosionPhase)][3]); glVertex3f(0, 0, 0);
glTexCoord2f(ExpTexCoord[Round(ExplosionPhase)][2], -ExpTexCoord[Round(ExplosionPhase)][3]); glVertex3f(2, 0, 0);
glTexCoord2f(ExpTexCoord[Round(ExplosionPhase)][2], -ExpTexCoord[Round(ExplosionPhase)][1]); glVertex3f(2, 2, 0);
glTexCoord2f(ExpTexCoord[Round(ExplosionPhase)][0], -ExpTexCoord[Round(ExplosionPhase)][1]); glVertex3f(0, 2, 0);
glEnd;</pascal>

Wie leicht zu erkennen nehmen wir unsere Texturkoordinaten anhand der aktuellen Explosionsphase aus unserem vorher in der Konstantensektion deklariertem Koordinatenarray. Bei ExplosionPhase=0 sieht unser Quad also so aus :

<pascal>glBegin(GL_QUADS);
glTexCoord2f(0, -0.75); glVertex3f(0, 0, 0);
glTexCoord2f(0.25, -0.75); glVertex3f(2, 0, 0);
glTexCoord2f(0.25, 0); glVertex3f(2, 2, 0);
glTexCoord2f(0, 0); glVertex3f(0, 2, 0);
glEnd;</pascal>

Der offensichtliche Vorteil dieser Methode ist die Tatsache, das die komplette Animation in einer Textur abgelegt ist, und somit nur eine Textur auf der Festplatte sowie im Grafikkartenspeicher Platz verbraucht.

[[Bild:Tutorial Bomberman2 bombermanbomb.gif|left]]

===Soundsystem===

Zu einer intensiven Spielumgebung gehören natürlich nicht nur aufwendige Grafiken, sondern auch Soundeffekte die dem Spieler das Gefühl vermitteln, er bewege sich inmitten einer dreidimensionalen Umgebung.

Hier springt unser Soundsystem ein ('''BombermanSoundSystem.pas'''), welches einfache Routinen zur Initialiserung und Ausgabe von Soundateien mitbringt.

Auf dem Markt gibt es inzwischen einige sehr gute Soundlibraries, die vor allem für Freewareprogramme kostenlos nutzbar sind. Deshalb machen wir von einer dieser Soundbibliotheken gebrauch, nämlich [http://www.fmod.de fmod], dessen Vorteile ein riesiger Funktionsumfang und die Nutzung aller gängigen Soundformate ist.

Unser Soundsystem tut deshalb nichts anderes als diese (sowieso schon einfach nutzbare) Bibiliothek zu kapseln. So kann man später einfach auf eine andere Bibliothek umsteigen, oder sein Soundsystem komplett selbst z.B. unter Verwendung von DirectSound programmieren.

Auf die Funktionsweise bzw. Implementation von fmod werde ich hier jedoch nicht genauer eingehen. Die mit dieser Bibliothek gelieferten Hilfedateien und Beispiele sind so ausführlich, dass jede weitere Dokumentation Zeitverschwendung wäre.

Unsere Implementation der FMOD-Library ins Soundsystem werden wir später aber noch genauer betrachten.

So viel also zu den verwendeten Techniken. Fehlen tut in der Liste zwar der Texturenmanager, diesen haben wir allerdings schon im letzten Tutorial besprochen, das ihr ja alle bestimmt aufmerksam gelesen habt ;-)

==Verwendete Dateiformate==
Natürlich sollte man sich bei der Programmierung eines Spiels Gedanken über die verwendeten Dateiformate machen. Hier braucht man das Rad nicht neu zu erfinden und sollte wenn möglich auf bereits bestehende Formate und Editoren zurückgreifen. Ich werde jetzt alle in unserem Bombermanklon verwendeten Formate auflisten, kurz begründen warum wir diese verwenden und auch Alternativen nennen.

===3D-Modelle===
Für unsere 3D-Modelle (Spieler, Bomben) nutzen wir das sehr weit verbreitet '''3DS-Format''', in das fast alle gängigen 3D-Modellierprogramme exportieren können. Ein weiterer Vorteil neben der breiten Unterstützung durch gängige Programme ist die Existenz diverser 3DS-Laderoutinen in allen möglichen Programmiersprachen.
Großer Nachteil dieses Formates sind Animationen, die auf Keyframe-Basis gesichert werden und deshalb recht schlecht zu implementieren sind, weshalb der genutzte 3DS-Loader diese auch nicht lädt.
Als Alternative (vielleicht gibts dazu etwas im nächsten Tutorial) schlage ich deshalb das Milkshapeformat vor, zu dem es auf DGL übrigens eine praktische Ladebibliothek gibt.

Weitere Infos zum 3DS-Format gibts auf [www.wotsit.org www.wotsit.org].

Auf der Suche nach 3D-Modellen sollten vor allem folgende Seiten gute Anlaufstellen sein :
*http://www.planetquake.com/polycount (Die Netzweit wohl größte Datenbank an Modellen für Q2/Q3/UT/UT2003/HL
*http://www.3dcafe.com (Recht große Sektion mit frei downloadbaren Modellen im 3DS-Format)

===Sounds===
Soundformate exisitieren inzwischen reichlich, und dank der FMOD-Library sind wir in dieser Hinsicht auch sehr flexibel. Da wir unser Spiel aber im Netz vertreiben wollen, nutzen wir für größere Sounds (also z.B. die Hintergrundmusik) das '''OGG-Vorbis-Format'''. Nicht nur das es ggü. dem MP3-Format bessere Qualität bei gleicher Komprimierung bietet, nein es ist sogar ein komplett gebührenfreies Format und kann deshalb selbst in kommerziellen Anwendungen ohne Copyrightprobleme genutzt werden.
Für kleinere Sounds wie z.B. die Bombenexplosion nutzen wir weiterhin das altbewährte '''Wave-Format'''.

Sounds finden sich im Netz leider weitaus schwerer als 3D-Modelle und Texturen, ein guter Anfang bildet allerdings folgende Page : http://www.findsounds.com

===Texturen===
Auch hier sind wir bei der Wahl des Formates dank glBMP.pas recht flexibel. Allerdings wollen wir auch Alphamasking unterstützen, eine Technik bei der man vorher im Bildbearbeitungsprogramm markierte Bereiche durchsichtig machen kann. Deshalb benötigen wir ein Format das die Speicherung des Alphakanals unterstützt.Dazu kämen entweder TGA oder PNG in Frage.
Da PNG jedoch recht neu ist und es für Delphi kaum Loader gibt, verwenden wir für unsere Texturen das TGA-Format.

Texturen für Spiele in Hülle und Fülle, und dazu noch in der Public Domain gibts übrigens beim [http://www.planethalflife.com/wadfather/index-new.htm WadFather].

===Karten===
Natürlich müssen wir auch ein Format für unsere selbsterstellten Karten wählen. Dieses Kapitel haben wir ja schon hinreichend im ersten Tutorial durchgekaut, weshalb ich hier nicht weiter drauf eingehen werde.

==Der Quellcode==
So Leute, jetzt gehts ans Eingemachte. Während der Quellcode zum Editor noch leicht überschaubar, recht kurz und die Anzahl der Objekte/Klassen sehr gering war, gehts jetzt etwas heftiger zur Sache, da unser Projekt bereits auf weit über 1000 Zeilen angewachsen ist.

Ich werde aber mein Bestes geben und versuchen alle wichtigen Codestellen, Variablen und Prozeduren möglichst detailliert und leicht nachvollziehbar zu erklären. Wenns doch noch irgendwo happert und selbst die Kommentare im Quellcode keine Lösung bringen, dann gibts ja immer noch das DGL-Forum in dem ich dann auf eure Fragen gerne eingehe... [[Bild:Bomberman Right.gif]]

===Grundgedanken===
Bevor ihr wild drauflos programmiert, solltet ihr euch natürlich über die in eurem Spiel benötigten Klassen, Objekte und Variablen Gedanken machen. Bei einem bereits vorgegebenem Spielprinzip wie Bomberman ist das natürlich eine recht einfache Sache. Hier brauchen wir Klassen (bzw. Objekte) die unser Spielfeld, die Spieler und gelegte Bomben repräsentieren. Des weiteren gibts noch die Klasse '''TBombermanGame''', welche das eigentliche Spiel kapselt und neben Routinen zur Initialisierung auch zur Verwaltung der globalen Spiellogik dient.

Wie ihr seht, ist es also essentiell sich über seine Objekte und Klassen Gedanken zu machen, denn besonders in der OOP sind dies mächtige Werkzeuge um den Code leichter nutzbar und übersichtlicher zu machen. In größeren Projekten spielt diese Planung natürlich eine weit wichtiger Rolle, kann man sich doch viel Arbeit mittels Vererbung sparen.

Wenn ihr nun z.B. KI-gesteuerte Monster in unseren Bombermanklon integrieren wollt, so könntet ihr euch eine TActor-Klasse schreiben, die sich um Kollsionsabfrage und das Zeichnen der Figur kümmert und davon sowohl die menschlich gesteuerten Figuren (TPlayer) als auch die KI-Aktoren (TKIActor) ableiten.

===Auslagern von Klassen/Objekten===
Ich hab es im Verlaufe dieses Tuts bereits kurz angeschnitten (bei der Unitauflistung). Klassen bzw. Objekte die nicht spezifisch auf das Spiel zugeschnitten sind (wie z.B. der Texturenmanager oder das Soundsystem) sollten am besten in eine externe Unit ausgelagert werden.

Dies hat den Vorteil, das man sich so nach und nach eine große Codebasis schafft die man dann später in anderen Projekten nutzen kann. So werdet ihr dann nur noch einen Texturenmanager programmieren müssen, den ihr von nun an in jedes andere Projekt einbinden und sofort nutzen könnt. Ein weiterer Vorteil dieser Methode ist die Tatsache, dass eine Erweiterung des Texturenmanagers z.B. direkt in jedem eurer Projekte verfügbar ist. Deshalb wäre es keine schlechte Idee, wenn ihr euch für solche Units einen eigenen Ordner erstellt und in euren Projekten direkt auf die dort befindlichen Units linkt.

===BombermanGlobal.pas===

Zu aller erst kümmen wir uns um unsere stark erweiterte Codebasis, zu der sich einige neue Objekte und Klassen gesellen. Im Folgenden werde ich euch zu jedem Objekt bzw. jeder Klasse die Deklaration liefern und wichtige Codestellen und Prozeduren detailliert erläutern :

====Das Spielfeld (TMap)====
Dieses Objekt haben wir ja bereits im ersten Tutorial besprochen. Hier ist nichts dazugekommen, weshalb wir uns mit diesem nicht weiter beschäftigen werden.

====Die Spielfigur (TPlayer)====
Dieses Objekt repräsentiert die Spieler und kümmert sich um deren Verwaltung. Die Liste der Spieler wird in dem dynamischen Array '''Player''' verwaltet, so daß es in der Anzahl der Spieler rein theoretisch keine Grenzen gibt. Einige der Eigenschaften dieses Objektes wie z.B. Size verändern sich im Verlaufe des Spielgeschehens nicht. Der Grund warum ich diese dennoch implementiert habe liegt darin, das unser Klon später mit aufsammelbaren Extras erweitert wird, die einige Eigenschaften des Spielers ähnlich dem Original beinflussen. Außerdem lässt sich über diese Eigenschaften das Gameplay recht einfach anpassen, ohne das man diverse Stellen im Quellcode nachträglich verändern muß.

Das Objekt '''TPlayer''' bringt folgende Eigenschaften und Funktionen mit :

;<nowiki>Position : TVector3f;</nowiki> : Die aktuelle Spielerposition auf dem Spielfeld .Hierzu verwenden wir einen Fließkommavektor, da sich der Spieler frei und nicht nur Feld für Feld bewegen soll.

;<nowiki>ExplosionRadius : Integer;</nowiki> : Gibt den Explosionsradius der vom Spieler gelegten Bomben an.

;<nowiki>MaxBombs : Integer;</nowiki> : Die Anzahl der von diesem Spieler maximal gleichzeitig platzierbaren Bomben.

;<nowiki>Direction : Integer;</nowiki> : Die Blickrichtung des Spielers.Diese Variable wird nur genutzt um das 3D-Modell in die korrekte Richtung zu drehen.

;<nowiki>Wins : Integer;</nowiki> : Anzahl der von diesem Spieler gewonnenen Spiele.

;<nowiki>IsDead : Boolean;</nowiki> : Wie fast alle anderen Variablen ist auch diese selbstredend. Wenn diese True ist, dann hats den Spieler erwischt und er kann nicht mehr am Spiel teilnehmen.

;<nowiki>Speed : Single;</nowiki> : Bewegungsgeschwindigkeit des Spielers.

;<nowiki>Size : Single;</nowiki> : Die Ausmaße der Spielfigur.

;<nowiki>Model3DS : String;</nowiki> : Der Name des zu diesem Spieler gehörenden 3D-Modells.

;<nowiki>KeyUp, KeyDown, KeyLeft, KeyRight, KeyFire : Word</nowiki> : Die Tastenbelegung des Spielers.

;<nowiki>function IsPositionValid(pNewPosX, pNewPosZ : Single) : Boolean;</nowiki> : Diese Funktion implementiert die (zum Glück recht einfache) Kollisionsabfrage, und prüft ob die Position an die sich der Spieler bewegen will auch begehbar ist. Dabei wird geprüft, ob das Feld unter der neuen Position begehbar ist, ob Kollision mit anderen Spielern stattfindet und ob Bomben im Weg liegen.<br> Wenn die neue Position gültig ist, dann liefert diese Funktion den Wert TRUE zurück.

;<nowiki>procedure UpDate;</nowiki> : In dieser Version unseres Bombermanklons hat diese Prozedur nur den einzigen Zweck zu prüfen ob sich der Spieler in einer Explosion befindet. Ist dies der Fall, so stirbt er und es wird ein entsprechender Sound abgespielt.

;<nowiki>procedure Draw;</nowiki> : Wie der Name bereits vermuten lässt kümmert sich diese Prozedur um das Zeichnen der Spielfigur und deren Schattens. Die hier verwendeten Schatten sind jedoch von der Sorte "Ganzbillig" und sind nichts anderes als auf den Boden geblendete Texturen. Für unseren Bombermanklon sind sie jedoch ausreichend und geben der Szene etwas mehr an Realismus.

;<nowiki>procedure DropBomb;</nowiki> : Auch dieser Prozedurnamen lässt bereits auf ihre Funktion schliessen. Sie prüft, ob die Zahl der vom Spieler gelegten Bomben nicht die maximale Anzahl an legbaren Bomben überschreitet und legt platziert eine Bombe auf dem Spielfeld.

;<nowiki>procedure ProcessInput;</nowiki> : Auch hier gibts nix besonderes. Mittels '''GetAsyncKeyState''' prüfen wir auf Hardwareebene ob eine Taste im gedrückten Zustand ist und führen dann die damit verbundene Aktion aus. Ist die übergebene Taste gedrückt, wird das höchstwertige Bit des zurückgegebenen Wertes gesetzt. <br>Im Falle einer Bewegung prüfen wir natürlich nach, ob die neue Position des Spielers auch gültig ist. <br> Einzige Besonderheit ist hier die Nutzung unseres vorher berechneten Zeitfaktors '''BomberManGame.TimeFactor''' als Faktor für die Bewegungsgeschwindigkeit.

====Bomben (TBomb)====
Auch die von den Spielern legbaren Bomben habe ich in einer Klasse gekapselt um deren Verwaltung und Aktualisierung zu erleichtern. Hier gibts eigentlich nix Spektakuläres, weshalb ich direkt zu den Eigenschaften und Prozeduren übergehe :

;<nowiki>Position : TVector3i;</nowiki> : Die Position der Bombe als '''Integer'''-Vektor, da Bomben nur genau in der Feldmitte abgelegt werden (wie beim original Bomberman).
;<nowiki>Owner : ^TPlayer;</nowiki> : Zeiger auf den Besitzer dieser Bombe.Diese Eigenschaft wird benötigt um herauszufinden wie viele Bomben dieser Spieler bereits gelegt hat, und um die Explosionsreichweiter der Bombe (die auch spielerabhängig ist) zu ermitteln.
;<nowiki>CountDown : Single;</nowiki> : Wie der Eigenschaftsname bereits vermuten lässt ist hier der Countdown bis zur Explosion der Bombe gespeichert. Sinkt dieser Wert auf >= 0, so wird die Explosion eingeleteitet und die Bombe aus der dynamischen Liste entfernt.
;<nowiki>AnimPhase : Single;</nowiki> : Die Animationsphase wird als Grundlage für die sinusförmigen Skalierung der Bombe genutzt und lässt so den Eindruck entstehen als würde die Bombe sich strecken und wieder zusammenziehen.
;<nowiki>procedure Draw;</nowiki> : Kümmert sich um das Zeichnen der Bombe sowie deren Schattens.
;<nowiki>procedure Explode;</nowiki> : Startet die lineare Explosion in vier Richtungen. Wie im Original wird die Explosion in die jeweilige Richtung durch einen Block gestoppt. Ist dieser Block sprengbar, so wird er vom Spielfeld entfernt. <br>Trifft die Explosion auf ihrem Weg auf eine andere Bombe, so wird der Countdown dieser Bombe auf einen Wert nahe 0 gesetzt, so daß eine Kettenrekation stattfindet.

====Das Spiel (TBomberManGame)====
Wie bereits erwähnt repräsentiert dieses Objekt unser Spiel und kümmert sich neben der Verwaltung dynamischer Listen und der Spiellogik auch um die Initialisierung wichtiger Listen bzw. OpenGL und implementiert unsere bereits ausgiebig beschriebene Statemachine. Bei Erweiterung solltet ihr hier alles was global geschieht und nicht von den Objekten selbst getan werden kann unterbringen.

<u>'''Private Deklarationen'''</u>
;<nowiki>ShakeScreen : Single;</nowiki> : In dieser Eigenschaft wird die Restdauer gespeichert während der der Bildschirm nach einer Bombenexplosion erschüttert wird.
;<nowiki>procedure DrawScene_GSMainMenu/DrawScene_GSNewGame/DrawScene_GSInGame/DrawScene_GSMatchEnd;</nowiki> : Wie bereits im Kapitel zur Statemachine angesprochen sind dies die Unterprozeduren die von der Statemachine zum Zeichnen der verschiedenen Spielstadien (sprich Szenen) genutzt werden.
<u>'''Öffentliche Deklarationen'''</u>
;<nowiki>gsMainMenu_Selected : Integer;</nowiki> : Wie am Präfix dieser Variable zu erkenne, gibt sie den im Hauptmenü ausgewählten Menüpunkt wieder.
;<nowiki>gsMainMenu_Rotation : Single;</nowiki> : Die Rotation der im Hintergrund des Menüs dargestellten Karte.
;<nowiki>gsNewGame_Selected : Integer;</nowiki> : Im Menü "Neues Spiel" gewählter Menüpunkt.
;<nowiki>gsNewGame_Players : Integer;</nowiki> : Anzahl der im Menü "Neues Spiel" eingestellten Spieler.
;<nowiki>MapList : TStringList;</nowiki> : In dieser Stringlist werden mit der Prozedur '''CreateMapList''' alle Namen der in einem bestimmten Ordner gefundene Karten abgelegt, so daß diese im Spielmenü bequem ausgewählt werden können.
;<nowiki>ExtremeMode : Boolean;</nowiki> : Der Name lässts wohl bereits vermuten. Hiermit wird dem Spiel mitgeteilt das es sich im Extremmodus befindet, in dem sowohl Anzahl der legbaren Bomben als auch deren Reichweite und die Geschwindigkeit der Spielfigur stark erhöht werden.
;<nowiki>MapListPos : Integer;</nowiki> : Position der gewählten Karte in '''MapList'''
;<nowiki>TimeFactor : Single;</nowiki> : Diese Variable wurde bereits im Kapitel zum Thema "Timebased Movement" besprochen und behinhaltet den Zeitfaktor der für eine gleichmäßige Bewegung/Animation sorgt.
;<nowiki>OwnerForm : ^TForm;</nowiki> : Zeiger auf die Form in der das Spiel dargestellt wird. Dieser Zeiger muß einen Wert besitzen und darf nicht ins Leere zeigen.
;<nowiki>CurrentState : Word;</nowiki> : Aktueller Status der Statemachine.
;<nowiki>procedure SetState(pNewState : Word);</nowiki> : Versetzt die Statemachine in einen neuen Status.
;<nowiki>procedure CreateMapList(pMapDir : String);</nowiki> : Erstellt eine Liste aller in ''pMapDir''' befindlichen Karten, so daß auf diese einfach und schnell zugegriffen werden kann.
;<nowiki>procedure Create3DSList(p3DSDir : String);</nowiki> : Erstellt eine Liste aller in '''p3DSDir''' befindlichen 3DS-Modelle und generiert auch gleichzeitig deren Displaylisten.
;<nowiki>procedure InitOpenGL;</nowiki> : Erstellt den OpenGL-Rendercontext und initialisiert einige OpenGL-Parameter.
;<nowiki>procedure DrawScene;</nowiki> : Diese Prozedur verzweigt je nach Zustand der Statemachine in die entsprechende Zeichenprozedur.
;<nowiki>procedure UpDateBombs;</nowiki> : Aktualisiert die dynamische Bombenliste und entfernt ggf. explodierte Bomben. Diese Aktion muß außerhalb des TBomb-Objektes getätigt werden, da sich ein Objekt nicht selbst aus einer dynamischen Liste entfernen kann.
;<nowiki>procedure StartNewMatch(pMapName : String);</nowiki> : Wie der Prozedurname vermuten lässt starte diese eine neues Match auf der in '''pMapName''' angegeben Karte. Dabei wird die Bombenliste geleert und es werden alle Spieler wieder auf die Grundwerte zurückgesetzt.

Soviel also zur Deklaration unserer Objekte bzw. Klassen. Wie ihr sehen könnt habe ich hier eine sehr saubere Namensgebung verwendet, durch die viele Eigenschaften bzw. Prozeduren selbsterklärend sind.

Wenden wir uns nun einigen interessanten Stellen im Quellcode zu, die eine genauere Erklärung notwendig machen.

====Interessante Codestellen====

=====Zeichnen der InGame-Action (TBomberManGame.DrawScene_GSInGame)=====
Die wichtigste Funktion der TBombermanGame-Klasse bedarf natürlich einer kleinen Erklärung, enthält sie doch recht viele Anweisungen. Deshalb werde ich den Quellcode hier detailliert durchgehen :

<pascal>[...]
glClear(GL_DEPTH_BUFFER_BIT);
glViewport(0, 0, OwnerForm^.ClientWidth, OwnerForm^.ClientHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPerspective(45, OwnerForm^.ClientWidth/OwnerForm^.ClientHeight, 1, 1024);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
glTranslatef(0,0,-30*Length(Map.PlayGround)/24);
glRotatef(45, 1, 0 ,0);
[...]</pascal>

Das Ganze fängt erstmal recht gemütlich mit OpenGL-Standardkost an. Zuert löschen wir den Tiefenpuffer. Ein Löschen des Farbpuffers ist aufgrund der Tatsache das sich unser Spielfeld über den kompletten Bildschirm erstreckt nicht nötigt.
Danach werden Viewport und Perspektive unserer Fenstergröße angepasst, bevor wir unsere Kamera zuguter Letzt in einem 45°-Winkel über dem Spielfeld ausrichten. Die Höhe der Kamera (wie sich aus der Formel in [[glTranslate]]f herbeileiten lässt) wird je nach Größe des Spielfelds in einer anderen Höhe positioniert, so daß man immer das komplette Spielfeld im Sichtbereich hat.Die 24 am Ende der Formel besagt, das sich die Kamera bei einer Kartengröße von 24 Feldern genau 30 Einheiten über dem Spielfeld befindet, bei einer Größe von 48 Spielfeldern würde sie also 60 Einheiten über dem Spielfeld schweben.

<pascal>[...]
if ShakeScreen > 0 then
begin
glTranslatef(-Length(Map.PlayGround)/2-Random+Random, Random-Random, -Length(Map.PlayGround)/2-Random+Random);
ShakeScreen := ShakeScreen-1*TimeFactor;
end
else
glTranslatef(-Length(Map.PlayGround)/2, 0, -Length(Map.PlayGround)/2);
Map.Draw;
[...]</pascal>

Dieses Quellcodesubstrakt sorgt dafür, dass unsere Karte auf dem Bildschirm zentriert wird. Wenn gerade eine Bombe explodiert ist ('''ShakeScreen = True''') verändern wir per Zufall die Position der Karte, so daß der Eindruck entsteht als würde das Spielfeld aufgrund der Bombenexplosion erzittern. Besonders bei einer längeren Kettenreaktion trägt dies nicht unerheblich zu einem dichteren Spielgefühl bei.
Nach der Zentrierung müssen wir natürlich noch unser Spielfeld zeichnen. Die dazu genutzte Prozedur '''TMap.Draw''' kümmert sich übrigens auch um das Zeichnen der Spielfiguren.

<pascal>[...]
for i := Low(Player) to High(Player) do
Player[i].ProcessInput;
[...]</pascal>

Mittels dieser Zeilen verarbeiten wir die Eingaben der Spieler (sprich Tastendrücke). Dies könnne wir jetzt getrost in jedem Frame machen, da wir die Bewegung des Spielers ja mittels unseres errechneten Zeitfaktors an die Rendergeschwindigkeit angleichen.

<pascal>[...]
glPushAttrib(GL_ALL_ATTRIB_BITS);
if Length(Bomb) > 0 then
for i := Low(Bomb) to High(Bomb) do
Bomb[i].Draw;
UpDateBombs;
glPopAttrib;
[...]</pascal>

Bevor wir nun unsere Bomben zeichnen können, sichern wir alle OpenGL-Attribute, damit wir diese für den Fall, das sie durch das Zeichnen der 3DS-Modelle verändert wurden, später wiederherstellen können.Täten wir das nicht, so würden folgende Zeichneoperationen nicht so ausgeführt wie wir das wollten.
Mittels '''UpDateBombs''' lassen wir alle Bomben aktualisieren und die dynamische Bombenliste falls nötig aktualisieren.

<pascal>[...]
glMatrixMode(GL_PROJECTION);
glLoadIdentity;
glOrtho(0,640,0,480,-2000,2000);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
[...]</pascal>

Nachdem wir nun alles in unserer 3D-Ansicht gezeichnet haben schalten wir in die orthogonale Ansicht, also den 2D-Modus von OpenGL um unsere Informationsleiste mit den Spielerpunktständen zu zeichnen. Dies geschieht mittels [[glOrtho]].Mit den ersten vier Parametern legen wir die Ausmaße der 2D-Ansicht fest, während die letzten zwei der Near- und Far-Wert für das Viewclipping sind.Diese Werte sind deshalb so groß, damit die 3D-Modelle der Spielerköpfe nicht geclippt werden.

<pascal>[...]
for i := 0 to 3 do
begin
glPushMatrix;
glTranslatef(128+i*128, 455, 20);
glScalef(0.5, 0.5, 0.5);
if Player[i].IsDead then
Draw3DSModel('bomberhead'+IntToStr(i+1)+'d')
else
Draw3DSModel('bomberhead'+IntToStr(i+1));
glColor3f(1,1,1);
glPopMatrix;
end;
[...]</pascal>

Nun zeichnen wir in einer Schleife die 3D-Modelle der Spielerköpfe in dieser 2D-Ansicht. Dabei wird mittels der ''If-Anweisung'' je nach Status des Spielers (tot oder lebendig) ein anderes Modell gezeichnet. Da wir uns ja im 2D-Modus befinden können wir die Positionen mittels ''glTranslatef'' pixelgenau angeben.

<pascal>[...]
for i := 0 to 3 do
begin
glPushMatrix;
glTranslatef(128+i*128, 455, 20);
glScalef(1,-1,1);
TextureFont.Print2D(IntToStr(Player[i].Wins), [16,-3,0], [1,1,1], 1, 1);
glScalef(1,-1,1);
glPopMatrix;
end;
[...]</pascal>

Zu dieser Schleife gibts eigentlich auch nicht viel zu sagen. Hier geben wir neben den Köpfen die Punktzahlen der einzelnen Spieler aus. Einzige Besonderheit ist hier das [[glScale]]f(1,-1,1) vor der Textausgabe.Dies ist deshalb nötig, da ich bei der Definition des 2D-Modus mittels glOrtho die Werte für Oben/Unten aus beleuchtungstechnischen Gründen getauscht habe.

<pascal>[...]
PlayersAlive := 0;
for i := 0 to High(Player) do
begin
Player[i].UpDate;
if not Player[i].IsDead then
inc(PlayersAlive);
end;
case PlayersAlive of
0 : begin
BomberManGame.StartNewMatch(Map.FileName);
end;
1 : begin
for i := 0 to High(Player) do
if not Player[i].IsDead then
inc(Player[i].Wins);
BomberManGame.StartNewMatch(Map.FileName);
end;
end;
[...]</pascal>

Mit der Schleife in diesem Codekonstrukt prüfen wir (neben dem Aktualisieren der Spieler, siehe dazu das Kapitel zum Objekt TPlayer) wie viele Spieler noch lebendig sind, erhöhen bei einem überlebendem Spieler dessen Punktzahl bzw und starten das Spiel neu. Ein Neustart des Spiels geschieht natürlich auch wenn alle Spieler tot sind, dann gibts aber natürlich keine Punkte.

Soviel also zur wichtigsten Zeichenroutine. Hier dürftet ihr eigentlich keine Probleme gehabt haben, aber dennoch wars mir wichtig einige Dinge anzuschneiden.

=====Zeichnen des Hauptmenüs (TBomberManGame.DrawScene_GSMainMenu)=====
Auch in dieser Zeichenprozedur gibts ein paar Besonderheiten die eventuell einer Erklärung bedürfen, weshalb wir uns auch diesen Quellcode vornehmen.

<pascal>[...]
const
EntryName : array[0..2] of String = ('Neues Spiel', 'Credits', 'Spiel beenden');
EntryPos : array[0..2] of Single = (160,240,320);
[...]</pascal>

Statt die Menüeinträge und deren Bildschirmposition zu "hardcoden" (also für jeden Menüeintrag eine eigene Textausgabe) ists weitaus praktischer die Menüeinträge sowie deren Positionen (in unserem Falle nur die auf der Y-Achse) am Anfang der Zeichenprozedur in einem Konstantenarray vorzubelegen, so dass wir diese später einfach in einer Schleife zeichnen können.

<pascal>[...]
TextureManager.BindTexture('gamewindow');
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glColor4f(1,1,1,0.7);
glBegin(GL_QUADS);
glTexCoord2f(0,1); glVertex3f(224, 112, 0);
glTexCoord2f(1,1); glVertex3f(416, 112, 0);
glTexCoord2f(1,0); glVertex3f(416, 368, 0);
glTexCoord2f(0,0); glVertex3f(224, 368, 0);
glEnd;
[...]</pascal>

Nachdem wir in den 2D-Modus gewechselt haben, binden wir die Textur für unser Hauptmenü, aktivieren Alphamasking um die Ränder der Textur loszuwerden und aktivieren auch noch Blending, damit die im Hintergrund rotierende Karte durch das Menü hindurch sichtbar ist.
Danach müssen wir nur noch ein zentriertes Quad mit den Ausmaßen der Textur auf den Bildschirm bringen und schon ist unser Menühintergrund sichtbar.

<pascal>[...]
for i := Low(EntryName) to High(EntryName) do
if i = gsMainMenu_Selected then
TextureFont.Print2D(EntryName[i], [230,EntryPos[i],0],[1,0.3,0.3],1,1)
else
TextureFont.Print2D(EntryName[i], [230,EntryPos[i],0],[1,1,1],1,1);
[...]</pascal>

Diese Schleife gibt dann unsere vorher definierten Menüpunkte an den im Array '''EntryPos''' festgelegten Bildschirmpositionen aus. Falls der Eintrag markiert ist, wird er rot hervorgehoben.

=====Zeichnen der Spielfiguren (TPlayer.Draw)=====

<pascal>[...]
glTranslatef(Position.x+0.5, Position.y, Position.z+0.5);
glRotatef(Direction, 0, 1, 0);
[...]</pascal>

Mit diesen beiden Zeilen werden wir zum einen das 3D-Modell des Spielers zentrieren, und des zum anderen in die aktuelle Blickrichtung ausrichten.

<pascal>[...]
glPushMatrix;
if IsDead then
begin
glTranslatef(0,0,-0.5);
glRotatef(90,1,0,0);
end;
glScalef(0.0085, 0.0085, 0.0085);
Draw3DSModel(Model3DS);
glPopMatrix;
[...]</pascal>

Nun kommt der interessante Teil dieser Prozedur. Natürlich sichern wir zuerst unsere Matrix, um sie später wieder schnell herstellen zu können. Dann prüfen wir ob der Spieler tot ist. Ist dies der Fall, so "legen" wir die Spielfigur mit einer Translation und Rotation auf die Stelle an der der Spieler gestorben ist.

Die dann folgende Skalierung ist deshalb so "überdimensioniert", da die Maßeinheiten im 3D-Studio relativ groß sind, und auf unsere Maßeinheit angepasst werden müssen.

Letztendlich rufen wir noch mit Hilfe der Prozedur '''Draw3DSModel''' die vom 3D-Modell des Spielers generierte Displayliste auf. Mehr dazu gibts in der Dokumentation zur '''BombermanLoad3DS.pas'''.

<pascal>[...]
glColor3f(1,1,1);
glDisable(GL_LIGHTING);
glDepthFunc(GL_LEQUAL);
glEnable(GL_BLEND);
glBlendFunc(GL_ZERO, GL_SRC_COLOR);
[...]</pascal>

Kommen wir nun zur "Schattendarstellung". Dieses Wort steht mit Absicht in Anführungszeichen, da es keine realistischen Schatten sind, sondern einfache mittels Blending auf den Boden gezeichnete "schwarze Kreise", die den Eindruck eines grade nach unten geworfenen Schattens entstehen lassen.Dies ist jedoch für den Anfang ausreichend und auf jeden Fall besser als gar keine Schatten.Eventuell werden wir uns im nächsten Tutorial mit echten Schattenwürfen beschäftigen.
Die Schattentextur wurde übrigens auf recht einfache Art und Weise mit Hilfe des Farbverlauftools in einem Bildbearbeitungsprogramm erstellt. Links seht ihr die Schattentextur, und rechts das Endergebnis im Spiel :

[[Bild:Tutorial Bomberman2 shadowtex.jpg]][[Bild:Tutorial Bomberman2 shadowplayer.jpg]]

Obige Zeilen dienen also erstmal der Intialisierung. Hier wird nichts weiter getan als den Tiefentest so einzustellen, das der Schatten auf jeden Fall gezeichnet wird, und das Blending wird aktiviert.Außerdem setzen wir noch einen additiven Blendingmodus.

<pascal>[...]
TextureManager.BindTexture('shadow_player.tga');
glBegin(GL_QUADS);
glTexCoord2f(0,1); glVertex3f(-0.5, 0.01, -0.5);
glTexCoord2f(1,1); glVertex3f( 0.5, 0.01, -0.5);
glTexCoord2f(1,0); glVertex3f( 0.5, 0.01, 0.5);
glTexCoord2f(0,0); glVertex3f(-0.5, 0.01, 0.5);
glEnd;
[...]</pascal>

Diese Zeilen dürften selbsterklärend sein. Nach dem Binden unserer Schattentextur zeichnen wir unter die Spielerposition noch ggü. dem Boden leicht erhöht das Schattenquad. Die minimale Erhöhung auf der Z-Achse dient dazu das sog. Z-Fighting zu verhindern, bei dem es je nach Kameraentfernung durch die Ungenauigkeit des Z-Puffers zum Überlappen von Poylgonen kommen kann.

Auch in der Zeichenprozedur unserer Spielfiguren eigentlich nur Standardkost. Die Zeichenprozedur für unsere Bomben sieht genauso aus, weshalb ich diese nicht besprechen werden.

=====Verarbeiten der Benutzereingaben (TPlayer.ProcessInput)=====
Auch wenn diese Prozedur schon kurz angesprochen wurde, werde ich hier nochmal auf die Besonderheiten eingehen, da wir die Benutzereingaben nicht wie die meisten von euch mittels der entsprechenden '''OnKeyDown/OnKeyUp/OnKeyPress'''-Ereignisse der Form, sondern direkt auf Hardwareebene abfragen. Allerdings reicht es wenn wir hier exemplarisch nur eine Tastenabfrage besprechen.

<pascal>[...]
if Hi(GetAsyncKeyState(KeyUp)) = 128 then
begin
[...]</pascal>

Wie schon angesprochen prüft die Funktion '''GetAsyncKeyState''' auf Hardwareebene ob die übergebene Taste bzw. der übergebene Mausbutton (was in unserem Falle ohne Interesse ist) gedrückt sind. Ist dies der Fall, so liefert uns diese Funktion im höchstwertigen Bit (also das Bit das ganz links "sitzt") eine 1. Mit der Delphifunktion ''Hi'' lassen wir uns also das höherwertige Byte (nicht Bit!) liefern und bekommen als Ergebnis ein Oktett (in dem sich die linken 8 Bits einer 16Bittigen Integervariable befinden). Das Bitmuster von 128 ist ja bekannterweise 1000 0000 und euch sollte sofort aufgefallen sein das bei diesem Bitmuster das von uns gesuchte höchstwertige Bit gesetzt ist .Ein kleiner Vergleich liefert uns nun also TRUE, falls diese Taste gedrückt ist. Das hat sich jetzt wahrscheinlich mächtig kompliziert angehört, war aber mehr als kleine Verständnishilfe Gedacht, und muß nicht unbedingt bekannt sein.

<pascal>[...]
if IsPositionValid(Position.x, Position.z-0.05*BomberManGame.TimeFactor*Speed-Size/2) then
Position.z := Position.z-0.05*BomberManGame.TimeFactor*Speed;
[...]</pascal>

Nun kommen wir zum Kern der Sache.Zuerst prüfen wir im If-Statement, ob die Position an die sich der Spieler bewegen will auch gültig ist. '''Nur wenn dies der Fall ist, wird die Spielerposition auch gesetzt.''' Ansonsten ändert sich nichts an seiner Position.

===BombermanSoundSystem.pas===

Wenn euch das vorherige Kapitel nicht erschlagen hat, dann habt ihrs jetzt eigentlich geschafft, denn das Schwerste liegt hinter euch. Als nächstes werden wir uns dann dem weitaus weniger komplexem Soundsystem widmen.

Kommen wir zuerst zur Typendeklaration :

====Das SoundSystem (TSoundSystem)====

;<nowiki>SampleHandle : array of PFSOUNDSample;</nowiki> : Wie in der Dokumentation zu FMOD nachzulesen (die ihr euch unbedingt ansehen solltet) greift diese Bibliothek auf seine Sounds (ähnlich wie Windows auf seiner Fenster) über Handles zu, die wir in diesem dynamischen Array ablegen werden.
;<nowiki>SampleList : TStringList;</nowiki> : Hier legen wir die Namen der in obigem array abgelegten Sounds zwecks schnellen Zugriffs ab.
;<nowiki>constructor Create;</nowiki> : Naja, der Konstuktor eben.Hier tun wir eigentlich nix anderes als FMOD zu initialiseren.
;<nowiki>destructor Destroy;</nowiki> : Hier passiert genau das Gegenteil ;-).
;<nowiki>procedure AddSample(pFileName, pSampleName : String);</nowiki> : Fügt unserem Samplepool das in der Datei pFileName abgelegte Soundfile unter dem Namen pSampleName hinzu.
;<nowiki>procedure PlaySample(pSampleName : String;pLoop : Boolean);</nowiki> : Sucht das Soundsample mit dem Name pSampleName und spielt dies ab.Per pLoop kann man angeben ob es kontinuierlich wiederholt wird.

====Interessante Codestellen====

In unserem momentan noch recht simplen Soundsystem gibts eigentlich nur recht wenige Interessante Codestellen. Fangen wir aber troztdem an, und schauen uns die Initialsierung der FMOD-Library in Konstruktor '''Create''' an :

<pascal>[...]
FSOUND_Init(44100, 32, 0);
[...]</pascal>

Simpel, nicht wahr =). Als Parameter müssen wir der FMOD-Library zur Initialisierung nur die Mixrate (44,1kHz) und die Anzahl der Soundkanäle übergeben (in unserem Falle 32).

Das wars schon mit der Initialisierung. Gehen wir also gleich über zum Abspielen eines Sounds in '''PlaySample''' :

<pascal>[...]
Index := SampleList.IndexOf(pSampleName);
[...]
Channel := FSOUND_PlaySound(FSOUND_FREE, SampleHandle[Index]);
[...]</pascal>

Das Abspielen von Sounds unter FMOD geschieht immer auf einem Kanal, den das Sample von FMOD zugeteilt bekommt. Die Zuteilung dieses Parameters geschieht entweder fest oder dynamisch durch FMOD, indem der Parameter FSOUND_FREE angegeben wird.
Als zweiter Parameter wird noch das Handle des Samples übergeben, dessen Index wir vorher über die StringList ermittelt haben.

<pascal>[...]
if pLoop then
FSOUND_SetLoopMode(Channel, FSOUND_LOOP_NORMAL);
[...]</pascal>

Mit diesen beiden Zeilen setzten wir (falls dies gewünscht wird) den Kanal auf dem das Sample abgespielt wird in den Loopmodus, so daß der Sound kontinuierlich wiederholt wird.

So, daß war eigentlich alles Wissenswerte zu unserem einfachen Soundsystem. Mehr Infos gibts in der Doku zu FMOD.

===BombermanLoad3DS.pas===
Nachdem wir nun eigentlich alle relevanten Stellen und Deklarationen unseres Quellcodes abgeklappert haben gibts noch ein paar Worte zur 3DS-Ladeunit. Das Groß des dort enthaltenen Quelltextes stammt nicht von mir, sondern aus dem Beispiel-3DS-Lader zu Mike Lischkes 3DS-Library.

Meine Arbeit an dieser Unit "beschränkt" sich auf das einfache Laden und Zeichnen der 3DS-Modelle, weshalb ich hier auch nur kurz auf die dafür von mir gebastelte Klasse und Routine eingehe.

====Kapselung des 3DS-Models (TModel3DS)====
Diese Klasse kapselt das 3DS-Model und bietet mit der Routine '''LoadFromFile''' eine einfache Möglichkeit dies in eine OpenGL-Displayliste zu konvertieren. Die 3D-Modelle werden im dynamischen array '''List3DS''', und ihre Namen (zum schnellen Zugriff) in '''Names3DS''' verwaltet.

;<nowiki>ListIndex : TGLUInt;</nowiki> : Index der OpenGL-Displayliste dieses 3D-Modells.
;<nowiki>Name : String;</nowiki> : Der Dateiname.
;<nowiki>procedure LoadFromFile(pFileName : String);</nowiki> : Lädt das 3DS-Model aus der in ''pFileName'' angegebenen Datei und erstellt eine DisplayListe, deren Kennung in ''ListIndex'' abgelegt wird.

====Aufrufen der DisplayListe (Draw3DSModel)====
Mit Hilfe dieser Prozedur kann man die DisplayListe eines vorher bereits geladenen 3D-Models bequem über dessen Namen zeichnen.

==Schlusswort==

BOOOOOM...ich hoffe dieser Knall holt euch wieder zurück in die harte Realität. Ich weiß, dieses Tut war ein harter Brocken, aber wenn ihr alles hier angesprochene begriffen habt, habt ihr ne Menge dazugelernt und solltet von nun an wissen wie man die Programmierung eines Spiels angeht, und welche Techniken man dabei nutzt.

Wenn ihr dieses Tut dann endgültig verdaut habt, wäre ich über Feedback sehr erfreut. Denn das lässt leider (nicht nur bei meinen Tuts) zu wünschen übrig...'''aber diesmal hängt der Umfang des nächsten Tuts, in dem wir unseren Bombermanklon um einige tolle Effekte und Funktionen erweitern von eurem Feedback ab!''' Also gebts mir, und am besten im Forum, so das Alle was davon haben!

Euer
:'''Sascha Willems'''

{{TUTORIAL_NAVIGATION|[[Tutorial_Bomberman1]]|[[Tutorial_Softwareentwicklung1]]}}

[[Kategorie:Tutorial|Bomberman2]]

Tutorial glsl

2007-05-24T22:20:27Z

Sascha Willems: /* Die Zukunft */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 einfach Shader zu schreiben und auch in ihren Programmen zu nutzen. Ausserdem soll dieses Dokument gleichzeitig als ein deutsches "Pendant" zu den von 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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 Orginal Spezifikation])
: 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 Orginal Spezifikation])
: Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.
* [[GL_ARB_Fragment_Shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt Orginal Spezifikation])
: 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 Orginal Spezifikation])
: Gibt die unterstützte Version von glSlang an, momentan 1.00.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} ganze Matrizen schnell und einfach übergeben. Ausserdem 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :'''<br>
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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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 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 Integervektor
|-
|ivec3
|3-Komponenten Integervektor
|-
|ivec4
|4-Komponenten Integervektor
|-
|mat2
|2x2 Fließkommamatrix
|-
|mat3
|3x3 Fließkommamatrix
|-
|mat4
|4x4 Fließkommamatrix
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 aussen 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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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<br>Funktionsaufrufe und Konstruktoren<br>Strukturfeldwahl und Swizzle<br>Postinkrement und -dekrement<br>
|[]<br>()<br>.<br>++ --
|Links n. Rechts
|-
|Prefixinkrement- und dekrement<br>Einheitlich (~ reserviert)
| ++ --<br> + - ~ !
|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<br>Arithmetrische Zuweisung<br>(Modulis, Shift und bitweise Op. reserviert)
|<nowiki>=</nowiki><br> <nowiki>+= -= *= /= %=</nowiki> <br> <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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

Funktionen die ''nichts zurückgeben'' müssen mit dem RückgabeTyp {{INLINE_CODE|void}} deklariert werden, ausserdem entfällt dann logischerweise das {{INLINE_CODE|return}}. Falls die Funktion eines ihrere Argumente nach aussen ü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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

Diese Funktion gibt ''nichts'' zurück, aber gibt EingabeWert*MyConstValue im Ausgabeargument AusgabeWert nach aussen.
<glsl>
float MeineFunktion(float EingabeWert)
{
return EingabeWert*MyConstValue;
}
</glsl>

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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 angle)
: Gibt den Sinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType cos (genType angle)
: Gibt den Cosinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType tan (genType angle)
: Gibt den Tangens von Angle zurück, wobei Angle 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 Arccosinus 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.

==Exponentiell==
* genType pow (genType x, genType y)
: Gibt x hoch y 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 floor (genType x)
: Gibt denn nächsten Integerwert zurück, der kleiner oder gleich x ist.
* genType ceil (genType x)
: Gibt den nächsten 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. (=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.
* 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. (= 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 <= edge und 1.0 wenn x >= edge. Dabei wird eine weiche Hermite Interpolation zwischen 0 und 1 durchgeführt.

==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 I, genType N)
: Gibt den an der Flächenausrichtung N reflektierten Vektor I zurück. (=I-2 * dot(N,I) * 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.

==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)

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'' :
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
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'' :
<glsl>
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</glsl>
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.

===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 :
<glsl>
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
<glsl>
uniform vec4 GlobalColor;

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

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.
Ausserdem 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==
<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;
}
</glsl>

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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 Bomberman1

2007-05-24T22:20:05Z

Sascha Willems: /* Schlusswort */

[[Bild:Bomberman.gif|left]]
=Wir programmieren einen Bombermanklon! <br> <br> Teil 1 : Die Codebasis und der Editor=

==Vorwort==

Ave, und willkommen zu meinem zweiten Tutorial, dem Anfang einer Tutorialserie!

Neben Tetris gehört ''Bomberman'' wohl zu einem der erfolgreichsten Spielkonzepte der Videospielgeschichte, wurde es doch auf fast jede Plattform und dazu noch in diversen Varianten (es existieren über 30 Bombermanspiele) umgesetzt. Der Erfolg dieses Spielkonzepts liegt (wie auch bei Tetris) in seinem recht einfachen, aber dennoch fesselndem Spielprinzip in dem es darum geht die Mitspieler durch geschicktes Platzieren von Bomben aus den Rennen zu werfen und als letzter auf dem Spielfeld zu stehen. (Mehr Infos zum Thema Bomberman gibts u.a. hier : [http://www.bomberman.info http://www.bomberman.info])

<div align="center">
[[Bild:Bomberman nes 1985.jpg|NES (1985)]][[Bild:Bomberman snes 1993.jpg|MegaDrive (1993)]][[Bild:Bomberman neogeo 1997.jpg|NeoGeo (1997)]]
</div>

Und gerade wegen der Einfachheit dieses Spielprinzips ist ein Bombermanklon gradezu prädestiniert um als Grundlage für eine kleine Tutorialserie zum Thema Spieleprogrammierung zu dienen. Während Anfängern ein recht einfacher Einstieg in die Spieleprogrammierung geboten wird, bietet es fortgeschritteneren Programmierern sehr viel Freiraum zur Weiterentwicklung.
In dieser mehrteiligen Serie werde ich von Anfang an und auf auch für Einsteiger (für die die Tutorials auch gedacht sind) geeignete Art und Weise zeigen wie man einen Bombermanklon und den dazugehörenden Editor von Grund auf programmiert.

In diesem ersten Teil der Serie werden wir die vom Editor und dem Spiel verwendete Codebasis erstellen und widmen uns dann später im dem Editor und seinen Eigenheiten.

Am Ende wird der geneigte Leser einen vollständen Karteneditor zum Erstellen einfacher Bombermankarten fertiggestellt haben, mit dessen Hilfe wir dann die Karten für den im zweiten Tutorial entwickelten Bombermanklons erstellen können.

Realisiert wird das Ganze natürlich in Delphi und OpenGL. Später wird dann noch FMOD als Soundlibrary zu den beiden stoßen.

==Voraussetzungen==

Was ich in diesem Tutorial allerdings nicht erklären werde, und was natürlich benötigt wird, sind zum einen '''Kenntnisse in Object Pascal''' (dazu gibts nicht nur sehr viele gute Tuts, sondern v.a. auch die Anleitung zu Delphi bzw. dessen Hilfedatei), und '''grundlegende OpenGL-Kenntnisse''' zu Themen wie Rotation und Bewegung, Zeichnen von geometrischen Objekten und Texturemapping. Zu diesen Themen gibts hier auf DGL ja jede Menge guter Tutorials.
Wer mit diesen Voraussetzungen ausgestattet ist, der sollte in dieser Tutorialserie auf keine Problem stoßen und kann sich schonmal auf einen brauchbaren Bombermanklon freuen, den er im Anschluß dann fleißig verbessern und erweitern kann.

==Das Ziel==

Am Ende dieser Tutorialserie wird ein ausgewachsener 3D-Bombermanklon mit diversen Spezieleffekten wie Alphamasking, Partikelsystemen, fulminanten Explosionen und Soundausgabe stehen, der sich vor seinen Vorbildern nicht zu verstecken braucht.
Und praktisch nebenbei (oder vornedran ;-)) wird dann noch ein leistungsstarker Editor mit einem einfach zu nutzenden Dateiformat entwickelt, mit dessen Hilfe in Windeseile neue Karten erstellt werden können.
Ziel dieser Tutorialserie ist nicht unbedingt der perfekte Bombermanklon, sondern es geht mir eher darum den Einsteigern unter den Leser neben einem guten Programmierstil auch noch wichtige Grundlagen für die Entwicklung eines Spiels mitzugeben. Denn was bei einem kleinen Projekt schon nützlich ist, kann sich bei einem großen Projekt schnell als große Hilfe erweisen.

Eventuell (hängt zum großen Teil auch vom Feedback der Leser ab) werde ich sogar noch ein Tutorial hinterherschieben, das unseren Klon noch im Mehrspielerfähigkeiten mittels LAN erweitert.

Viel Spaß also beim Bombenlegen...[[Bild:Bomberman anim.gif]]

==Die Codebasis==

Wie die Überschrift es schon erahnen lässt, widmen wir uns zu allererst der Codebasis. Die Codebasis nennt sich deshalb so, weil sie grundlegende Funktionen und Klassen zur Verfügung stellt die sowohl vom Editor als später auch vom Spiel genutzt werden. Bezeichnen kann man das natürlich auch als Engine, doch dieser Begriff ist in meinen Augen falsch, da ich unter Engine ein viel komplexeres Grundgerüst verstehe, als dies bei einem Bombermanklon benötigt wird.

Diese Codebasis besteht zu Beginn nur aus einigen wenigen Dingen, wird aber im Verlaufe der Tutorialserie ständig erweitert und ist Dreh- und Angelpunkt unseres Bombermanklons.
In diesem Tut stellt unsere Codebasis (die sich in der Datei '''global.pas''' befindet) folgende Objekte zur Verfügung :

===Einen Texturenmanager (TTextureManager)===
Viele von euch werden ihre Texturen bisher wohl auf einfache Art und Weise über ein (meist dynamisches) {{INLINE_CODE|array of glUInt}} "verwaltet" haben, und haben dann beim Programmstart alle Texturen per Hand in dieses array eingelesen haben. Nicht nur das dass Laden der Texturen auf diese Art und Weise recht umständlich war und bei jeder neuen Textur der Quellcode geändert werden musste, nein auch der Zugriff auf die Texturen beim Zeichnen der Szene war umständlich und geschah auf die Weise {{INLINE_CODE|[[glBindTexture]](GL_TEXTURE_2D, Textur[3])}}. Dadurch war man immer gezwungen, sich zu vergewissern dass Textur Nr.3 auch die richtige Textur war.

Bei unserem Bombermanklon wollen wir diesen Fehler nicht machen, und haben auch nicht vor bei jeder neuen Textur den Quellcode ändern zu müssen. Das ist nicht nur für den Programmierer selbst komfortabler, sondern auch für die Spieler, die die Karten mit eigenen Texturen verschönern wollen.

Deshalb schreiben wir uns einen kleinen aber sehr nützlichen Texturenmanager, mit dessen Hilfe wir alle Texturen in einem Verzeichnis zur Laufzeit in den Texturenpool laden können, und der Texturen nicht anhand ihrer Position im array bindet, sondern auf diese mit einer Stringlist über deren Namen zugreift. So wird z.b. aus dem {{INLINE_CODE|glBindTexture(GL_TEXTURE_2D, Textur[3])}} ein einfaches und leichter durchschaubares {{INLINE_CODE|TextureManager.BindTexture('steinwand1.tga')}}.

Um uns nicht mit dem Laden verschiedener Formate herumschlagen zu müssen, benutzen wir zum Umwandeln der Texturen die '''glBMP-Bibliothek''' von [http://delphigl.cfxweb.net http://delphigl.cfxweb.net] in einer von mir um einige nützliche Dinge erweiterten Variante (ist im Download zu diesem Tutorial natürlich enthalten).

Unser Texturmanager besteht aus folgenden Prozeduren und Variablen:

*Texture : array of TglBMP
:In diesem dynamischen array werden alle geladenen Texturen abgelegt.

*TextureName : THashedStringList
:In dieser StringList werden die Texturennamen abgelegt, über die der Texturenmanager später die Texturen im {{INLINE_CODE|Texturearray}} addressiert. Hier wird statt einer herkömmlichen {{INLINE_CODE|TStringList}} eine {{INLINE_CODE|THashedStringList}} verwendet, da diese bei häufigen Suchvorgängen (was bei vielen Texturenwechseln der Fall ist) und besonders bei großen Datenmengen schneller als die herkömmliche {{INLINE_CODE|TStringList}} ist.
:'''Hinweis für Nutzer von Delphiversionen < 6:'''
:In diesen Delphiversionen existiert der Typ {{INLINE_CODE|THashedStringList}} nicht. Dadruch seid ihr gezwungen doch eine normale {{INLINE_CODE|TStringList}} zu verwenden.

*constructor Create
:Erstellt und initialisiert den Texturenmanager.

*destructor Destroy
:Deinitialisiert und entfernt den Texturenmanager aus dem Speicher.

*procedure AddTexturesInDir(pDirName, pFileMask : String)
:Fügt dem Texturenpool alle im Verzeichnis {{INLINE_CODE|pDirName}} liegenden Texturen mit der in {{INLINE_CODE|pFileMask}} angegebenen Endung hinzu.

*procedure AddTexture(pFileName, pTextureName : String)
:Fügt dem Texturenpool die aus der Datei {{INLINE_CODE|pFileName}} geladene Textur unter dem Namen {{INLINE_CODE|pTextureName}} hinzu.

*procedure BindTexture(pTextureName : String)
:Sucht die Textur mit dem Namen {{INLINE_CODE|pTextureName}} im Texturenpool und bindet diese an das {{INLINE_CODE|GL_TEXTURE_2D}}-Ziel. Wurde die Textur nicht gefunden, wird für das Texturemapping deaktiviert.

Wie man also sehen kann steckt hinter einem Texturenmanager nicht sonderlich viel Arbeit, er erleichtert einem das Leben allerdings erheblich. Besonders wenn man später Dinge wie Alphamasking einbringen will, muss man nicht mehr umständlich im Zeichencode rumwühlen, sondern man muss einfach nur noch die {{INLINE_CODE|BindTexture}}-Routine ein wenig abändern. Alles in allem also ein nützliches Hilfsmittel das in keinem OpenGL-Projekt fehlen sollte.

===Das Spielfeld (TMap)===
Der nächste Baustein unserer Codebasis repräsentiert das Spielfeld auf dem die Aktion stattfindet. Viel zu bieten hat diese Klasse momentan, ausser einer Zeichenprozedur und einige Editorprozeduren noch nicht viel, was sich aber in naher Zukunft noch ändern wird.

Hier also Prozeduren und Variablen des Spielfelds :

*PlayGround : array of array of TFieldType
:Diese Variable repräsentiert das eigentliche Spielfeld und ist ein zweidimensionales array vom Typ {{INLINE_CODE|TFieldType}}, dessen Definition die Eigenschaften eines Spielfelds festlegt und so aussieht :
<pascal>TFieldType = record
Texture : String;
FType : Byte;
FSpecial : Byte;
end;</pascal>
:{{INLINE_CODE|Textur}} steht für den Namen der diesem Feld zugewiesenen Textur, während {{INLINE_CODE|FType}} angibt ob es sich um ein Bodenteil, einen festen Block oder einen zerstörbaren Block handelt. Natürlich ist diese Variable frei erweiterbar (was später auch noch ausgiebig getan wird), und man könnte hier quasi unendlich viele Feldtypen mit den tollsten Eigenschaften (z.B. bewegliche Blöcke) definieren. {{INLINE_CODE|FSpecial}} gibt letztendlich noch an, ob dieses Feld noch eine besondere Eigenschaft, wie z.B. einen Spielerstart enthält.

*DefaultFieldTexture : String
:In dieser Variable wird die Standardtextur festgelegt, die einem Feld zugewiesen wird, nachdem ein darauf befindlicher sprengbarer Block zerstört wurde.

*procedure SetSize(pSize : Integer)
:Legt die in {{INLINE_CODE|pSize}} angegebene Spielfeldgröße fest, und tut nichts anderes als das dynamisches {{INLINE_CODE|PlayGround}}-array in seiner Größe mittels {{INLINE_CODE|SetLength}} zu verändern.

*procedure FillBorder(pTexture : String;pFieldType : Integer)
:Füllt den Rand des Spielfelds mit der in {{INLINE_CODE|pTexture}} angegebenen Textur und dem in {{INLINE_CODE|pFieldType}} angegebenen Feldtyp.

*procedure FillGround(pTexture : String;pFieldType : Integer)
:Füllt das Spielfeld (exklusive dem Rand) mit der in {{INLINE_CODE|pTexture}} angegebenen Textur und dem in {{INLINE_CODE|pFieldType}} angegebenen Feldtyp

*procedure Draw;
:Wie der Prozedurenname bereits erahnen lässt, wird in dieser Prozedur das komplette Spielfeld gezeichnet. Diese Prozedur spielt daher also ein Hauptrolle in unserem Bombermanprojekt.
:Da in der Grundversion unseres Editors nichts weiter getan wird, als die Felder in einer {{INLINE_CODE|for..do}}-Schleife zu zeichnen, bedarf der Quellcode wohl kaum detaillierter Beschreibungen. Eine Zeile dürfte den Anfänger in der Leserschaft jedoch etwas unbekannt vorkommen, weshalb ich diese hier etwas detaillierter erkläre :
:*glLoadName(OpenGLID)
::Mit dieser Zeile legen wir einen "Namen" (Eine Variable vom Typ Cardinal, und nicht etwa wie der leicht irreführende Titel Name zu vermuten lässte einen String) auf den {{INLINE_CODE|NameStack}} von OpenGL, der dann dem nächsten gezeichneten geometrischen Objekt zugewiesen wird. Damit wird dann jedem Feld ein einzigartiger OpenGL-Name zugewiesen.
::Mit Hilfe dieses OpenGL-Namens kann man dann später mit einer {{INLINE_CODE|[[Selection]]}} genannten Methode herausfinden auf welches Feld der Mauszeiger gerade zeigt. Benötigt wird das Ganze natürlich nur für den Editor. Wie genau dieses Selektionsverfahren realisiert wird, dazu gibts später im Editorkapitel mehr.

*procedure SaveToFile(pFileName : String)
:Diese Prozedur sichert die Karte in die mit {{INLINE_CODE|pFileName}} angegebene Datei. Dabei wird ein einfach zu lesendes und leicht erweiterbares ASCII-Format verwendet :
Dateiversion
Größe Der Karte
Name der Standardtextur
Textur von Feld [1,0]
FeldTyp von Feld [1,0]
SpezialInfo von Feld [1,0]
.
.
.
Textur von Feld [Größe Der Karte-1,Größe Der Karte-1]
FeldTyp von Feld [Größe Der Karte-1,Größe Der Karte-1]
SpezialInfo von Feld [Größe Der Karte-1,Größe Der Karte-1]
:Ein binäres Format hätte hier natürlich den Vorteil, das zum einen der Platzbedarf geringer wäre, und es zum anderen auch vor Veränderungen sicher wäre, allerdings wären die alten Karten nach jeder Änderung unbrauchbar.Für ein reines ASCII-Format kann man sich jedoch schnell mal einen Importer schreiben, der ältere Karten in eine neuere Version konvertiert.

*procedure LoadFromFile(pFileName : String)
:Lädt die Karte aus der in {{INLINE_CODE|pFileName}} angegebene Datei.

Soviel also zu unserer aktuellen Codebasis, die als Grundlage für unseren Editor sowie das Spiel an sich dienen wird. Bis jetzt war ja noch nichts spektakuläres dabei, und selbst die unerfahreneren unter euch sollten bis hierhin keine Probleme gehabt haben.
Der größte Teil unserer zukünftigen Änderungen werden an der Codebasis stattfinden und vor allem das Kartenobjekt betreffen. Natürlich werden später noch neue Klassen u.a. zur Spielerverwaltung (und evtl. Gegnerverwaltung) hinzukommen, dazu aber mehr in den folgenden Tutorials.

Doch wenden wir uns jetzt dem Editor zu... [[Bild:Bomberman happy.gif]]

==Der Editor==

Ein Spiel ist ja bekannterweise nur so gut wie sein Inhalt, der mit Hilfe der entwickelten Tools wie einem Leveleditor erstellt wird. Was nützen die tollsten und modernsten Features oder die ausgeglügelste künstliche Intelligenz, wenn die Level in denen man sich bewegt einfach mies sind...deshalb sollte man sich bei der Entwicklung eines Spiels immer auf seine Tools konzentrieren, und diese so intuitiv und gleichzeitig leistungsfähig wie möglich gestalten, damit man später schnell und einfach guten Gamecontent erstellen kann.

Zum Glück ist diese Thematik bei einem Bombermanklon nicht so brisant wie bei einem Egoshooter á la Doom3, dessen Editor sich vor 3DStudio MAX nicht zu verstecken braucht, aber trotzdem geht einem der Levelbau viel leichter von der Hand wenn man einen einfach zu nutzenden Mapeditor zur Hand hat, statt die Karten für die erste Betaversion seines Spiels mittels Notepad zusammenzubasteln.

In diesem Kapitel werden wir uns deshalb um einen leicht zu bedienenden Editor kümmern, der grundlegende Fähigkeiten zum Erstellen der Karten und einige brauchbare Tools mitbringt.

Natürlich wird der Editor mittels der Delphi-VCL realisiert, ist sie doch schliesslich dass was Delphi so groß gemacht hat, und die Entwicklungszeit von Windowsanwendungen signifikant verringert.

[[Bild:Bomberman editor1.jpg|center]]

Wie auf obigem Screenshot zu erkennen basiert die Grundversion unseres Editors auf zwei Fenstern. Im linken Fenster wird das Spielfeld dargestellt, und im rechten befinden sich zum einen Einstellungen bezüglich des zu setztenden Feldes und einige Tools die dem Kartenbauer das Leben erleichtern.

Der Quellcode des Editors bietet ansich nichts unbekanntes und dürfte recht leicht verständlich sein. Dennoch werde ich einige relevante Codestellen erläutern :

===OpenGL initialisieren (TForm1.FormCreate)===
Der Einfachheit halber verwende ich in unserem Bombermanprojekt die {{INLINE_CODE|OpenGL12.pas}} von [http://www.lischke-online.de/ Mike Lischke] in einer minimal abgeänderten Form (betrifft nur das Erstellen des Rendercontext), die dem Projektquellcode natürlich beiliegt.

Diese macht das erstellen eines Rendercontextes zu einem Kinderspiel :

<pascal>DC := GetDC(Handle);
RC := CreateRenderingContext(DC, [opDoubleBuffered], 32, 24, 8, 0, 0, 0, DummyPal);</pascal>

In der ersten Zeile erstellen wir uns vom Handle unseres Fensters einen gültigen DeviceContext vom Typ {{INLINE_CODE|HDC}}, der dann genutzt wird um den OpenGL-Rendercontext zu erstellen.

In der zweiten Zeile erstellen wir einen OpenGL-Context mit Doublebuffering, 32Bit Farbtiefe, 24bittigem Tiefenpuffer und einem 8Bit großen Stencilpuffer, mit dessen Hilfe wir in einem späteren Tutorial Schattenwürfe realisieren werden. Die {{INLINE_CODE|DummyPal}}-Variable ist wie ihr Name schon sagt nur ein Dummy, der nicht benötigt wird, da unser Rendercontext keinen Palettenmodus (256 Farben) nutzt.

Einige Zeilen später werden wir dann einige OpenGL-Werte initialisieren :

<pascal>glEnable(GL_TEXTURE_2D);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LESS);
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);</pascal>

Die Funktion dieser Zeilen dürfte bekannt sein : Zeile 1 aktiviert zweidimensionales Texturemapping, die Zeilen 2 und 3 legen den Tiefentest fest (aktiviert, und nur Fragmente die weiter vorne liegen durchlassen). Zeile 4 sagt der Grafikkarte dann noch, das sie die best aussehendste Perspektivenkorrektur verwenden soll.

Danach laden wir noch die benötigten Texturen :

<pascal>TextureManager.AddTexturesInDir('textures', '*.tga');
for i := 0 to TextureManager.TextureName.Count-1 do
Form2.TextureCombo.Items.Add(TextureManager.TextureName[i]);
ChDir(ExtractFilePath(Application.ExeName));

SetLength(SpecialTex, Length(SpecialTexName));
for i := Low(SpecialTexName) to High(SpecialTexName) do
begin
SpecialTex[i] := TglBMP.Create('textures\special\'+SpecialTexName[i]);
SpecialTex[i].GenTexture(False, False);
end;</pascal>

Im ersten Block sagen wir dem Texturenmanager das er alle TGA-Dateien im Unterordner {{INLINE_CODE|textures}} in den Texturenpool laden soll. Ich verwende das TGA-Format deshalb, da es eines der wenigen Formate (neben PNG) ist, das einen Alphakanal unterstützt. Mehr zu diesem Alphakanal und seiner Anwendung gibts ineinem späteren Tutorial (Kleiner Hinweis : Alphamasking). Gleichzeitig fügen wir noch alle Texturennamen in die ComboBox im Toolfenster ein, damit wir diese später bequem zuweisen können.

Im zweiten Block laden wir die in der Konstantensektion festgelegten Spezialtexturen die später z.B. genutzt werden um die Startpunkte der Spieler zu kennzeichnen.

Ich hoffe ihr seit nach diesem etwas langweiligen und nicht besonders anspruchsvollem Ausflug in die Initialisierung des Editors noch wach, denn jetzt kommt etwas schwierigeres...[[Bild:Bomberman wait.gif]]

===Spielfelder mittels des Mauszeigers auswählen (aka Selection)===
Im Kapitel zur Codebasis hab ich dieses Thema schonmal kurz angeschnitten und euch gezeigt, wie man ein Objekt mittels des Namestacks unter OpenGL "bekannt" macht. Wer mehr zum Thema Selection erfahren will, kann sich ja das Tutorial dazu auf meiner Hompage durchlesen : [http://www.delphigl.de/tutorials/selection_de.html Selection-Tutorial]. (Oder das [[Tutorial_Selection]] hier im Wiki)

Nun stelle ich euch eine (recht kurze, aber knackige) Prozedur vor, die prüft ob und wenn ja, welches dieser auf dem Namestack befindlichen Objekte unter dem Mauszeiger ist. Gemeint ist die Funktion '''GetSelectBufferHit''', die ich euch hier häppchenweise erläutern werde :

<pascal>var
SelectBuffer : array[0..512] of TGLUInt;
Viewport : TVector4i;
Hits,i : Integer;
HitZValue : TGLUInt;
Hit : TGLUInt;</pascal>

Die Variablendeklaration dieser Funktion bedarf erstmal einer fundierten Erklärung : Im {{INLINE_CODE|SelectBuffer}}-array werden alle Objekttreffer gespeichert. Jeder Objekttreffer besteht aus vier Werten : Anzahl der Objekte auf dem Namestack zum Zeitpunkt des Treffers, kleinste Z-Koordinate aller Eckpunkte des Objektes, größte Z-Koordinate aller Eckpunkte des Objektes und Name des getroffenen Objektes. Deshalb kann unser SelectBuffer bis zu 128 (512/4) Objekttreffer beinhalten.
In der Variable Viewport wird der aktuelle OpenGL-Viewport gespeichert, den wir später noch brauchen werden.
Und mit den Variablen {{INLINE_CODE|Hits, HitZValue}} und {{INLINE_CODE|Hit}} stellen wir am Ende der Funktion in einer Schleife fest welches Objekt nun letztendlich unter dem Mauszeiger liegt.

Kommen wir nun zur eigentlichen Funktion und der in ihr enthaltenen erwähnenswerten Codezeilen :

<pascal>glGetIntegerv(GL_VIEWPORT, @viewport);</pascal>

Mittels dieser Zeile speichern wir den aktuellen Viewport in die vorher dafür definierte Variable.

<pascal>glSelectBuffer(512, @SelectBuffer);</pascal>

Hiermit teilen wir OpenGL zum einen die Größe des SelectBuffers und zum anderen dessen Adresse im Speicher mit.

<pascal>glRenderMode(GL_SELECT);</pascal>

Jetzt schalten wir in den SelectModus, in dem nichts auf den Bildschirm gerendert wird, aber unser SelectBuffer gefüllt wird.

<pascal>glInitNames;
glPushName(0);</pascal>

Diese zwei Zeilen sind unabdingbar, denn sie dienen dazu den Namestack zu initialisieren.

<pascal>glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluPickMatrix(MousePos.x, viewport[3]-MousePos.y, 3.0, 3.0, Viewport);
gluPerspective(45.0, Form1.ClientWidth/Form1.ClientHeight, 0.1, 2048);
Form1.DrawScene;</pascal>

Dieser Teil ist sehr wichtig. Hier setzen wir die Ansichtsmatrix so, das (wenn wir im normalen Rendermodus wären) nur der Bereich im 3 Pixel Umkreis um die Mausposition herum gerendert werden würde. Dies dient dazu das nur Objekte im direkten Umkreis der Mausposition in den Selectbuffer gerendert werden.

<pascal>Hits := glRenderMode(GL_RENDER);
Hit := High(TGLUInt);
HitZValue := High(TGLUInt);</pascal>

Die erste Zeile schaltet jetzt wieder in den normalen Rendermodus. Allerdings liefert uns OpenGL jetzt (da wir uns vorher im Selectmodus befanden) die Anzahl der getroffenen Objekte zurück. Die zwei nachfolgenden Zeilen initialisieren die Variablen vor, mit deren Hilfe wir später herausfinden welches Objekt dem Mauszeiger am nächsten liegt.

<pascal>for i := 0 to Hits-1 do
if SelectBuffer[(i*4)+1] < HitZValue then
begin
Hit := SelectBuffer[(i*4)+3];
HitZValue := SelectBuffer[(i*4)+1];
end;
Result := Hit;</pascal>

Mittels der Schleife prüfen wir ob die Z-Koordinaten des neuen Objektes niedriger als die bereits gespeicherte ist (wir erinnern uns : in {{INLINE_CODE|SelectBuffer[(n*4)+1]}} steht die kleinste Z-Koordinate der Eckpunkte dieses Objekts, sprich der dem Betrachter nächste Z-Wert). Wenn dies der Fall ist, übernehmen wir dessen Z-Koordinaten in {{INLINE_CODE|HitZValue}} und dessen Namen in {{INLINE_CODE|Hit}}.
Am Ende dieser Schleife haben wir dann endlich das Objekt, welches der Kamera am nächsten ist und geben dies im Resultat der Funktion zurück.

Wenns dir jetzt besser geht als unserem kleine Bomberman, dann hast du das Schlimmste bereits überstanden, bei Nichtverstehen nochmal das von mir erwähnte Tut durchlesen...

===Zeichnen der Szene (TForm1.ApplicationEvents1Idle)===
Bekannterweise gibt es ja jede Menge Möglichkeiten und Stellen an denen man seine Szene zeichnen könnte. Entweder man schreibt sich nen eigenen Loop mittels {{INLINE_CODE|repeat..until}}, machts mit einem Timer (ist übrigens eine sehr schlechte Lösung) oder nimmt ganz einfach den {{INLINE_CODE|OnIdle}}-Event der Form, der über die {{INLINE_CODE|ApplicationEvents}}-Komponente (siehe Komponenten-Tab "Zusätzlich") zur Vefügung gestellt wird.
Dieses Ereignis wird eigentlich nicht periodisch aufgerufen, sondern immer nur nach der Abarbeitung einer Fensternachricht. Allerdings kann man dies mit einem kleinen Trick umgehen :

<pascal>Done := False;</pascal>

Wenn diese Zeile im {{INLINE_CODE|OnIdle}}-Ereignis aufgerufen wird, verschweigt man Windows ganz einfach das die Anwendung die Nachrichtenschleife durchlaufen hat. Als Folge dessen wird diese Routine permanent durchlaufen, und das OpenGL-Programm hat fast die komplette CPU-Zeit zum Zeichnen der Szene.
Weitere interessante Zeilen im {{INLINE_CODE|OnIdle}}-Ereignis sind folgende :

<pascal>DrawScene;
SBufferHit := GetSelectBufferHit;</pascal>

Nachdem in der ersten Zeile die Szene gezeichnet wurde, wird der Variable {{INLINE_CODE|SBufferHit}} die Kennung des unter der Maus befindlichen Feldes zugeweisen, so dass man dieses Feld dann in der Zeichneroutine der Karte farblich hervorheben kann.

<pascal>if MouseLeft then
if Assigned(SelField) then
begin
SelField^.Texture := Form2.TextureCombo.Items[Form2.TextureCombo.ItemIndex];
SelField^.FType := Form2.FieldTypeCombo.ItemIndex;
end;</pascal>

Dieser Codehappen weist dem ausgewählten Feld ({{INLINE_CODE|SelField <nowiki>=</nowiki> @TFieldType}}) bei gedrückter linker Maustaste die im Toolfenster ausgewählte Textur und den ausgewählten Feldtyp zu. Ist kein Feld unter dem Cursor ({{INLINE_CODE|SelField <nowiki>=</nowiki> nil}}) dann geschieht nichts, da {{INLINE_CODE|Assigned()}} diesen Fall abfängt.

So, geschafft!Das war alles Wichtige zum Quellcode des Editors.Der Rest des Codes ist recht einfach und aufgrund der Dokumentation und ausgiebieger Kommentare im Quelltext dürfte er auch keine Probleme machen... [[Bild:Bomberman cheer.gif]]

Abschliessend gibts noch ein paar Worte zur Bedienung des Editors :

:Im 3D-Fenster :
::Cursortasten : Auf dem Spielfeld scrollen
::Mausrad : Rein- bzw. rauszoomen
::Bild rauf/Bild runter : Kamerawinkel verändern
::Linke Maustaste : Feld unter dem Mauscursor mit der Textur und dem in Form2 gewählten Feldtyp belegen
::Rechte Maustaste : Kontextmenü mit Spezialfeldern aufrufen
::+/- : Spielfeld rotieren

==Schlusswort==

Das wars fürs Erste, und ich hoffe das Tutorial hat euch gefallen. Weiterhin hoffe ich natürlich das ihr meiner Tutorialserie bis zum Ende treu bleibt und mich mit Feedback (am besten direkt ins Forum) überschüttert. Anregungen und Kritik (solange konstruktiv) sehe ich nämlich gerne und motivieren mich auch...
Außerdem interessieren mich eure Modifikationen zum Editor und eure Levelkonstrukte, postet also fleissig Neuerungen, Verbesserungen und gebastelte Level ins Forum, und '''freut euch auf den zweiten Teil der Tutorialreihe!!!'''

Euer
:'''Sascha Willems'''

<br><br>
{{TUTORIAL_NAVIGATION| - | [[Tutorial_Bomberman2]]}}

[[Kategorie:Tutorial|Bomberman1]]

Tutorial Modellierung eines Low-Poly Menschen Teil 2

2007-05-24T22:19:37Z

Sascha Willems: /* Nachwort */

==Ave!==

Und willkommen zum Nachfolger meines ersten Low-Poly-Tutorials.Nachdem wir in diesem gelernt haben aus möglichst wenigen Dreiecken eine menschliche Figur zu modellieren,beschäftigen wir uns nun mit der Texturierung eben dieses Polygoniers.

Wie bekannt tragen gerade die Texturen sehr viel zum Aussehen eines 3D-Modelles bei und können leicht zum simulieren von Details genutzt werden,ohne das dadurch die Anzahl der genutzten Polygone steigt.

In diesem Tutorial werden wir unseren fertigen Polygonhelden also mit '''einer''' selbstgemachten Textur versehen.Wenn ihr aufmerksam ward,dann habt ihr sicher bemerkt das ich im lezten Satz "einer" betont habe.Das hat auch einen Grund,denn wir belegen nicht jeden Mesh unserer Figur mit einer eigenen Textur,sondern nutzen nur eine einzige Textur für alle Meshes des Modelles.Diese eine Textur wird im Fachjargon auch "Skin" genannt und hat im Groben zwei Vorteile ggü. der Nutzung mehrere Texturen.Texturenwechsel (via glBindTexture) sind ja bekannterweise recht zeitintensiv und können bei häufigem Autreften schonmal nen Flaschenhals darstellen.Durch die Nutzung einer einzigen Textur für das komplette Modell sparen wir also ganz einfach diverse Texturenwechsel und machen der GPU das Leben leichter.Ein weiterer,vielleicht sogar besserer Grund für die Nutzung eines einzigen Skins für unser Modell ist die Tatsache das man anhand eines einfachen Texturenwechsel innerhalb seines Spiels das komplette Aussehen des 3D-Helden darüber verändern kann.Diese Technik findet auch in professionellen Spielen (u.a. UT2003) häufig Anwendung,und ein gutes Beispiel ist z.B. ein 2.WK-Shooter.Statt ein Modell für einen Wehrmachtssoldaten und eins für einen allierten Soldaten zu erstellen (und damit zwei Modelle im Speicher zu halten) wird nur ein Grundmodell erstellt,dessen Zugehörigkeit oder Spezialfähigkeit (z.B. Mediziner) dann über sein Skin sichtbar ist.

==Voraussetzungen==

Für dieses Tutorial benötigt ihr unbedingt einen 3D-Modeller der euch einen visuellen Editor zum Verändern der UVW-Koordinaten auf Vertexbasis und einen UVW-Unwrap-Modifikator anbietet,da ihr sonst Probleme haben werdet das im Tutorial gemachte nachzuvollziehen.
Ansonsten solltet ihr wie im ersten Tutorial zumindest grundlegende Kenntnisse in Sachen 3D-Modellierung und Nutzung eurer 3D-Software mitbringen.

In Sachen Bildbearbeitungssoftware ist eigentlich alles erlaubt und ich habe zum Erstellen der Textur auch "nur" Picture Publisher 9 gentutzt,welches bei meinem Webspacepaket dabei war.Photoshop,PaintShop Pro oder Gimp (kostenlos) sollten also auch ausreichen.

==Erstellen der Textur==

Beginnen wollen wir also mit dem Erstellen der Textur die unsere Figur später schmücken soll.Da wir für das komplette Modell nur eine Textur verwenden,sollten wir uns erstmal Gedanken um die Einteilung eben dieser machen und dafür sorgen das alle Meshes Platz darauf haben.Unser Polygonmensch besteht aus zwei Armen,zwei Beinen,einem Becken,dem Rumpf,einem Hals und seinem Kopf.Aufgrund der Symetrie des Körpers können wir übrigens die beiden Arme und Beine auf jeweils auf ein Exemplar beschränken.Summa Sumarum sind das also 6 Körperteile,wobei man einige davon aus den anderen heraus texturieren könnte.Für das Tutorial erstelle ich nämlich einen uniformierten Soldaten,der deshalb an Beinen und Armen (bis auf Hände und Stiefel) gleich texturiert werden kann,also brauche ich keine extra Textur für das Beinkleid.Genausowenig braucht der Hals eine eigene Textur,da sich in der Textur für den Kopf garantiert genug Haut findet um sie über den Hals zu legen.

Im Endeffekt bräuchten wir jetzt also nur noch Platz für vier Körperteile auf unserer Textur (Arm,Rumpf,Becken,Kopf).Allerdings sollte man sich auch vor dem Erstellen eben dieser Überlegen,ob man nicht doch noch irgendwelche Stellen besonders behandeln will.Ist dies der Fall,sollte man das natürlich beim Einteilen des Platzes mitberücksichtigen.So hat mein Soldat auf den Schultern noch ein paar Abzeichen,also kann ich für diese nicht einfach die Textur des Rumpfes nutzen.Aber diese Besonderheiten sind abhängig von dem was ihr machen wollt,also müsst ihr euch da auch selbst was einfallen lassen.

Da sich eine solche Einteilung recht schlecht in Schrift und Wort erklären lässt,zeige ich euch mal wie ich das bei meinem Soldaten mit der Texturunterteilung gehandhabt habe.Folgend seht ihr die farblich eingeteilten Bereiche :

[[Bild:Tutorial_Low-Poly-Mensch2_skin1_col2.jpg]]

Ich hoffe mal das diese Einteilung zumindest halbwegs nachvollziehbar erscheint,und rate euch sowas auch zuerst mit farbigen Blöcken durchzuspielen,bevor ihr beim Basteln der Textur plötlich merkt das kein Platz mehr für ein bestimmtes Körperteil da ist und wieder von vorne anfangen müsst.
Im Bezug auf die Texturengröße gibts auch keinen allgemeingültigen Rat,denn diese hängt von mehreren Faktoren ab.Zum einen wie nahe der Spieler dem Modell je kommt,wie detailliert das Modell an sich ist und wie viele Details ihr gerne über die Textur realisieren wollt.Ich habe für mein Modell ganz einfach eine 256x256 Pixel große Textur genommen,damit ich hier und da ein Detail einbringen kann.

Da es nicht Gegenstand dieses Tutorials ist euch das Erstellen einer Textur beizubringen,überlasse ich euch mal euren Bildbearbeitungskünsten (Kleiner Tipp falls ihr v.a. Details für die Textur sucht : Die google Bildsuche hilft ungemein) und präsentiere euch direkt meine fertige Textur (etwas verkleinert) :

[[Bild:Tutorial_Low-Poly-Mensch2_skin1_prev.jpg]]

Das sollte bei euch zumindest ähnlich aussehen und wenn nicht,dann nehmt halt die Farbtextur und nutzt diese zum Texturieren des Modelles.Der Rest kann ja später noch gemacht werden.

==UVW-Mapping==

Da wir jetzt sowohl eine fertige Textur (oder etwa nicht?) sowie ein fertiges 3D-Modell haben,wollen wir diese natürlich auch gerne zusammenführen.Dazu machen wir uns die Möglichkeit zu Nutze,das ein halbwegs brauchbares 3D-Modellierungsprogramm in der Lage ist die UVW-Koordinaten für jedes Vertex zu verändern.Wers noch nicht weis : UVW sind die Texturkoordinaten eines Vertexes und werden in OpenGL allgemein auch als STQ referenziert,wobei uns die letzte Koordinate (W) nichts angeht.

[[Bild:Tutorial_Low-Poly-Mensch2_01.jpg|right]]Wir laden also unser im letzten Tut gebasteltes 3D-Modell und holen uns (sofern möglich) den perspektivischen Viewport auf den kompletten Schirm.Nun öffnen wir den Materialeditor (Shortcut m) und laden in die Diffuse-Map des ersten Materials unsere Textur zu,bevor wir diese dann dem kompletten Modell zuweisen.Ausserdem sollte natürlich "Map im Viewport zeigen" aktiv sein,da wir unsere Textur später sonst nicht sehen.Momentan sehen wir natürlich noch nicht viel von der Textur,da kein einziger Mesh UVW-Koordinaten besitzt.

Anfangen wollen wir mit dem Arm und nutzen ein nettes Feature von 3DSMax um diesen einzeln bearbeiten zu können,nämliches das Isolationstool.Dazu selektieren wir den Arm und drücken '''ALT+Q''' (oder im Hauptmenü über den Eintrag Tools->Selektion isolieren) und schon wird der Rest des Models ausgeblendet,während ein kleines Fenster erscheint das uns über den Isolationsmodus informiert.
Dem Arm,allein auf dem Schirm und noch selektiert,weisen wir jetzt aus der Modifikatorliste den '''Unwrap UVW'''-Modifikator zu (befindet sich recht weit unten),der auch automatisch UVW-Koordinaten für den selektieren Mesh erstellt,die wie zu sehen allerdings keinesfalls brauchbar sind.

[[Bild:Tutorial_Low-Poly-Mensch2_02.jpg|right]]Als nächstes wollen wir uns endlich ins UVW-Mappen stürzen.Dabei gehen wir beim Arm Seite-für-Seite vor,und selektieren deshalb alle Faces der Vorderseite.Dazu öffnen wir den UVW-Unwarp-Modifikator des Arms und klicken auf "Face selektieren",bevor wir dann im Viewport alle Faces der Vorderseite des Armes selektieren (Um mehrere Objekte zu selektieren STRG gedrückt halten).Wenn ihr das gemacht habt,dann sollte eure perspektivische Ansicht in etwa so aussehen :

[[Bild:Tutorial_Low-Poly-Mensch2_03.jpg]]

Nun öffnen wir durch einen Klick auf '''"Bearbeiten..."''' in den Eigenschaften des UVW-Modifikators den UVW-Editor,der danach ungefähr so auf eurem Bildschirm erscheinen sollte :

[[Bild:Tutorial_Low-Poly-Mensch2_04.jpg]]

Was euch evtl. direkt auffällt (und den ein oder anderen evtl. auch schon ein paar nerven gekostet hat),ist die Tatsache das dort wo eure Textur sein sollte nur ein schwarzes Quadrat ist.Das liegt ganz einfach daran das dass 3DStudio die Textur aus einem mir unerklärlichen Grund mit einer Helligkeit von 0 anzeigt.Wollt ihr also was von eurer zugewiesenen Textur sehen,dann öffnet mit bem Button ganz unten rechts (Show options) eine kleine Zusatzleiste am unteren Fensterrand und setzt die Helligkeit dort auf 1.Ausserdem solltet ihr auch den Haken vor "Bitmap wiederholen" (Tile Bitmap) entfernen.
Nun sind wir also endlich bereit unserem Arm die passenden UVs zuzuordnen.Ein kleiner Tipp für die Produktivität : Wenn ihr eure Fenster so anordnet wie ich (links UVW-Editor und das zu editierende Objekt rechts daneben),dann lässt sich nicht nur bequem arbeiten,sondern die Änderungen im UVW-Editor auch in Echtzeit auf dem Modell verfolgen :

[[Bild:Tutorial_Low-Poly-Mensch2_05.jpg]]

[[Bild:Tutorial_Low-Poly-Mensch2_06.jpg|right]]Immernoch die Frontfaces unseres Armes selektiert klicken wir in den Eigenschaften des Modifikators jetzt also auf '''Planar Map''' um die Texturkoordinaten der gewählten Vertexe auf die Textur zu projezieren.Bei den Frontfaces wird die Notwendigkeit dieser Aktion noch nicht so recht sichtbar,aber spätestens bei den Seiten des Armes wird euch dies klar werden.Ausserdem aktivieren wir "Filter selected Faces",damit nur die gewählten Faces im UVW-Editor sichtbar sind.Habt ihr dieses Prozedere korrekt nachvollzogen,dann sollte euer UVW-Editor in etwa so aussehen :

[[Bild:Tutorial_Low-Poly-Mensch2_07.jpg]]

Nun sehen wir ein korrektes Abbild unserer Armgeometrie auf der Textur,allerdings passen die Texturkoordinaten noch absolut nicht.Wir schnappen uns also die Vertices des Armes und verschieben diese so,das sie den Bereich einnehmen den wir auf unserer Textur für den Arm vorgesehen haben.Ich mach das übrigens lieber über die Eingabefelder,denn das blosse Verschieben mit der Maus ist nicht gerade genau.Danach sollte die Vorderseite des Armes so auf der Textur zugewiesen sein und wie rechts zu erkennen aussehen :

[[Bild:Tutorial_Low-Poly-Mensch2_08.jpg]] [[Bild:Tutorial_Low-Poly-Mensch2_09.jpg]]

Diese Prozedur müsst ihr jetzt natürlich für alle vier Seiten des Armes,sowie die Unterseite der "Hand" anwenden.Wer dann auch noch mitgedacht hat,wird sich nicht blindlinks auf den zweiten Arm stürzen,sondern diesen durch eine Kopie unseres bereits UVW-Gemappten Armes ersetzen.

Weiter gehts jetzt mit dem Torso unseres Polygonators.Nachdem wir diesen angewählt haben,gehen wir wieder in den Isolationsmodus und selektieren wie gewohnt alle Frontfaces.Allerdings werden wir jetzt direkt sehen dass das Mapping (welches momentan auf "Averaged Normals" steht) nicht "korrekt" ist,denn das gelbe Mappingquadrat steht schief (siehe Links).Um das zu korrigieren (damit die Frontfaces des Torsos auch auf der Textur richtig liegen) wählen wir diesmal bei den Sub object Parametern "Z" und sofort sollte das Mappingquadrat in der richtigen Position liegen (siehe Rechts).Hier könnt ihr also je nach Bedarf mit den Optionen rumprobieren und sobald ihr die richtige Einstellung gefunden habt wieder auf '''Planar Map''' klicken :

[[Bild:Tutorial_Low-Poly-Mensch2_10.jpg]] [[Bild:Tutorial_Low-Poly-Mensch2_11.jpg]]

Auch diesmal skaliert und verschiebt ihr die Vertices der Vorderseite des Torus solange im UVW-Editor,bis diese alle im dafür vorgesehen Bereich der Textur liegen.Evtl. müsst ihr an einigen Stellen noch ein wenig rumschieben bis alles so aussieht wie es soll :

[[Bild:Tutorial_Low-Poly-Mensch2_12.jpg]] [[Bild:Tutorial_Low-Poly-Mensch2_13.jpg]]

Zur Texturierung der Rückseite bzw. der beiden anderen Seiten könnt ihr übrigens ganz einfach den Teil der Textur nutzen in dem keine Medallien abgelegt sind.Folgend seht ihr den gemappten Rücken (oben) und eine Seite (unten) :

[[Bild:Tutorial_Low-Poly-Mensch2_14.jpg]]

amit wären wir eigentlich auch schon am Ende des Tutorials angelangt.Euch jetzt noch bebildert zu erzählen wie die restlichen Körperteile texturiert werden würde,wäre in meinen Augen Schwachsinn.Die Grundlagen und evtl. auftretende Schwierigkeiten hab ich ja bereits angesprochen,und den Rest des Modells solltet ihr ohne Problem fertigtexturieren können.

==Nachwort==

Wenn ihr meinen Beschreibungen folgen konntet,dann sollte euer Polygonsoldatn nun in etwa so aussehen :

[[Bild:Tutorial_Low-Poly-Mensch2_15.jpg]]

Das ist doch die Mühe wert,oder?Zumal ihr nun behaupten könnt neben dem Modell auch noch die Textur für euer Modell komplett selbst erstellt zu haben.Ausserdem bietet sich euch jetzt durch die Nutzung eines einzigen Skins für unser Modell noch jede Menge Erweiterungsmöglichkeiten,von der andersfarbigen Uniform bis hin zu einer total anderen Bekleidung.

Wie immer hoffe ich,das euch dieses Tut so viel Spaß gemacht hat wir mir das Verfassen eben dieses und bin auf euer Feedback und eure Modellierergebnisse mehr als gespannt!

Sascha Willems

{{TUTORIAL_NAVIGATION| [[Tutorial Modellierung eines Low-Poly Menschen Teil 1]] | - }}

[[Kategorie:Tutorial|Modellierung eines Low-Poly Menschen Teil 2]]

Tutorial Modellierung eines Low-Poly Menschen Teil 1

2007-05-24T22:19:21Z

Sascha Willems: /* Nachwort */

==Ave!==

Und hallo zu meinem ersten Tutorial das direkt weder was mit Delphi noch was mit OpenGL zu tun hat.Hört sich zwar verwirrend an,aber im Endeffekt geht es diesmal um ein Thema mit dem sich jeder der ein 3D-Spiel entwickelt früher oder später einmal auseinandersetzen muss.

Es geht nämlich um das Erstellen eines 3D-Modelles,genauer gesagt um ein 3D-Modell mit einer geringen Polygonanzahl.Wie jeder der sich mit 3D-Grafiken in Echtzeit auseinander setzt weis,hängt die Geschwindigkeit einer 3D-Anwendung u.a. stark von der Anzahl der darzustellenden Polygone ab und selbst auf modernen Grafikkarten sollte man es damit nicht übertreiben.

Und genau deshalb beschäftigen wir uns in diesem Tutorial mit dem Erstellen eines menschlichen 3D-Modelles unter Nutzung möglichst weniger (genauer gesagt 360) Dreiecke.Für eine Hauptfigur in einem Egoshooter wäre das natürlich viel zu undetailliert,allerdings ziele ich eher auf ein Modell für ein Strategiespiel o.Ä. ab,bei denen sich oft hunderte von Einheiten gleichzeitig auf dem Bildschirm tummeln.Allerdings lässt sich die Polygonanzahl des Modells leicht erhöhen und den eigenen Bedürfnissen anpassen.Mir gehts in diesem Tutorial eher um die Grundlagen als um den endgültigen Polycount.

==Voraussetzungen==

In diesem Tutorial verwende ich 3DStudio MAX (wie zu sehen in einer englischen Version),aber eigentlich sollte es sich ohne größere Umstände auf alle 3D-Modellierer die nach einem ähnlichen Prinzip arbeiten und das Modifizieren auf Vertexebene ermöglichen,übertragbar sein.

Grundlegende Kenntnisse der genutzten 3D-Software sollten euch allerdings bekannt sein bevor ihr euch ins Tut stürzt.Damit meine ich solche Aktionen wie Markieren,Verschieben,Skalieren,Erstellen von Primitiven und das Verändern eines Viewports.

==Grundlagen==

Da sich menschliche Formen nur schlecht aus dem Gedächtnis mit ein paar Boxen modellieren lassen,brauchen wir natürlich eine Vorlage die einem Menschen ähnlich kommt.Da das Ganze auch noch 3D ist,vorzugsweise auch von zwei Seiten (Vorne und Links oder Rechts).Entschieden hab ich mich dann für die Grundlage eines jeden Menschen,nämlich ein Skelett.(zum vergrößern klicken)

[[Bild:Tutorial_Low-Poly-Mensch1_bones1.jpg|100px]] [[Bild:Tutorial_Low-Poly-Mensch1_bones2.jpg|100px]]

3DStudio MAX bietet uns jetzt die tolle Möglichkeit eben diese Vorlagen als Hintergrund für einen Viewport anzugeben.Wir beginnen mit dem Modellieren unserer Figur in der Frontansicht,und wählen deshalb auch diesen Viewport an.Nun wechseln wir in den Dialog der uns diesen Hintergrund festlegen lässt :

[[Bild:Tutorial_Low-Poly-Mensch1_01.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_02.jpg]]

In obigem Dialog wählen wir über "File" zuerst unser Hintergrundbild für den aktuell selektierten Viewport aus. Danach müssen wir den Aspekratio via "Match Bitmap" an das Bild anpassen,da es sonst verzerrt im Hintergrund angezeigt werden würde.Die Checkbox "Lock Zoom/Pan" muss auch aktiviert werden,damit das Bild beim Verschieben/Zoomen des Viewports auch angepasst wird.

Danach sollte eure Frontansicht ungefähr so aussehen (ich hab ihn mir auf den ganzen Schirm geholt und auch passen gezoomt bzw. verschoben) :

[[Bild:Tutorial_Low-Poly-Mensch1_03.jpg]]

===Der Brustkorb===

Nachdem wir nun unseren Viewport an unsere Bedürfnisse angepasst und mit einem Hintergrundbild ausgesttatet haben,auf dessen Basis wir unser Modell erstellen,können wir auch schon mit dem eigentlichen Modelliervorgang loslegen.

[[Bild:Tutorial_Low-Poly-Mensch1_04a.jpg|right]]Wie schon kurz angesprochen werden wir unsere Figur komplett aus '''Boxen''' erstellen. Also wählen wir die Boxprimitive aus und erstellen eine 3x3x1 unterteilte Box die ungefähr den Ausmassen des Skelettbrustkorbes entspricht, allerdings ein wenig größer ist, da ein Mensch ja bekannterweise noch Haut und Fleisch besitzt :

[[Bild:Tutorial_Low-Poly-Mensch1_04.jpg]]

[[Bild:Tutorial_Low-Poly-Mensch1_05.jpg|right]]Die Box kommt zwar vom Umfang her schonmal nah ran, allerdings passt die Form absolut nicht.Dazu gibts aber den "Mesh bearbeiten"(Edit Mesh)-Modifikator,den wir auch gleich auf die Box anwenden. Danach selektieren wir die Vertices '''immer''' so wie auf folgendem Screen zu sehen mit dem Auswahlrechteck :

[[Bild:Tutorial_Low-Poly-Mensch1_06.jpg]]

Das Auswahlrechteck deshalb,weil bei einem einfachen Klick auf das sichtbare Vertex nur dieses ausgewählt werden würde,und nicht auch wie beim Auswahlrechteck alle dahinterliegenden Vertices.Bitte behaltet euch diesen Satz das ganze Tut über im Hinterkopf,denn er ist '''wichtig!'''.

Nun selektiert und verschiebt ihr also die Vertices (Auswahlrechteck!) solange in der Vorderansicht,bis der Brustkorb in etwa dem des Skelettes entspricht.Das muss nicht 1:1 sein,man kann hier natürlich nach Lust und Laune variieren.Euer Ergebnis sollte nun in etwa so aussehen (rechts seht ihr das Ergebnis in der 3D-Ansicht) :

[[Bild:Tutorial_Low-Poly-Mensch1_07.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_08.jpg]]

Dank unserer Vorlage in Form des Skelettes sollte euch diese Aktion eigentlich recht leicht gefallen sein.Kleiner Hinweis falls ihr ein detaillierters Modell erstellen wollt : Die 3x3x1-unterteilte Box kann natürlich nach Belieben unterteilt und somit mit mehr Dreicken versehen werden,wodurch ihr leicht mehr Details ausarbeiten könnt!

===Die Arme===

Weiter gehts mit den Armen unseres Protagonisten.Da die Grundsätze des Modellierens der Körperteile (Vertexauswahl,Modifikatoranwendung) bereits im vorigen Kapitel beschrieben wurden,spar ich mir das jetzt und in den folgenden Absätzen und komme direkter auf den Punkt.

Wir erstellen also wieder eine Box,die ungefähr den Dimensionen des Armes entspricht.Diesmal allerdings 3x1x1 unterteilt (Oberarm,Unterarm,Hand).Diesmal verändern wir diese Box allerdings '''nicht''' entsprechend der Armposition,sondern so wie ein menschlicher Arm im Normalfall bei lässigem Stehen positioniert wäre :

[[Bild:Tutorial_Low-Poly-Mensch1_09.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_09a.jpg]]

[[Bild:Tutorial_Low-Poly-Mensch1_10.jpg|right]]Nun nutzen wir die Tatsache das ein menschlicher Körper symetrisch ist schamlos aus und erstellen den anderen Arm durch ein Spiegeln als Kopie :

[[Bild:Tutorial_Low-Poly-Mensch1_11.jpg]]

Anschliessend müssen wir den neu erstellten Arm nur noch an die passende Stelle auf der gegenüberliegenden Seite des Brustkorbs schieben.

===Das Becken===

Wer sich in Sachen Anatomie ein wenig auskennt (oder wer schonmal in den Spiegel geschaut hat),wird feststellen das es eine Verbindung zwischen Rumpf und den Beinen gibt,auch das Becken genannt.Rein theoretisch hätten wir diesen im selben Mesh wie den Rumpf modellieren können,aber für eine evtl. später folgende Animation unseres Recken ist ein seperater Mesh dafür besser geeignet.

Da das Prozedere dem der Erstellung des Brustkorbes wie ein Ei dem anderen gleicht,gibts hier nur die Screencaps von der Box und dem fertigen Rumpf.Einziger Unterschied zum Brustkorb ist natürlich die Form und die Tatsache das man einen Übergang zu eben diesem im Becken schaffen sollte,sowie Ansätze für die gleich folgenden Beine :

[[Bild:Tutorial_Low-Poly-Mensch1_12.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_13.jpg]]

Kurzer Tipp für Polygonsparer : Hier würde eigentlich auch eine 2x2x1-unterteilte Box reichen (28 Polygone weniger),die dann allerdings natürlich nicht so organisch aussähe.

===Die Beine===

Damit sich unser Polygonheld auch etwas besitzt auf das er sich in seiner virtuellen Umgebung stützen kann,geben wir ihm auch zwei Beine mit (dank der Symetrie müssen wir allerdings nur eines modellieren).Wie auch schon bei den Armen erstellen wir wieder eine 3x1x1-unterteilte Box die in etwa die Beine unseres Viewporthintergrunds umschliesst und passen diese Box dann anhand des Skeletts in ihren Unterteilungen an.Danach bringen wir das Bein noch in eine natürlichere Position :

[[Bild:Tutorial_Low-Poly-Mensch1_14.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_15.jpg]]

Ist unser Bein fertiggestellt,so wird dieses wieder als eine Kopie gespiegelt um anschliessend an die passende Position geschoben zu werden.Beim "basteln" der Beine solltet ihr übrigens drauf achten,das die Stelle an der diese aus dem Becken treten auch recht "flüssig" überläuft um einen natürlichen Eindruck zu gewährleisten.Solltet ihr das zumindest halbwegs hinbekommen haben,dann dürfte euer Modell in der 3D-Ansicht in etwa so aussehen :

[[Bild:Tutorial_Low-Poly-Mensch1_16.jpg]]

===Der Hals===

Dem Hals müssen wir besonders bei einem Modell mit so wenigen Polygonen kaum Beachtung schenken,tut er doch nichts weiter als den Rumpf und den Kopf zu verbinden.Wir verwenden eine einfache 2x1x1 Box die etwas höher als breit ist :

[[Bild:Tutorial_Low-Poly-Mensch1_17.jpg]]

===Der Kopf===

Der Kopf gillt allgemein hin als das wichtigste Körperteil des modernen Menschen,wird er doch manchmal zum Denken genutzt.Bei uns nimmt er auch eine "wichtige" Funktion ein,denn er ist der einzige Mesh den wir auch in die Tiefe hinein unterteilen (dazu gleich mehr).Wir erstellen also eine 3x3x3-unterteilte Box die in etwa den kompletten Schädel umschliesst.Auch diese passen wir wie gewohnt den Gegebenheiten des zugrundeliegenden Körperteils an,machen sie allerdings ein wenig runder (und damit organischer) als dies beim Schädel der Fall ist.Natürlich könnt ihr euch beim Kopf freien Lauf lassen und evtl. noch Hörner oder sonstige Accessoirs wie Haare,Helme oder Hüte direkt in den Kopf miteinbringen.Solche Details wie Augenhöhlen,Nase oder Mund können wir bei einem Low-Poly-Model natürlich nicht über die Geometrie einbinden,sondern müssen später über eine Textur realisiert werden :

[[Bild:Tutorial_Low-Poly-Mensch1_21.jpg]]

Was natürlich sofort auffällt ist die Flachheit unseres Avatars.Da wir allerdings in 3 Dimensionen sehen und leben,werden wir uns diesem Problem natürlich auch sofot annehmen.

==Die 3.Dimension==

Wie bereits gesagt,ist unser Modell zwar schon menschlich geformt,würde so aber in keiner 3D-Anwendung ne gute Figur machen.Begeben wir uns nun also in die 3.Dimension.Dazu aktivieren wir die linke Seitenansicht und laden dort als Hintergrund dann die Datei bones2.jpg.Mit großer Wahrscheinlichkeit wird euch jetzt allerdings genau dasselbe passieren wie mir : Das Hintergrundbild passt größen- und positionstechnisch nicht zu unserem 3D-Modell.Das macht aber nichts,denn da wir in der Frontansicht fertig sind werden wir unsere Figur komplett markieren und solange skalieren bzw. verschieben bis sie in etwa auf unser neues Hintergrundbild passt.Eure linke Seitenansicht sollte nun in etwa so aussehen :

[[Bild:Tutorial_Low-Poly-Mensch1_22.jpg]]

===Der Brustkorb===

Besonders bei diversen Filmschauspielern und Superhelden ist es gerade der markante Brustkorb der ihnen das gewisse etwas verleiht.Das soll bei unserem Polygonier auch so sein,weshalb wir den Brustkorb jetzt leicht in die nach vorne und leicht nach hinten verbreitern.Das sollte dann in etwa so aussehen,und wie rechts zu sehen macht sich der Effekt auch gleich bemerkbar.Wer sich übrigens beim "Brustkorb" an die Skelettvorlage gehalten hat,der hat einen netten Durschnittspolygonier gebastelt :

[[Bild:Tutorial_Low-Poly-Mensch1_23.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_24.jpg]]

===Der Kopf===

Auch dem Kopf sollten wir eine natürliche Form in allen 3 Dimensionen verpassen.Diesmal müssen wir allerdings auch kurz mal in die von-oben Ansicht wechseln,um die äusseren Ecken des Kopfes ein wenig nach Innen zu ziehen.Das ist deshalb nötig,da unser Polygonprolet sonst ein leicht eingedelltes und damit recht befremdliches Gesicht (und auch Hinterkopf) hätte.In Pixel ausgedrückt sollte das im Endeffekt so aussehen und in der 3D-Ansicht ist gut zu erkennen was ein paar verschobene Vertices so ausmachen können :

[[Bild:Tutorial_Low-Poly-Mensch1_25.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_26.jpg]] [[Bild:Tutorial_Low-Poly-Mensch1_27.jpg]]

===Die Beine===

Auch die Beine (und v.a. der Fuß) unseres Modelles sollten leicht in die 3.Dimension transportiert werden um es realistischer erscheinen zu lassen.Zu diesem Zeck knicken wir das Bein dort wo eigentlich die Kniekehle ist ein wenig nach vorne und ziehen die vorne und ganz unten sitzenden Vertices recht weit nach vorne um einen Fuß zu bilden.Natürlich müsst ihr das nicht an beiden Beinen machen.Vor dem Bearbeiten solltet ihr deshalb ein Bein entfernen und das bearbeitet nach dem Ende dieser Aktion wieder als gespiegelte Kopie verschieben :

[[Bild:Tutorial_Low-Poly-Mensch1_28.jpg]]

==Nachwort==

Da steht er nun (mehr oder weniger ähnliche),unser 360 Polygone leichter Paul Pixel und er wartet nur darauf in irgendeinem Spiel in die virtuelle Schlacht geschickt zu werden :

[[Bild:Tutorial_Low-Poly-Mensch1_28.jpg]]

Was ihm natürlich noch fehlt ist ein passende Textur.Dazu wirds in Zukunft bei brauchbarem Feedback dann auch evtl. ein Tutorial geben,aber bis dahin könnt ihr euch ja schonmal selbst daran verdingen.

Ich hoffe mit diesem Tutorial übrigens eine kleine Lücke geschlossen zu haben,welche teamintern schon besprochen wurde : Content.Denn viele haben zwar die programmiertechnischen Voraussetzungen um ein Spiel zu programmieren,aber beim Erstellen des Inhalts (v.a. 3D-Modelle) haperts oft.Ich hoffe deshalb dass durch dieses Tutorial nun einige von euch in der Lage sind eigene Figuren zu erstellen.Deshalb gibts allerdings auch kein fertiges 3D-Modell zum Download.Um den Lerneffekt dieses Tutorials zu verstärken müsst ihr diesmal vom Anfang bis zum Ende durchhalten!

Sascha Willems

{{TUTORIAL_NAVIGATION| - | [[Tutorial Modellierung eines Low-Poly Menschen Teil 2]]}}

[[Kategorie:Tutorial|Modellierung eines Low-Poly Menschen Teil 1]]

DGL Projekte

2007-05-02T10:00:40Z

Sascha Willems: Links zu meinen Projekte aktualisiert

=DGL Projects Corner=

<div align="center">
Willkommen in der '''[[DelphiGL|DGL]] Projekte Ecke'''!
[[Bild:ProjekteEcke.jpg|center]]
Auf dieser Seite findet ihr Projekte von '''Mitgliedern von [http://DelphiGL.com DelphiGL.com]''' welche als '''abgeschlossen''' gewertet wurden.
</div>

==Spiele==
Viele, um nicht zu sagen die meisten, DGL-Mitglieder widmen sich dem Thema Spiele. Was dabei an respektablen Ergebnissen entstanden ist könnt ihr in dieser Rubrik sehen.

===3D Shooter und Labyrinth Spiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|''Noch keine Programme''
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!
|''Hier könnte dein Name stehen''
|}

===Action===

{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Thumb_asteroids.jpg|framed|center|Link: '''[[Projekt_Asteroids|Asteroids]]''']]

|Asteroids ist ein Remake des alten Klassikers "Comet". Ziel des Spiels ist es so viel Asteroiden wie möglich zu zerstören um dadurch möglichst viele Punkte zusammeln, ohne dabei von den herum fliegenden Trümmern getroffen zu werden.

An einem Spiel können bis zu 4 Spieler gleichzeitig teilnehmen.

|align="center"|[[Benutzer:Magellan|Magellan]]
|-
|-
|[[Bild:Thumb_napalmbomber.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=90 Napalmbomber3D Projektseite]''']]

|NapalmBomber3D ist wie der Titel schon vermuten lässt ein 3D-Klon des bekannten Bombermanspielprinzips.Dieses hochbrisante und fesselnde Spiel besticht durch seine tolle Grafik die natürlich mittels OpenGL realisiert wurde.

Zusätzlich zum Spiel gibt es natürlich auch noch einen Karteneditor mit dem sich in Windeseile eigenen Maps erstellen lassen.

Neben inzwischen über 50.000 Downloads (im Schnitt sind es immernoch > 400 pro Monat) und diversen sehr guten Reviews hat es das Spiel sogar auf die PC-Action Ausgabe 07/2004 geschafft.

|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]
|-
|}

===Brett-, Denk- und Kartenspiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Projekt_Hex_Change_Screenshot.jpg|thumb|center|168px|Link: '''[[Projekt_Hex-Change|Hex-Change]]''']]
|2 Spieler konkurrieren um die Felder auf einer Hexagon Fläche. Das Spiel enthält einen Einzelspieler- (gegen KI) und einen "Hot-Seat"-Mehrspielermodus.
|align="center"|[[Benutzer:H.A.S.E.|H.A.S.E.]]
|}

===Reaktions- und Geschicklichkeitsspiele===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:Thumb_confusingball.jpg|framed|center|Link: '''[[Projekt_ConfusingBall|Confusing Ball]]''']]

|In "Confusing Ball" steuert man einen Ball durch ein 3D Labyrinth, in dem die Gesetze der Physik neu definiert werden müssen. Um ins Ziel eines Levels zu gelangen benötigt man einen gewissen Orientierungssinn und ein gutes räumliches Vorstellungsvermögen.
Nebenher muss man ja auch noch die Münzen einsammeln, und den Bomben aus dem Weg gehen. Frei verschiebbare Steine erhöhen den Schwierigkeitsgrad.

|align="center"|[[Benutzer:MatReno|MatReno]]
|-
|[[Bild:Thumb_beanmachine.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=86 Bean Machine Projektseite]''']]

|"Bean Machine" basiert auf dem Sega MegaDrive-Klassiker "Dr.Robotnik's Mean Bean Machine" (ausserhalb Europas auch als "Puyo Puyo" bekannt) und spielt sich somit ähnlich wie Tetris.
Auch dieses Klassikerremake spielt sich fast genauso wie die Vorlage, allerdings gibt es dank OpenGL recht aufwendige Grafiken, natürlich gewohnt komplett in 3D.

|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]
|}

===Manager===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|[[Bild:PBM2_Kdr.jpg|thumb|center|168px|Link: '''[[Projekt_PBM2|PBall Manager 2]]''']]

|Der PBall Manager 2 ist ein Sportmanager in welchem man in die Rolle des Trainers/Managers eines von 96 PBall Teams aus ganz Europa schlüpft. PBall selbst ist eine fiktive Sportart welche ähnlich Fußball ist.

Im Spiel hat man die Kontrolle über alle Abläufe: Von der Aufstellung über Spielerkäufe bis hin zum Stadionausbau liegt alles in der Hand des Spielers. Doch auch die eigene Karriere kann voran getrieben werden indem man zu anderen Clubs wechselt.

Das Ziel aller PBaller ist der Liga-Meister-Pokal indem die besten Clubs der 4 Europäischen Ligen um den Titel spielen.

|align="center"|[[Benutzer:Flash|Kevin Fleischer alias Flash]]
|-
|}

===Simulationen===
{|{{Prettytable_B1}} width="100%"
!width="30%"|Name
!width="50%"|Beschreibung
!width="20%"|Macher
|-
|''Noch keine Programme''
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!
|''Hier könnte dein Name stehen''
|}

Tutorial Skyboxen

2007-02-21T11:58:22Z

Sascha Willems: /* Skyboxen */ + Hinweise

=Skyboxen=

==Teil 1: Die Texturen mit Terragen erzeugen==
Dieser Teil des Tutorials beschäftigt sich mit dem Erstellen der für eine Skybox benötigten Texturen mit Hilfe des Programms [http://www.planetside.co.uk/terragen Terragen]. Sie sollten jedoch grundlegende Kenntnisse über dieses Programm besitzen, da ich nicht zu sehr ins Detail gehen werde. Ich werde nur die Schritte erklären, die nötig sind, um ein grundlegendes Terrain zu erstellen und die Skybox zu rendern. Sie sollten also zuerst besser das Online-Tutorial zu Terragen lesen.

Wenn Terragen gestartet wird, erscheint die Oberfläche wie abgebildet:<br>
[[Bild:Tutorial_Skyboxen_skybox01.jpg]]<br>

Wir bechäftigen uns zuerst mit dem rechten Fenster, um unsere Landschaft zu generieren. Wählen Sie es aus und klicken sie auf den "Generate Terrain"-Button, um den folgenden Dialog zu öffnen:<br>
[[Bild:Tutorial_Skyboxen_skybox02.jpg]]<br>

In der Auswahlbox "Method" kann die zur Landschaftsgenerierung genutzte Methode gewählt werden, die mit den Optionen auf der rechten Seite noch angepasst werden kann. Ich habe mich dazu entschieden, für dieses Tutorial einen Canyon zu generieren. Klicken Sie nach ihrer Wahl auf "Generate Terrain" und Sie werden Ihre neu generierte Landschaft im "Landscape"-Dialog sehen:<br>
[[Bild:Tutorial_Skyboxen_skybox03.jpg]]<br>

Wenn Ihnen das generierte Terrain nicht gefällt, können Sie es mit den oberen drei Buttons nachträglich anpassen.

Der Punkt, von dem drei Linien ausgehen, ist die Position des Betrachters. Mit einem Linksklick kann man dessen Position und mit einem Rechtsklick dessen Blickpunkt ändern.
Jetzt ist es Zeit die Oberflächentextur zu wählen. Sie könnten zwar selbst eine generieren, da dies jedoch sehr zeitintensiv ist ,habe ich mich dazu entschieden, eine der mit Terragen gelieferten Vorlagen zu öffnen. Klicken Sie dazu auf den "Open..."-Button in der "Surface Map"-Sektion des Dialogs und wählen Sie eine Vorlage aus. Natürlich kann diese im Nachhinein noch abgeändert werden.

Und jetzt zum "Rendering"-Dialog:<br>
[[Bild:Tutorial_Skyboxen_skybox04.jpg]]<br>

Oben links können Sie eine Vorschau Ihrer Landschaft sehen, welche mit dem "Render Preview"-Button aktualisiert werden kann. Aber benutzen Sie nicht die höchste Detailstufe, nur um die Vorschau zu rendern, da dies sonst relativ lange dauern kann. Diese Detailstufe sollte nur zum endgültigen Rendern genutzt werden, während für das Preview die mittlere Stufe ausreicht.

Unter "Image Size" können Sie die Größe Ihrer Skyboxtexturen wählen. Für eine Skybox sollten Höhe und Breite gleich sein. Ich habe 512x512 Pixel gewählt, so das die Skybox später detailliert genug aussieht, um einen realisitschen Eindruck zu vermitteln. Aber vergessen Sie nicht, das größere Texturen mehr Speicher benötigen und Performance kosten.
Bevor Sie die Skybox rendern können, müssen noch einige Einstellungen geändert werden, um das benötigte 90° Sichtfeld zu erhalten. Klicken Sie auf "Camera Settings" um den folgenden Dialog zu öffnen:<br>
[[Bild:Tutorial_Skyboxen_skybox05.jpg]]<br>

Für das korrekte Sichtfeld müssen Sie den "Zoom"-Wert auf 1 setzen. Danach können Sie diesen Dialog auch schon wieder schliessen und zum "Rendering Control"-Dialog wechseln. Setzen Sie dort alle Werte für die Kameraausrichtung ("Camera orientation") auf 0.
Nachdem Sie den Detailschieber auf Maxmimum gesetzt haben- sind Sie Bereit die Texturen zu rendern. Der erste Teil wird bei einer Kopfausrichtung ("head orientation") von 0° generiert und stellt ihr hinteres Bild dar. Das rechte wird bei 90°, das vordere bei 180° und das linke bei 270° gerendert.
Setzen Sie die Kopfausrichtung jetzt wieder auf 0° und den "Pitch" auf 90°, um den Himmel zu rendern, also ihr oberes Bild. Die untere Textur für die Skybox wird bei einem "Pitch" von -90° gerendert.
Die hier von mir gewählten Namen sind natürlich unverbindlich und an das Beispielprogramm angepasst.

Hier die 6 Texturen meiner Skybox:

<div>
{|rules="all" border = "1"
| [[Bild:Tutorial_Skyboxen_skybox10.jpg]]
|
|
|
|-
| [[Bild:Tutorial_Skyboxen_skybox06.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox07.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox08.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox09.jpg]]
|-
| [[Bild:Tutorial_Skyboxen_skybox11.jpg]]
|
|
|
|}
</div>

==Teil 2 - Nutzung der Skybox in OpenGL==
Nachdem Sie nun ihre Skyboxtexturen generiert haben, ist es Zeit, sie in Ihrer OpenGL-Anwendung zu nutzen. Ich werde hier nicht die Grundschritte zur Erstellung eines Renderkontextes oder zur Darstellung von Dreiecken zeigen. Wenn Sie darüber mehr wissen wollen, suchen sie eine der diversen OpenGL Seiten mit Tutorials zu diesen Themen auf.

===Schritt 1 - Die Texturen laden===
Texturen mit der TglBMP Klasse zu laden ist sehr leicht. Der Einfachheit halber bevorzuge ich es, alle Texturen der Skybox in einem Array zu organisieren. Ausserdem nutze ich lokal in der Ladeprozedur ein Array in dem alle Dateinamen abgelegt sind, so dass die Texturen leicht in einer Schleife geladen werden können:

<pascal>procedure TGLForm.LoadSkyBox;
const
SkyBoxName : array[0..5] of String = ('BK', 'FR', 'DN', 'UP', 'LF', 'RT');
var
i : Integer;
begin
for i := 0 to High(SkyBoxTexture) do
begin
SkyBoxTexture[i] := TGLBmp.Create;
SkyBoxTexture[i].LoadImage(SkyBoxName[i]+'.jpg');
SkyBoxTexture[i].SetTextureWrap(GL_CLAMP_TO_EDGE, GL_CLAMP_TO_EDGE);
SkyBoxTexture[i].GenTexture(False, False);
end;
GenerateSkyBox(256, 256, 256);
end;</pascal>

Das global deklarierte SkyBoxTexture-Array beinhaltet unsere sechs Texturen und im lokal deklarierten SkyBoxName-Array befinden sich alle zugehörigen Dateinamen für jede Textur, so dass Sie die Ladeprozedur ganz einfach an Ihre Namenskonventionen anpassen können.
Zuerst laden wir die Texturen in einer Schleife. Dabei muss jedesmal die TglBMP Klasse erstellt werden, dann wird die Bilddatei geladen und der Texturewrap auf GL_CLAMP_TO_EDGE für die S und die T Koordinate gesetzt. Dies ist nötig damit unsere Kanten passend aneinandergefügt werden.

Beachten Sie auch, dass ich die GenTexture-Prozedur der TglBMP-Klasse abgeändert habe. Ihr werden jetzt zwei Parameter vom Typ BOOLEAN übergeben, wobei der erste angibt, ob die Textur im komprimierten S3-Format geladen gibt und der zweite, ob das anisotropische Filtering genutzt werden soll. Wenn Sie diese Eigenschaften nutzen wollen, müssen Sie sich jedoch zuerst davon versichern, dass die Grafikkarte diese unterstützt.

Sie sollten jedoch davon absehen, Ihre Skybox Texturen komprimiert zu laden weil dadurch die Qualität stark herabgesetzt werden kann.

===Schritt 2 - Die Displayliste erstellen===
Nachdem die Texturen geladen wurden, generieren wir die Displayliste für unsere Skybox. Wie Sie bereits wissen sollten, sind Displaylisten um ein Vielfaches schneller, als die Quads in jedem Frame neu zu zeichnen.

<pascal>procedure TGLForm.GenerateSkyBox(pWidth, pHeight, pLength : TGLFloat);
var
px,py,pz : TGLFloat;
begin
List := glGenLists(1);
glNewList(List, GL_COMPILE);
px := - pWidth / 2;
py := - pHeight / 2;
pz := - pLength / 2;
SkyBoxTexture[0].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px, py, pz);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz);
glEnd;
SkyBoxTexture[1].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(0, 0); glVertex3f(px + pWidth, py, pz + pLength);
glEnd;
SkyBoxTexture[2].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz + pLength);
glTexCoord2f(0, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px, py, pz);
glEnd;
SkyBoxTexture[3].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px, py + pHeight, pz);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py + pHeight, pz);
glEnd;
SkyBoxTexture[4].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 0); glVertex3f(px, py, pz);
glTexCoord2f(0, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px, py + pHeight, pz);
glEnd;
SkyBoxTexture[5].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px + pWidth, py, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px + pWidth, py + pHeight, pz);
glEnd;
glEndList;
end;</pascal>

Dieser Teil des Quelltextes ist sehr einfach zu verstehen. Die Variablen px, py und pz werden genutzt, um die Skybox zu zentrieren. Dann wird ein Quader mit den Kantenlängen pWidth, pHeight und pLength und den zugehörigen Texturen in unsere Displayliste kompiliert. Der erste Quad ist die hintere Seite, der zweite die vordere Seite, der dritte ist der Boden, der vierte der Deckel, der fünfte die linke Seite und der letzte ist die rechte Seite.

===Schritt 3 - Die Skybox zeichnen===
Bevor wir die Skybox nun zeichnen '''deaktivieren wir das Schreiben in den Tiefenpuffer''' via [[glDepthMask]]. So vermeiden wir dass später gerenderte Objekte durch den von der Skybox geschriebenen Tiefenwert betroffen werden :

<pascal>glDepthMask(False);</pascal>

Aufgerufen wird die Skybox nun über ihre Displayliste :

<pascal>
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
glClear(GL_DEPTH_BUFFER_BIT);
glRotatef(xrot, 1, 0, 0);
glRotatef(yrot, 0, 1, 0);
glCallList(List);
SwapBuffers(FDC);</pascal>

Einleitend wechseln wir in die Modelansichtsmatrix und laden dort die Grundmatrix. Dann muss nur der Tiefenpuffer gelöscht (und eventuell andere verwendete Puffer) werden, den Farbpuffer müssen Sie nicht mehr löschen, da die Skybox den ganzen Schirm füllt. Jetzt muss unsere Matrix nur noch entsprechend dem Sichtwinkel des Betrachters rotiert werden, bevor unsere Displayliste aufgerufen wird. An die Spielerposition wird hier natürlich nicht transformiert, da die Skybox ja unendlich weit vom Spieler entfernt sein soll.

Nach dem Rendern der Skybox müssen wir das Schreiben in den Tiefenpuffer natürlich wieder aktivieren :

<pascal>glDepthMask(True);</pascal>

''Kleiner Hinweis :'' Wer möchte kann die beiden [[glDepthMask]]-Aufrufe natürlich auch direkt in der oben erstellten Displayliste ablegen.

Jetzt könnte zusätzlich noch eine animierte Wolkenschicht wie in Quake3 oder Unreal zu sehen hinzugefügt werden. Eine Alternative zu einer Skybox sind übrigens [[Skydome]]s, die mittels passender Formeln (und evtl. auch [[Shader]]n) dynamischer gestaltet werden können.

==Hinweise==

===Größe der Texturen===
Je nach Anwendung bzw. Blickrichtung des Betrachters nimmt die Skybox einen recht großen Platz auf dem Schirm bei, wodurch Qualitätsunterschiede hier direkt sichtbar sind. Daher sollte eine entsprechend hohe Auflösung gewählt werden, also 1024x1024 und höher. Man benötigt zwar 6 solch großer Texturen (die untere Textur kann man sich aber evtl. je nach Szenario sparen) die allerdings auch trotz solch hoher Auflösung in den Speicher moderner Grafikkarten passen sollten.

===Texturenkompression===
Bereits seit mehreren Jahren können 3D-Beschleuniger Texturen in einem Format mit fester Kompressionsrate ablegen und nutzen, wodurch sowohl Grafikkartenspeicher als auch Bandbreite gespart wird. Allerdings wirkt sich diese besonders bei Texturen mit langen Farbverläufen bzw. Übergängen (wie bei Skyboxen oft der Fall) negativ aus und ist i.d.R. auch direkt erkennbar, wie auf folgendem Bild sichtbar ist :
[[Bild:Tutorial_skyboxen_texcomp.jpg]]<br>
Die Verschlechterung des Bildes auf der rechten Seite sollte leicht erkennbar sein. Wenn man die Texturen dann auch noch als JPG abgelegt hat und dort bereits komprimiert hat (auch bei 100% Qualitätseinstellung komprimiert JPG immernoch) verschlechtert sich das Gesamtbild nochmals.

==Das Beispielprogramm==
Und zu guter Letzt noch ein Bild unserer Skybox aus dem Demoprogramm:<br>
[[Bild:Tutorial_Skyboxen_skybox12.jpg]]<br>

Hinweis:
Für diesen Screenshot habe ich 512x512 Pixel große Texturen genutzt, während die Texturen im Download nur 256x256 Pixel groß sind!

==Download==
[http://www.delphigl.de/files/skyboxtut.zip Die Skyboxdemo (inklusive Quellcode) herunterladen]

Autor: [[Benutzer:Sascha_Willems|Sascha Willems]]

{{TUTORIAL_NAVIGATION|[[Tutorial_Terrain3]]|-}}

[[Kategorie:Tutorial|Tutorial3]]

Datei:Tutorial skyboxen texcomp.jpg

2007-02-21T11:52:28Z

Sascha Willems: Vergleich der Skyboxtextur ohne und mit Texturkompression

Vergleich der Skyboxtextur ohne und mit Texturkompression

Tutorial Skyboxen

2007-02-21T11:37:48Z

Sascha Willems: /* Schritt 3 - Die Skybox zeichnen */

=Skyboxen=

==Teil 1: Die Texturen mit Terragen erzeugen==
Dieser Teil des Tutorials beschäftigt sich mit dem Erstellen der für eine Skybox benötigten Texturen mit Hilfe des Programms [http://www.planetside.co.uk/terragen Terragen]. Sie sollten jedoch grundlegende Kenntnisse über dieses Programm besitzen, da ich nicht zu sehr ins Detail gehen werde. Ich werde nur die Schritte erklären, die nötig sind, um ein grundlegendes Terrain zu erstellen und die Skybox zu rendern. Sie sollten also zuerst besser das Online-Tutorial zu Terragen lesen.

Wenn Terragen gestartet wird, erscheint die Oberfläche wie abgebildet:
[[Bild:Tutorial_Skyboxen_skybox01.jpg|center]]

Wir bechäftigen uns zuerst mit dem rechten Fenster, um unsere Landschaft zu generieren. Wählen Sie es aus und klicken sie auf den "Generate Terrain"-Button, um den folgenden Dialog zu öffnen:
[[Bild:Tutorial_Skyboxen_skybox02.jpg|center]]

In der Auswahlbox "Method" kann die zur Landschaftsgenerierung genutzte Methode gewählt werden, die mit den Optionen auf der rechten Seite noch angepasst werden kann. Ich habe mich dazu entschieden, für dieses Tutorial einen Canyon zu generieren. Klicken Sie nach ihrer Wahl auf "Generate Terrain" und Sie werden Ihre neu generierte Landschaft im "Landscape"-Dialog sehen:
[[Bild:Tutorial_Skyboxen_skybox03.jpg|center]]

Wenn Ihnen das generierte Terrain nicht gefällt, können Sie es mit den oberen drei Buttons nachträglich anpassen.

Der Punkt, von dem drei Linien ausgehen, ist die Position des Betrachters. Mit einem Linksklick kann man dessen Position und mit einem Rechtsklick dessen Blickpunkt ändern.
Jetzt ist es Zeit die Oberflächentextur zu wählen. Sie könnten zwar selbst eine generieren, da dies jedoch sehr zeitintensiv ist ,habe ich mich dazu entschieden, eine der mit Terragen gelieferten Vorlagen zu öffnen. Klicken Sie dazu auf den "Open..."-Button in der "Surface Map"-Sektion des Dialogs und wählen Sie eine Vorlage aus. Natürlich kann diese im Nachhinein noch abgeändert werden.

Und jetzt zum "Rendering"-Dialog:

[[Bild:Tutorial_Skyboxen_skybox04.jpg|center]]

Oben links können Sie eine Vorschau Ihrer Landschaft sehen, welche mit dem "Render Preview"-Button aktualisiert werden kann. Aber benutzen Sie nicht die höchste Detailstufe, nur um die Vorschau zu rendern, da dies sonst relativ lange dauern kann. Diese Detailstufe sollte nur zum endgültigen Rendern genutzt werden, während für das Preview die mittlere Stufe ausreicht.

Unter "Image Size" können Sie die Größe Ihrer Skyboxtexturen wählen. Für eine Skybox sollten Höhe und Breite gleich sein. Ich habe 512x512 Pixel gewählt, so das die Skybox später detailliert genug aussieht, um einen realisitschen Eindruck zu vermitteln. Aber vergessen Sie nicht, das größere Texturen mehr Speicher benötigen und Performance kosten.
Bevor Sie die Skybox rendern können, müssen noch einige Einstellungen geändert werden, um das benötigte 90° Sichtfeld zu erhalten. Klicken Sie auf "Camera Settings" um den folgenden Dialog zu öffnen:

[[Bild:Tutorial_Skyboxen_skybox05.jpg|center]]

Für das korrekte Sichtfeld müssen Sie den "Zoom"-Wert auf 1 setzen. Danach können Sie diesen Dialog auch schon wieder schliessen und zum "Rendering Control"-Dialog wechseln. Setzen Sie dort alle Werte für die Kameraausrichtung ("Camera orientation") auf 0.
Nachdem Sie den Detailschieber auf Maxmimum gesetzt haben- sind Sie Bereit die Texturen zu rendern. Der erste Teil wird bei einer Kopfausrichtung ("head orientation") von 0° generiert und stellt ihr hinteres Bild dar. Das rechte wird bei 90°, das vordere bei 180° und das linke bei 270° gerendert.
Setzen Sie die Kopfausrichtung jetzt wieder auf 0° und den "Pitch" auf 90°, um den Himmel zu rendern, also ihr oberes Bild. Die untere Textur für die Skybox wird bei einem "Pitch" von -90° gerendert.
Die hier von mir gewählten Namen sind natürlich unverbindlich und an das Beispielprogramm angepasst.

Hier die 6 Texturen meiner Skybox:

<div align="center">
{|rules="all" border = "1"
| [[Bild:Tutorial_Skyboxen_skybox10.jpg]]
|
|
|
|-
| [[Bild:Tutorial_Skyboxen_skybox06.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox07.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox08.jpg]]
| [[Bild:Tutorial_Skyboxen_skybox09.jpg]]
|-
| [[Bild:Tutorial_Skyboxen_skybox11.jpg]]
|
|
|
|}
</div>

==Teil 2 - Nutzung der Skybox in OpenGL==
Nachdem Sie nun ihre Skyboxtexturen generiert haben, ist es Zeit, sie in Ihrer OpenGL-Anwendung zu nutzen. Ich werde hier nicht die Grundschritte zur Erstellung eines Renderkontextes oder zur Darstellung von Dreiecken zeigen. Wenn Sie darüber mehr wissen wollen, suchen sie eine der diversen OpenGL Seiten mit Tutorials zu diesen Themen auf.

===Schritt 1 - Die Texturen laden===
Texturen mit der TglBMP Klasse zu laden ist sehr leicht. Der Einfachheit halber bevorzuge ich es, alle Texturen der Skybox in einem Array zu organisieren. Ausserdem nutze ich lokal in der Ladeprozedur ein Array in dem alle Dateinamen abgelegt sind, so dass die Texturen leicht in einer Schleife geladen werden können:

<pascal>procedure TGLForm.LoadSkyBox;
const
SkyBoxName : array[0..5] of String = ('BK', 'FR', 'DN', 'UP', 'LF', 'RT');
var
i : Integer;
begin
for i := 0 to High(SkyBoxTexture) do
begin
SkyBoxTexture[i] := TGLBmp.Create;
SkyBoxTexture[i].LoadImage(SkyBoxName[i]+'.jpg');
SkyBoxTexture[i].SetTextureWrap(GL_CLAMP_TO_EDGE, GL_CLAMP_TO_EDGE);
SkyBoxTexture[i].GenTexture(False, False);
end;
GenerateSkyBox(256, 256, 256);
end;</pascal>

Das global deklarierte SkyBoxTexture-Array beinhaltet unsere sechs Texturen und im lokal deklarierten SkyBoxName-Array befinden sich alle zugehörigen Dateinamen für jede Textur, so dass Sie die Ladeprozedur ganz einfach an Ihre Namenskonventionen anpassen können.
Zuerst laden wir die Texturen in einer Schleife. Dabei muss jedesmal die TglBMP Klasse erstellt werden, dann wird die Bilddatei geladen und der Texturewrap auf GL_CLAMP_TO_EDGE für die S und die T Koordinate gesetzt. Dies ist nötig damit unsere Kanten passend aneinandergefügt werden.

Beachten Sie auch, dass ich die GenTexture-Prozedur der TglBMP-Klasse abgeändert habe. Ihr werden jetzt zwei Parameter vom Typ BOOLEAN übergeben, wobei der erste angibt, ob die Textur im komprimierten S3-Format geladen gibt und der zweite, ob das anisotropische Filtering genutzt werden soll. Wenn Sie diese Eigenschaften nutzen wollen, müssen Sie sich jedoch zuerst davon versichern, dass die Grafikkarte diese unterstützt.

Sie sollten jedoch davon absehen, Ihre Skybox Texturen komprimiert zu laden weil dadurch die Qualität stark herabgesetzt werden kann.

===Schritt 2 - Die Displayliste erstellen===
Nachdem die Texturen geladen wurden, generieren wir die Displayliste für unsere Skybox. Wie Sie bereits wissen sollten, sind Displaylisten um ein Vielfaches schneller, als die Quads in jedem Frame neu zu zeichnen.

<pascal>procedure TGLForm.GenerateSkyBox(pWidth, pHeight, pLength : TGLFloat);
var
px,py,pz : TGLFloat;
begin
List := glGenLists(1);
glNewList(List, GL_COMPILE);
px := - pWidth / 2;
py := - pHeight / 2;
pz := - pLength / 2;
SkyBoxTexture[0].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px, py, pz);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz);
glEnd;
SkyBoxTexture[1].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(0, 0); glVertex3f(px + pWidth, py, pz + pLength);
glEnd;
SkyBoxTexture[2].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz + pLength);
glTexCoord2f(0, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px, py, pz);
glEnd;
SkyBoxTexture[3].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px, py + pHeight, pz);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py + pHeight, pz);
glEnd;
SkyBoxTexture[4].Bind;
glBegin(GL_QUADS);
glTexCoord2f(1, 0); glVertex3f(px, py, pz);
glTexCoord2f(0, 0); glVertex3f(px, py, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px, py + pHeight, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px, py + pHeight, pz);
glEnd;
SkyBoxTexture[5].Bind;
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex3f(px + pWidth, py, pz);
glTexCoord2f(1, 0); glVertex3f(px + pWidth, py, pz + pLength);
glTexCoord2f(1, 1); glVertex3f(px + pWidth, py + pHeight, pz + pLength);
glTexCoord2f(0, 1); glVertex3f(px + pWidth, py + pHeight, pz);
glEnd;
glEndList;
end;</pascal>

Dieser Teil des Quelltextes ist sehr einfach zu verstehen. Die Variablen px, py und pz werden genutzt, um die Skybox zu zentrieren. Dann wird ein Quader mit den Kantenlängen pWidth, pHeight und pLength und den zugehörigen Texturen in unsere Displayliste kompiliert. Der erste Quad ist die hintere Seite, der zweite die vordere Seite, der dritte ist der Boden, der vierte der Deckel, der fünfte die linke Seite und der letzte ist die rechte Seite.

===Schritt 3 - Die Skybox zeichnen===
Bevor wir die Skybox nun zeichnen '''deaktivieren wir das Schreiben in den Tiefenpuffer''' via [[glDepthMask]]. So vermeiden wir dass später gerenderte Objekte durch den von der Skybox geschriebenen Tiefenwert betroffen werden :

<pascal>glDepthMask(False);</pascal>

Aufgerufen wird die Skybox nun über ihre Displayliste :

<pascal>
glMatrixMode(GL_MODELVIEW);
glLoadIdentity;
glClear(GL_DEPTH_BUFFER_BIT);
glRotatef(xrot, 1, 0, 0);
glRotatef(yrot, 0, 1, 0);
glCallList(List);
SwapBuffers(FDC);</pascal>

Einleitend wechseln wir in die Modelansichtsmatrix und laden dort die Grundmatrix. Dann muss nur der Tiefenpuffer gelöscht (und eventuell andere verwendete Puffer) werden, den Farbpuffer müssen Sie nicht mehr löschen, da die Skybox den ganzen Schirm füllt. Jetzt muss unsere Matrix nur noch entsprechend dem Sichtwinkel des Betrachters rotiert werden, bevor unsere Displayliste aufgerufen wird. An die Spielerposition wird hier natürlich nicht transformiert, da die Skybox ja unendlich weit vom Spieler entfernt sein soll.

Nach dem Rendern der Skybox müssen wir das Schreiben in den Tiefenpuffer natürlich wieder aktivieren :

<pascal>glDepthMask(True);</pascal>

''Kleiner Hinweis :'' Wer möchte kann die beiden [[glDepthMask]]-Aufrufe natürlich auch direkt in der oben erstellten Displayliste ablegen.

Jetzt könnte zusätzlich noch eine animierte Wolkenschicht wie in Quake3 oder Unreal zu sehen hinzugefügt werden. Eine Alternative zu einer Skybox sind übrigens [[Skydome]]s, die mittels passender Formeln (und evtl. auch [[Shader]]n) dynamischer gestaltet werden können.

==Das Beispielprogramm==
Und zu guter Letzt noch ein Bild unserer Skybox aus dem Demoprogramm:
[[Bild:Tutorial_Skyboxen_skybox12.jpg|center]]

Hinweis:
Für diesen Screenshot habe ich 512x512 Pixel große Texturen genutzt, während die Texturen im Download nur 256x256 Pixel groß sind!

==Download==
[http://www.delphigl.de/files/skyboxtut.zip Die Skyboxdemo (inklusive Quellcode) herunterladen]

Autor: [[Benutzer:Sascha_Willems|Sascha Willems]]

{{TUTORIAL_NAVIGATION|[[Tutorial_Terrain3]]|-}}

[[Kategorie:Tutorial|Tutorial3]]

Diskussion:TBN Matrix

2006-12-13T15:01:09Z

Sascha Willems:

== Offlinebearbeitung ==

Der Artikel ist bereits seit mehreren Wochen als "Offline in Bearbeitung" markiert und in der Zeit sind keine Änderungen erfolgt. Wird noch dran gearbeitet, oder ist ber bereits fertig. Bei letzterem bitte Offline-Tag entfernen.

--[[Benutzer:Sascha Willems|Sascha Willems]] 16:01, 13. Dez 2006 (CET)

Diskussion:GLSL Licht und Schatten

2006-12-13T15:00:21Z

Sascha Willems: Offlinebearbeitung

Ich hoffe du sponserst später noch paar coole Bilder. Du weißt doch: Ich steh auf sowas. ;)
Und außerdem bietet es sich bei einem Shaderthema immer an. ;)

--[[Benutzer:Flash|Flash]] 16:47, 12. Sep 2006 (CEST)

== Offlinebearbeitung ==

Der Artikel ist bereits seit mehreren Wochen als "Offline in Bearbeitung" markiert und in der Zeit sind keine Änderungen erfolgt. Wird noch dran gearbeitet, oder ist ber bereits fertig. Bei letzterem bitte Offline-Tag entfernen.

[[Benutzer:Sascha Willems|Sascha Willems]] 16:00, 13. Dez 2006 (CET)