Was heute das Fundament für die meisten PC-Spiele ist, begann vor fast 30 Jahren als verzweifelter Akt der Notwehr. Die Geschichte von DirectX ist nicht nur eine Chronik technischer Meilensteine, sondern auch der Evolution der Spielegrafik. Sie ist untrennbar mit dem Aufstieg von Windows zur dominanten Gaming-Plattform verbunden.

Die Anfänge: Das „Manhattan Project“ für Windows 95 (1994–1995)

Ende 1994 stand Microsoft vor einem Dilemma. Das mit Spannung erwartete Windows 95 sollte den PC-Markt revolutionieren, doch eine entscheidende Gruppe blieb skeptisch: die Spieleentwickler. Sie hielten am bewährten, aber veralteten MS-DOS fest. Der Grund war einfach: DOS bot direkten, ungefilterten Zugriff auf die Hardware – eine Notwendigkeit für die performance-hungrigen Spiele dieser Zeit. Windows hingegen galt mit seinen Abstraktionsebenen und seinem kooperativen Multitasking als langsam, unberechenbar und für Spiele schlicht ungeeignet.

Als der Microsoft-Evangelist Alex St. John bei Entwicklerstudios anfragte, ob sie ihr nächstes großes Spiel für Windows entwickeln würden, erntete er nur Spott und Ablehnung. Die Situation war kritisch. Ohne Spiele drohte Windows 95 ein entscheidender Teil des Heim-PC-Marktes zu entgleiten, der zunehmend von japanischen Spielkonsolen dominiert wurde.

Aus dieser Not heraus wurde intern das „Manhattan Project“ ins Leben gerufen. Der Name, eine bewusste Anspielung auf die Entwicklung der ersten Atombombe, spiegelte den Ehrgeiz und die Dringlichkeit wider, mit der Microsoft die Vormachtstellung im Gaming-Sektor erobern wollte. Ein kleines, schlagkräftiges Team aus den drei Entwicklern Alex St. John, Craig Eisler und Eric Engstrom erhielt den Auftrag, innerhalb von nur vier Monaten ein „Game SDK“ (Software Development Kit) zu entwickeln.

Am 30. September 1995 wurde das Ergebnis als DirectX 1.0 veröffentlicht. Die erste Version war ein Baukasten von Programmierschnittstellen (APIs), die den direkten Hardwarezugriff standardisieren sollten: DirectDraw für hardwarebeschleunigte 2D-Grafik, DirectSound für die Tonausgabe, DirectPlay für Netzwerkspiele und DirectInput für Eingabegeräte. Kurioserweise war der Name „DirectX“ eine spontane Schöpfung eines Journalisten, der die vielen „Direct“-Komponenten spöttisch zusammenfasste. Microsoft erkannte das Potenzial des Namens und übernahm ihn kurzerhand.

Der Durchbruch: DOOM95 als trojanisches Pferd

Eine API allein macht noch keinen Erfolg aus. Um die Entwicklerwelt zu überzeugen, benötigte Microsoft ein Aushängeschild – ein Spiel, das die Überlegenheit von DirectX unmissverständlich demonstrierte. Die Wahl fiel auf den damals größten Spieltitel der Welt: DOOM. In einem cleveren Schachzug wandte sich Microsoft an John Carmack von id Software. Das Angebot: Microsoft würde DOOM komplett kostenlos auf Windows portieren, ohne jegliche Bedingungen. Das Projekt wurde von Gabe Newell geleitet, dem späteren Gründer von Valve.

Das Ergebnis, DOOM95, war ein Paukenschlag. Es lief nicht nur stabiler und flüssiger als die DOS-Version, sondern bot auch höhere Auflösung von 640 × 480, 24 zusätzliche Audiokanäle und vor allem ein drastisch vereinfachtes Multiplayer-Set-up über DirectPlay. DOOM95, am 20. August 1996 veröffentlicht, wurde zum ersten jemals vorgestellten DirectX-Spiel und zum ultimativen Beweis für die Leistungsfähigkeit der neuen API. Der Erfolg war so groß, dass Microsoft-Gründer Bill Gates in einem legendären Werbevideo mit Schrotflinte und Trenchcoat durch die Gänge eines virtuellen Levels schritt. Da DOOM zu dieser Zeit auf mehr PCs installiert war als Windows 95 selbst, diente das Spiel als perfektes trojanisches Pferd, um DirectX auf Millionen von Rechnern zu etablieren.

Die Grundsteine der 3D-Grafik: DirectX 3.0 bis 6.0 (1996–1998)

Nachdem DirectX 2.0 aus internen Gründen übersprungen wurde, brachte DirectX 3.0 1996 eine entscheidende Neuerung: Direct3D. Damit hielt erstmals die Hardware-beschleunigte 3D-Grafik Einzug in die API. Optimierungen für die neuen MMX-Befehle der Pentium-Prozessoren und erweiterte Multiplayer-Fähigkeiten machten das Paket komplett.

Zwei Jahre später, 1998, setzte das verfügbare DirectX 6.0 neue Maßstäbe. Revolutionäre Funktionen wie Multitexturing (das Übereinanderlegen mehrerer Texturen auf einem Objekt für mehr Detailreichtum) und Bumpmapping (eine Technik, um Oberflächen durch Licht- und Schatteneffekte plastischer erscheinen zu lassen) wurden eingeführt. Zudem wurde AMDs 3DNow!-Befehlssatz unterstützt. Grafikkarten wie die damals gängige Riva 128 und Voodoo Graphics liefen deutlich schneller als mit DirectX 5.0. Erstmals schien DirectX leistungsfähig genug, um proprietäre, chip-spezifische APIs wie 3dfx‘ Glide überflüssig zu machen, das die genannten Funktionen auf den Voodoo-Grafikchips bereits unterstützte – aber eben nur auf jenen.

DirectX 7 mit Transform & Lighting (1999)

Das 1999 veröffentlichte DirectX 7.0 führte Hardware Transform & Lighting (T&L) ein. T&L verlagerte einen guten Teil der geometrischen Berechnungen und Beleuchtungseffekte erstmals vollständig von der CPU auf die Grafikkarte. Hardware T&L wurde zum Standard für moderne 3D-Anwendungen und ermöglichte deutlich komplexere Szenen ohne Leistungseinbußen.

Die Implementierung von DirectX 7 war jedoch nicht ohne Probleme. So einige Hardware-Hersteller kämpften mit der praktischen Umsetzung, etwa S3 mit ihrem Savage2000-Chip. S3 räumte ein, dass ihre ersten Treiber die T&L-Hardware noch gar nicht nutzten, da sich die Firma zunächst auf Stabilität konzentriert hatte. Erst spätere Treiberversionen sollten die volle DirectX-7-Funktionalität freischalten – ein Problem, das auch andere Hersteller plagte. Beim Savage2000 sollte das Warten allerdings vergeblich bleiben.

DirectX 7 etablierte die Grundlage für hardware-beschleunigte 3D-Grafik, die in den folgenden Jahren zum Standard werden sollte.

Die Ära der Shader: DirectX 8 und 9 (2000–2004)

Mit DirectX 8.0 erlebte die 3D-Grafik im Jahr 2000 ihre vielleicht größte Revolution. Microsoft fasste DirectDraw und Direct3D zu „DirectX Graphics“ zusammen und führte die Shader-Technik ein. Statt auf feste, in der Hardware verdrahtete Effekte angewiesen zu sein, konnten Entwickler nun mit Pixel- und Vertex-Shadern (Version 1.1) eigene kleine Programme schreiben, die direkt auf der GPU ausgeführt wurden. Dies ermöglichte erstmals hardwarebeschleunigte Pro-Pixel-Beleuchtung, komplexe Materialeffekte und nie dagewesene künstlerische Freiheit. Die erste Shader-Sprache war noch eine Art Assembler mit 17 Basisbefehlen und einer maximalen Länge von 128 Befehlen pro Programm für die Vertex-Shader.

DirectX 9.0, im Dezember 2002 freigegeben, trieb diese Entwicklung auf die Spitze. Mit der High Level Shader Language (HLSL) wurde die umständliche Assembler-Programmierung durch eine deutlich zugänglichere, C-ähnliche Syntax ersetzt. Die Komplexität der Shader-Programme wuchs exponentiell: Pixel-Shader konnten anfänglich ganze 96 Befehle verarbeiten, Vertex-Shader sogar 256, inklusive Sprüngen und Schleifen – spätere Ausbaustufen von DirectX 9.0 erweiterten diese Fähigkeiten mit Shader-Model 3.0 noch einmal deutlich.

Besonders die hochpräzisen Gleitkomma-Datenformate waren ein Segen, da sie Farbverfälschungen (Banding) bei komplexen Berechnungen verhinderten. Eine umstrittene, aber innovative Funktion war das Displacement Mapping, das geometrische Details zur Laufzeit erzeugte und so flachen Oberflächen echte Tiefe verlieh. Nvidia verzichtete bei der GeForce-FX-Serie bewusst auf eine optimierte Unterstützung, da das Unternehmen befürchtete, Entwickler würden die Kontrolle über das finale Erscheinungsbild des Spiels verlieren.

Die Vista-Kontroverse: DirectX 10 (2007)

Die Veröffentlichung von DirectX 10 im Jahr 2007 wurde von einer der umstrittensten Entscheidungen in Microsofts Gaming-Geschichte begleitet: Die API wurde exklusiv an das neue Betriebssystem Windows Vista gekoppelt. Microsoft wollte damit den Umstieg auf das neue OS erzwingen, doch der Schuss ging nach hinten los. Valve-Chef Gabe Newell nannte die Entscheidung in einem Interview einen „schrecklichen Fehler“. Laut den damaligen Steam-Statistiken nutzten zunächst nur verschwindend geringe zwei Prozent der Spieler eine DirectX-10-fähige Grafikkarte in Kombination mit Vista.

Es entstand ein Teufelskreis: Da Konsolen kein DirectX 10 unterstützten und die PC-Spielerbasis auf Windows XP verharrte, entwickelten die Studios weiterhin für den kleinsten gemeinsamen Nenner (DirectX 9) und ignorierten die neuen Funktionen. Die Exklusivität wurde zum Bumerang und bremste die technische Adaption für Jahre aus. Die Sorge vor einer solchen Fragmentierung wiederholte sich Jahre später, als AMD-Mitarbeiter Richard Huddy 2014 für Verwirrung sorgte, indem er erklärte, DirectX 12 würde nicht für Windows 7 erscheinen – eine Aussage, die Microsoft erst später korrigierte.

Effizienzsteigerung: DirectX 11 und 12 (2009–2015)

2009 brachte das neue Windows 7 die Schnittstelle DirectX 11 mit, die Microsoft später auch für Vista nachreichte. Die wichtigste Neuerung war DirectCompute; damit öffnete sich DirectX zudem erstmals für GPGPU-Anwendungen, also allgemeine Berechnungen auf dem Grafikchip. Aufseiten der Spielgrafik wurde um die Hardware-Tessellation das meiste Getöse veranstaltet. Dabei handelt es sich um eine Technik, die einfache 3D-Modelle mehr oder weniger dynamisch mit zusätzlichen Polygonen verfeinert, um höhere Detaildichte ohne CPU-Belastung zu erreichen, grob vereinfacht könnte man es auch als Geometrie-Kompression bezeichnen.

Mit DirectX 12, angekündigt 2014, vollzog Microsoft einen radikalen Strategiewechsel. Statt neuer Grafikeffekte stand erstmals die Effizienz im Vordergrund. „In den vergangenen zehn Jahren haben neue Direct3D-Versionen immer mehr Effekte hinzugefügt, die den Abstand zur Hardware vergrößerten“, erklärte AMD-Manager David Oldcorn damals auf der GDC. DirectX 12 sollte diesen Abstand drastisch verringern und Entwicklern einen hardwarenäheren Zugriff ermöglichen.

Die Demonstration auf der GDC war eindrücklich: Ein 3DMark-Test zeigte, wie DirectX 11 die Last ungleich auf vier CPU-Kerne verteilte und einen Kern an seine Grenzen brachte. DirectX 12 hingegen nutzte alle Kerne gleichmäßig und erzielte eine um 50 Prozent höhere Performance. Microsofts Versprechen war klar: „Konsolen-Effizienz auf Windows-PCs“.

Konkurrenz und kontinuierliche Evolution: Mantle, Vulkan und die Zukunft

Der Druck zur Effizienzsteigerung kam nicht von ungefähr. AMD hatte 2013 mit Mantle eine eigene Low-Level-API vorgestellt, die als direkte Antwort auf die Ineffizienzen von DirectX 11 konzipiert war. Mantle diente als wichtiger Wegbereiter und Ideengeber für DirectX 12 und die plattformübergreifende API Vulkan. Bereits 2015 stellte AMD die Weiterentwicklung von Mantle 1.0 ein und empfahl Entwicklern den Umstieg auf DirectX 12 oder Vulkan – ein Eingeständnis, dass der Kampf gegen die etablierten Standards nicht zu gewinnen war.

Heute liegt der Fokus auf der kontinuierlichen Weiterentwicklung. Statt auf ein „DirectX 13“ zu warten, wird DirectX 12 Ultimate als erweiterbare Plattform stetig ausgebaut. Funktionen wie DirectX Raytracing (DXR) für realistische Echtzeit-Spiegelungen und -Schatten, Mesh Shader zur Effizienzsteigerung bei der Darstellung komplexer Geometrien und Variable Rate Shading (VRS) werden sukzessive integriert. Diese Updates erfolgen direkt über Windows-Updates und stellen sicher, dass die Plattform-Einheitlichkeit zwischen PC und der Xbox Series X/S gewahrt bleibt.

Die neueste Entwicklung, DXR 1.2, verspricht massive Leistungssteigerungen beim Path Tracing durch Techniken wie Shader Execution Reordering (SER) und Opacity Micro-Maps. Damit schließt sich der Kreis: Von der ersten, einfachen 2D-Beschleunigung bis zur Simulation physikalisch korrekter Lichtstrahlen hat DirectX die Gaming-Welt in drei Jahrzehnten fundamental geprägt.

(vza)

Richard Seidl und Felix Winter sprechen über den Arbeitskreis Software-Qualität und Fortbildung (ASQF) und sein Netzwerk rund um Softwarequalität. Sie zeichnen den Weg von Erlangen (Hauptsitz des ASQF) über das German Testing Board (GTB) bis zum International Software Testing Qualifications Board (ISTQB) nach und zeigen, welchen Mehrwert eine Mitgliedschaft bietet: Wissen teilen, Kontakte knüpfen, in Fachgruppen, Quality Nights und Testing Days aktiv werden – vor Ort und online.

Im Ausblick geht es um KI im Testen, eine neue Fachgruppe sowie Weiterbildungen wie Secure Software Engineering.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Das Qualitätsnetzwerk ASQF – Felix Winter“ und steht auf YouTube bereit.

(mdo)

Das chinesische KI-Start-up DeepSeek hat mit V3.2-Exp eine experimentelle Version seines Sprachmodells veröffentlicht und gleichzeitig die Preise für seine API-Dienste um mehr als 50 Prozent gesenkt. Wie das Unternehmen auf seiner Hugging-Face-Seite mitteilte, markiert die neue Version einen Zwischenschritt zur nächsten Generation der KI-Architektur.

Das erst im Jahr 2023 gegründete Unternehmen, das Anfang des Jahres mit seinem R1-Modell für Aufsehen im Silicon Valley gesorgt hatte, arbeitet nach eigenen Angaben mit chinesischen Chipherstellern an der Weiterentwicklung seiner Modelle. Die neue Version V3.2-Exp baut auf dem älteren V3.1-Modell auf und führt eine neue Technik namens DeepSeek Sparse Attention (DSA) ein.

Die Sparse-Attention-Technologie soll die Effizienz bei der Verarbeitung langer Textsequenzen verbessern. Während herkömmliche Attention-Mechanismen bei großen Sprachmodellen alle Tokens gleichzeitig berücksichtigen, konzentriert sich DSA nur auf die relevantesten Bereiche des Inputs. Dies reduziert den Rechenaufwand laut DeepSeek erheblich, ohne die Qualität der Ausgabe wesentlich zu beeinträchtigen.

Parallel zur Modellveröffentlichung kündigte DeepSeek eine drastische Preissenkung für seine API-Dienste um mehr als 50 Prozent an. Die neuen Tarife gelten sofort und sollen dem Unternehmen helfen, mehr Nutzer zu gewinnen. Zum Vergleich bleibt das bisherige V3.1-Terminus-Modell bis zum 15. Oktober 2025 über eine temporäre API verfügbar.

Unterstützung durch Huawei und neue Datenformate

Huawei, der führende Anbieter von KI-Chips in China, kündigte an, dass seine Produkte das neueste DeepSeek-Modell unterstützen werden.

DeepSeek hat außerdem angegeben, dass die neuesten Versionen seiner Modelle mit simplen 8-Bit-Gleitkommawerten (Floating Point 8, FP8) umgehen kann, während an der Implementierung von BF16 (Brain Floating Point 16) gearbeitet wird. FP8 ermöglicht theoretisch Speichereinsparungen und schnellere Berechnungen, da es weniger Speicherplatz benötigt und die Matrizen vergleichsweise simpel sind. Obwohl FP8 weniger präzise ist als klassische Formate wie FP32, gilt es für KI-Anwendungen als ausreichend genau.

BF16 hingegen stellt einen Kompromiss zwischen Geschwindigkeit und Präzision dar. Die Unterstützung beider Formate soll es ermöglichen, große Modelle auch auf Hardware mit begrenzten Ressourcen zu betreiben.

API-Preise um 50 Prozent gesenkt

Mit der Preissenkung um mehr als 50 Prozent positioniert sich DeepSeek aggressiv im umkämpften KI-API-Markt. Das Unternehmen reiht sich damit in eine Reihe chinesischer Start-ups ein, die durch niedrige Preise Marktanteile gewinnen wollen. Input-Token kosten bei DeepSeek künftig 0,28 US-Dollar pro Million Token statt bislang 0,56 US-Dollar. Mit Cache sinkt der Preis sogar auf 0,028 US-Dollar. Eine Million Output-Token kosten 0,42 US-Dollar. Vorbehalte gegenüber chinesischen Modellen gibt es beim Datenschutz und der staatlichen Zensur Chinas.

(mki)