SDL
(Mehr Informationen/weitere Artikel) {{{1}}} |
 |
Dieser Artikel deckt bisher nur den nötigsten Teil von SDL ab und soll nicht über den wahren Funktionsumfang von SDL hinwegtäuschen. (Phobeus)
Inhaltsverzeichnis
SDL
|
Dieses Wiki besitzt eine eigene SDL-Funktionsübersicht mit deutschen Übersetzungen der SDL-Befehlsreferenzen. (Noch im Aufbau) |
Über SDL
Steckbrief
SDL steht für Simple Direct Media Layer. Hinter dieser komplizierten Bezeichnung verbirgt sich nichts anderes als die OpenSource-Antwort auf Microsofts DirectX. Es handelt sich hierbei um eine Bibliothek die wie DirectX versucht alle wichtigen Bereiche der Spieleprogrammierung abzudecken. Im Gegensatz zu DirectX ist SDL auch für andere Plattformen verfügbar und ermöglicht es z.B. eine Anwendung sowohl für Windows als auch für Linux oder anderen Plattformen wie BSD, MacOS oder der XBOX zu entwickeln.
Entstehung
SDL ist ein Projekt von Loki Games, einer Firma, die damit beauftragt wurde kommerzielle Spieletitel nach Linux zu portieren. Einer der wichtigsten Hauptentwickler ist Sam Lantinga, der heute bei Blizzard Entertainment arbeitet.
SDL & OpenGL
Wer sich beginnt mit SDL zu beschäftigen wird feststellen, dass weitesgehend nur der Bereich der 2D-Grafikprogrammierung abgedeckt wird. SDL selbst versucht nur den Bereich von DirectDraw abzudecken. Eine Konkurrenz für Direct3D gibt es bei SDL nicht. Stattdessen bietet SDL einfache Möglichkeiten ein Fenster zu initalisieren, welches OpenGL darstellen kann. Für den OpenGL-Programmierer ändert sich damit nur die Art, wie er zuvor sein Fenster initalisiert. Die restliche OpenGL-Programmierung bleibt wie gewohnt erhalten.
Warum SDL
Vermutlich ist die erste Frage, die man sich beim Erlernen einer neuen Schnittstelle sich selbst fragt. In diesem Fall ist dies allerdings nicht ganz leicht zu beantworten, zumindest nicht, ohne dabei die Gegenfrage zu Stellen. "Warum WinAPI?". Gerade bei der Entwicklung eines Spieles arbeitet man vorwiegend im Vollbildmodus und nur selten wird dabei wirklich auf interne Schnittstellen von Windows zugegriffen. Meistens beschränkt sich die Verwendung auf das blosse Initalisieren eines geeigneten Fensters um darauf mit OpenGL zu zeichnen.
SDL bietet hierfür einige einfache Schnittstellen mit denen man plattformneutral nicht nur ein Fenster initalisieren kann, sondern auch Eingaben des Anwenders verarbeiten kann, Soundeffekte abspielen kann oder auch einfach nur Texturen zu laden. Wieso also sollte man diese Möglichkeiten außer acht lassen und eine Schnittstelle verwenden, die einen zwingend an einer Plattform bindet? Immerhin ist es nicht gelogen! Wer nur SDL und OpenGL verwendet und nicht auf das darunter liegende System zugreift, kann seine Applikation (sofern Compiler und SDL verfügbar) ohne Änderungen auf anderen Plattformen zu laufen bekommen. Sicherlich erscheint der Marktanteil von Linux eher begrenzt zu sein und die meisten nicht interessieren. Doch welchen Grund gibt es, um potenzielle Anwender davon abzuhalten die eigene Applikation zu verwenden? Zumal man mit einem durchschnittlichen Spiel unter Linux sicherlich mehr Ruhm erlangen kann als unter Window mit einer guten Anwendung in der Masse unterzugehen. Die Frage, ob SDL für einen selbst eine lohnende Schnittstelle ist, sollte also damit gekoppelt sein, welche Vorteile eine andere für einen selbst hat. Sind diese nicht gegeben, lohnt sich der Blick auf SDL in jedem Fall.
Nachteile
Nicht immer ist der Einsatz von SDL von Vorteil. Die Schnittstelle hat eindeutig ihren Ursprung bei der Spieleentwicklung und ist entsprechend auch auf dieser Bereich ausgelegt. Wer also eine Anwendung schreibt die nur einen kleinen Sichtbereich für OpenGL benötigt und ansonsten mit sehr vielen Knöpfen und Eingabefeldern aufwartet (z.B. eine Simulation) wird eventuell mit der VCL unter Delphi konfortabler sein Programm entwickeln können. Auch ist das "Simple" im Namen von SDL durchaus gebot. Das Fenstermangement ist nicht besonders mächtig. Das erzeugen eines Fensters und ihm einen Titel geben, sowie Events abzufangen ist schon nahezu das höchste Gefühle. In der Praxis zwar weitesgehend ausreichend, läßt es nicht viele Spielereien mit dem Fenster mehr zu.
SDL in der Praxis
Philosophie
Die gängige Philosophie von SDL ist ein möglich einfache, allerdings dennoch mächtige API zur Verfügung zu stellen. Nach einer kurzen Einarbeitungszeit setzt ein steiler Lerneffekt ein und man wird mit wenigen Anweisungen schnell zu den gewünschten Ziel gelangen. Im Gegensatz zu anderen komplexen APIs ist es ohne Probleme möglich innerhalb von kurzer Zeit die Funktionen von SDL auswendig zu lernen und sich nicht in einem Dschungel an Funktionen zu verheddern.
Aus diesem Grunde ist SDL in mehre Subsysteme unterteilt, die je nach Anforderung der Anwendung eingebunden werden können. Obwohl diese einzelnen Systeme zumeist von unterschiedlichen Autoren stammen, erkennt man durchweg eine einheitliche Struktur innerhalb der Subsysteme.
Einsatzfelder
SDL gliedert sich in zahlreiche Untersysteme mit unterschiedlichen Zielsetzungen. Ähnlich wie bei DirectX gibt es z.B. statt einem DirectInput ein SDL_Input, statt DirectSound ein SDL_Audio etc. Jedes dieser Subsysteme läßt sich meistens sehr leicht in eine bestehende SDL-Applikationen integrieren. Oftmals reicht der Aufruft des Subsystems beim Init von SDL aus um dieses in Anspruch zu nehmen. Im folgenden Stellen wir einige dieser Untersystem vor:
- SDL_Audio (DirectSound-Ersatz)
- SDL_Image (Laden von Texturen)
- SDL_Net (DirectPlay-Ersatz)
- SDL_Thread (Multithreading)
- SDL_TTF (Anzeige von TrueType-Schriften)
Wer jetzt eine deutsche Dokumentation zu SDL-Funktionen sucht, kann hier im Wiki fündig werden. Siehe dazu die SDL-Funktionsübersicht.
Typische Anwendungsbeispiele
(Anm v. Phobeus: Das wird künftig wegfallen und durch Tutorials ersetzt)
- Laden einer Textur
- Erzeugen eines Fensters
- Reagieren auf Eingaben
Wissenswertes
Bekannte Programme
Bekannte Programme die SDL verwenden:
