Eine Studie hat vor Kurzem das mittlerweile riesige Ausmaß der Spielindustrie bestätigt: 220 000 Angestellte sind demnach im Moment weltweit beschäftigt, der jährliche Umsatz beträgt ungefähr 21 Milliarden US-Dollar (davon alleine über 1 Mrd. in Deutschland) und es sind weiterhin zweistellige Wachstumsraten zu erwarten. Man geht davon aus, dass der globale Umsatz bis 2008 auf über 55 Mrd. Dollar steigen wird. Damit haben Videospiele der Filmindustrie schon jetzt den Rang abgelaufen und gehören somit zu einem der wichtigsten Zweige der Unterhaltungsbranche. Das Wachstum hängt u.a. damit zusammen, dass immer mehr ältere Konsumenten virtuelle Spielewelten für sich entdecken.
Was hat das mit DirectX zu tun? Nun DirectX, oder DX, wie ich im Folgenden abkürzen werde, ist die Basis vieler Programmierer bei der Entwicklung von Computerspielen. Das Einsatzgebiet von DX erstreckt sich aber heute noch viel weiter, wie man an mehreren Stellen später sehen wird. Grob gesagt, handelt es sich dabei um eine Sammlung von Komponenten und Technologien für das Design anspruchsvoller Multimediaanwendungen unter Windows, die von Microsoft entwickelt und frei vertrieben wird.
Um den Sinn und Zweck von DirectX zu erklären, muss man etwas weiter ausholen: Im Mai 1990 erfolgte mit der Einführung von Microsoft Windows 3.0 ein entscheidender Einschnitt in die Softwareindustrie. Zum ersten Mal hatte der User ein Betriebssystem vor sich, das ihm eine grafische Benutzeroberfläche bot, in der er sich bequem durch Fenster navigieren und so Aufgaben schnell erledigen konnte. Bisher war man nämlich von DOS gewohnt, auswendig gelernte Textbefehle einzutippen, wenn man z.B. einen Ordner verschieben wollte. Schon zu dieser Zeit gab es eine beachtliche Computerspielszene. Nun sollte man wissen, dass DOS ein Singletasking-OS war. Wenn also eine Anwendung gestartet wurde, dann übergab DOS die volle Kontrolle über die Hardware an das Programm. Dieses konnte bzw. musste dann ohne Umwege direkt mit der Hardware interagieren, wodurch sich eine maximale Performance bei optimalem Programmcode ergab. Gleichzeitig lag darin aber auch ein großes Problem: Der Programmierer konnte nur die Funktionen einer Grafik- oder Soundkarte nutzen, von denen er sicher war, dass sie von allen Herstellern zur Verfügung gestellt wurden. Die einzige Alternative war, jede einzelne Karte separat zu unterstützen, was mit sehr hohem Aufwand verbunden war. Neben dem eigentlichen Programm mussten in diesem Fall noch unzählige Treiber für die Hardware mitliefert werden. Diese mühselige Vorgehensweise nennt man auch hardware-abhängige Programmierung.
Windows 3.0 verfolgte dagegen einen anderen Ansatz. Zwar basierte es noch intern auf dem MS-DOS-Kern, doch wurde das Betriebssystem zur obersten Instanz, zu einer zentralen Anlaufstelle für alle Prozesse. Anders als bei einem Singletaskingsystem, wo das OS nicht mehr Rechte als eine Anwendung hat, gestattete Windows den direkten Zugriff auf die Hardware aus Anwendungen heraus nicht mehr; es hatte hier die exklusiven Rechte. Es verwaltete den Speicher und die Hardware und teilte die vorhandenen Ressourcen unter den Tasks auf. Erst dadurch konnten mehrere Anwendungen parallel laufen, meistens ohne dass sie sich in die Quere kamen (Multitasking-OS). Ab sofort kommunizierte man also als Programmierer nicht mit der Hardware selber, sondern mit Windows (hardware-unabhängige Programmierung), über vereinheitlichte Funktions-Bibliotheken. Ein Befehl eines Programms – z.B. das Zeichnen eines roten Pixels - musste nun viele Schichten des Betriebssystems passieren, bis er schließlich übersetzt an die Hardware geschickt wurde und eine Ausgabe erfolgte. Dass dieser hierarchisch gegliederte Befehlsablauf enorme Zeit kostete, ist offensichtlich. Die Performance wurde also zu Gunsten der Kompatibilität eingeschränkt.
Zu Beginn bot Windows deshalb einem nicht die Mittel, die für die Realisierung von aufwändigen Grafik- und Soundeffekten benötigt wurden. Die Grafik-API GDI , welche die Fenster auf den Bildschirm zeichnete, entpuppte sich als zu langsam für Multimediaanwendungen, die über Minesweeper hinaus gingen, da sie die Grafikkarte nicht direkt ansprach.
Wie erwähnt, war MS-DOS immer noch fest in Windows verankert. Man konnte ohne Probleme in den DOS-Modus umschalten und somit das Multitasking-System aushebeln und wieder direkten Zugriff auf die Hardware bekommen. Diese Option war eigentlich als Übergangslösung gedacht, um ältere Software, die für DOS programmiert wurde, trotzdem noch auf Windows-PCs betreiben zu können. Doch da es keine Alternativen für die Spielentwickler gab, wurden Spiele weiterhin aktiv für MS-DOS programmiert (prominentestes Beispiel wäre Doom I von Id Software); sie hielten dieses obsolete OS lange am Leben.
Um diese paradoxe Situation aufzulösen, arbeitete Microsoft intensiv daran die Multimedia-Funktionen von Windows zu verbessern. Hier kommt nun DirectX ins Spiel. Es dauerte allerdings 5 Jahre, bis die erste DX-Version 1995 mit Windows 95 verabschiedet wurde und die temporären Übergangsmodelle ablöste. Microsoft setzte sich bei dessen Entwicklung einige zentrale Ziele:
Zum einen sollten die Multimedia-Entwickler endlich von der Last befreit werden, zwingend unter DOS zu programmieren, ergo sich selber darum kümmern zu müssen, dass ihre Anwendungen auf Windows-PCs mit den unterschiedlichsten Hardware-Konfigurationen einwandfrei laufen. DirectX sollte eine geräteunabhängige Programmierschnittstelle werden, die – und das ist wichtig - maximale Geschwindigkeit für aufwändige Effekte durch direkten Hardwarezugriff bietet. Die Bibliotheken sollten zudem leicht erweiterbar sein, damit man Features von neuer Hardware schnell den Entwicklern verfügbar machen konnte. Zuletzt sollte man den Hintergedanken Microsofts nicht übersehen, die Entwickler und die Konsumenten von sich abhängig zu machen. Verständlicherweise funktionierte bereits die erste DX-Version ausschließlich nur mit Windows und auch heute kriegt man z.B. DX-Spiele auf Linux oder einem sonstigen non-Windows-System nicht zum Laufen.
DirectX ermöglicht uns also mit Hilfe mehrerer APIs einen schnellen und einheitlichen (= hardware-unabhängig) Zugriff auf die Hardware auf Low-Level Ebene (= hardwarenah). Mit diesen können wir nicht nur auf Funktionen von Grafik- und Soundkarten zurückgreifen und so 2D- oder 3D-Grafik bzw. Audioeffekte realisieren, sondern auch Eingabe- und Netzwerkfähigkeiten in unsere Anwendungen einbauen, die eine möglichst hohe Performance benötigen.
Doch wie kann eigentlich DirectX als ein Satz von geschwindigkeitsoptimierten Low-Level-APIs die Hardwareunabhängigkeit garantieren?
Die Antwort klingt überraschend: DirectX arbeitet mit einem Schichtenmodell, also genau jenem Modell, das bei Windows für den Leistungseinbruch bei Multimediasoftware verantwortlich ist. Nur ist dieses bei DirectX nicht so aufgeblasen. Im Wesentlichen gibt es hier nämlich nur zwei Schichten: die HAL repräsentiert Funktionen, die direkt von der Hardware des Computers, auf dem die DX-Anwendung läuft, unterstützt werden. Welche das sind, wird im Vorfeld von der Anwendung ermittelt und abgespeichert. Die HAL kommuniziert auf direktem Wege mit dem Hardware-Treiber und umgeht somit langsame Windows-Schnittstellen. Sie ist der Kern von DirectX und macht den Geschwindigkeitsvorteil aus. Die HEL kommt erst zum Zuge, wenn angeforderte Funktionen von der Hardware, also von der HAL, nicht zur Verfügung gestellt werden können. Wie der Name dieser Schnittstelle schon sagt, emuliert sie die fehlenden Features, indem sie diese dann z.B. auf Funktionen des Windows GDI zurückführt. Dieser Vorgang schlägt sich fast immer in einer Mehrbelastung des Prozessors nieder und führt damit häufig zu einem Einbruch der Performance, da die CPU mit den Berechnungen nicht mehr hinterherkommt. Oft muss man auch eine Qualitätsminderung des Outputs in Kauf nehmen, die notwendig wird, damit die Leistung nicht ganz in den Keller sinkt. Deshalb ist es sinnvoll, Funktionen nur zu einem bestimmten Grad zu emulieren.
Ein gutes Beispiel für den Einsatz des HEL wären die aktuellen AudioChips, die auf Mainboards gerne verlötet werden und eine separate Soundkarte ersetzen können. Sie suggerieren einem 3D-Sound-Unterstützung und die Hauptplatinen bieten auch die entsprechenden Ausgänge, die für Surround-Sound-Boxensysteme gebraucht werden. Tatsächlich aber muss die CPU die meiste Arbeit bei der Berechnung übernehmen. Wird also eine DirectX-Anwendung gestartet, die 3D-Sound ausgeben soll, so gehen die Befehle in diesem Fall über die HE-Schicht an den Prozessor.
Wohlgemerkt widerspricht das DirectX-Modell dem Sinn eines Multitasking–Betriebssystems, da es Windows die Rechte bei der Verwaltung der Hardware wegnimmt. Doch ist die Leistung der CPU und sonstiger Hardware auch heute immer noch nicht ganz ausreichend, um z.B. fotorealistische Welten selbst bei möglichst direktem Hardwarezugriff auf dem Bildschirm darzustellen. Von einer Verwaltung der Hardware beim Rendern von 3D-Szenen durch Windows kann deshalb auch in naher Zukunft nicht die Rede sein.
Mittlerweile ist DirectX bei Version 9 angelangt. Es ist im Laufe der Zeit wesentlich umfangreicher, aber auch strukturierter und einfacher zu bedienen geworden. Während die ersten Versionen die Funktionalität von Windows nicht erweiterten, sondern in erster Linie nur den direkten Hardware-Zugriff boten, gehen die aktuellen Versionen weit über die normale Windows-Funktionalität hinaus.
Microsoft behält es sich vor etwa alle 10 Monate eine neue DirectX-Generation herauszubringen, die meist einen erheblich erweiterten Umfang bietet, aber auch oft, zum Leid des Programmierers, in vielen Teilen eine Umstrukturierung erfahren hat. Neuere Versionen sind im Normalfall abwärtskompatibel, es werden also beispielsweise die DX8-Bibliotheken für VB bei der neuesten Ausgabe von DirectX9 mitgeliefert.
Die Programmierung von DirectX erfolgt objekt-orientiert. Die Menge an Klassen, Funktionen und Eigenschaften dürfte nicht nur zu Beginn jeden erschlagen.
Die einzige erwähnenswerte Alternative zu der Grafik-Komponente von DX stellt OpenGL dar (für Sound-Wiedergabe, Eingabegeräte, u.a. müssen weitere Bibliotheken herangezogen werden). Dieses System gilt aber als schwerer erlernbar als DirectX, unter anderem, weil Komfortfunktionen fehlen und man vieles zusätzlich selber implementieren muss. Außerdem ist kein umfassender Support gegeben.
Ein großer Vorteil dieser Bibliothek ist aber, dass OpenGL-Anwendungen nicht an Windows gebunden sind. Eine Portierung auf Linux oder andere Betriebssysteme lässt sich unter verhältnismäßig geringem Aufwand bewerkstelligen. OpenGL findet heutzutage weniger bei der Spielprogrammierung als viel mehr bei Anwendungen aus dem wissenschaftlich-technischen Bereich Gebrauch.
