👗 🙍🏻 👼🏽 Direct3D vs OpenGL: eine Geschichte der Konfrontation 🕴🏿 🤶🏻 👨🏼‍🤝‍👨🏻

Bis heute wird im Internet darüber diskutiert, welche Grafik-API besser ist: Direct3D oder OpenGL? Trotz ihrer religiösen Natur bringen solche verbalen Schlachten nützliche Ergebnisse in Form guter historischer Rückblicke auf die Entwicklung hardwarebeschleunigter Grafiken.

Bild

Der Zweck dieses Beitrags ist es, eine dieser Exkursionen in die Geschichte zu übersetzen .geschrieben von Jason L. McKesson als Antwort auf die Frage "Warum bevorzugen Spieleentwickler Windows?" Es ist unwahrscheinlich, dass dieser Text die gestellte Frage beantwortet, aber er beschreibt die Entwicklungsgeschichte und die Konfrontation der beiden beliebtesten Grafik-APIs auf sehr farbenfrohe und ziemlich detaillierte Weise, sodass ich das Markup des Autors in der Übersetzung beibehalten habe. Der Text wurde Mitte 2011 verfasst und umfasst einen Zeitraum, der kurz vor dem Aufkommen von Direct3D und bis zum Zeitpunkt des Schreibens beginnt. Der Autor des Originaltextes ist ein erfahrener Spieleentwickler, ein aktiver Teilnehmer an StackOverflow und der Schöpfer eines umfangreichen Lehrbuchs über moderne 3D-Grafikprogrammierung. Also lasst uns Jason das Wort erteilen.

Vorwort

Bevor wir beginnen, möchte ich sagen, dass ich mehr über OpenGL als über Direct3D weiß. In meinem Leben habe ich keine einzige Codezeile in D3D geschrieben, aber ich habe OpenGL-Handbücher geschrieben. Aber worüber ich sprechen möchte, ist keine Frage von Vorurteilen, sondern von Geschichte.

Die Geburt eines Konflikts

Einmal, Anfang der 90er Jahre, sah sich Microsoft um. Sie haben gesehen, dass SNES und Sega Genesis sehr cool sind, man kann viele Actionspiele spielen und all das. Und sie sahen die Dos. Die Entwickler schrieben Dosovskie-Spiele als Konsole: nah am Eisen. Im Gegensatz zu Konsolen, bei denen der Entwickler wusste, welche Art von Hardware der Benutzer haben würde, mussten dos-Entwickler jedoch unter vielen Konfigurationen schreiben. Und das ist viel komplizierter als es scheint.

Microsoft hatte jedoch ein größeres Problem: Windows. Sie sehen, Windows wollte die Hardware im Gegensatz zu DOS vollständig besitzen, was Entwicklern erlaubte, alles zu tun. Der Besitz von Eisen ist für die Wechselwirkung zwischen Anwendungen erforderlich. Aber diese Art der Interaktion ist genau das, was sie hassen.Spieleentwickler, weil es wertvolle Ressourcen verbraucht, die sie für alle möglichen coolen Dinge verwenden könnten.

Um die Spieleentwicklung unter Windows voranzutreiben, benötigte Microsoft eine einheitliche API, die auf niedriger Ebene verfügbar war, unter Windows ohne Leistungseinbußen funktionierte und mit verschiedener Hardware kompatibel war . Eine einzige API für Grafik-, Sound- und Eingabegeräte.

So wurde DirectX geboren.

Einige Monate später erschienen 3D-Beschleuniger. Und Microsoft geriet in Schwierigkeiten. Tatsache ist, dass DirectDraw, eine Grafikkomponente von DirectX, nur mit 2D-Grafiken arbeitete: Es ordnete Grafikspeicher zu und führte schnelle Bitoperationen zwischen verschiedenen Speichersektoren durch.

Daher kaufte Microsoft Software von Drittanbietern und verwandelte sie in Direct3D Version 3. Er wurde gescholtenabsolut alles. Und es gab einen Grund: Das Lesen des Codes auf D3D v3 sah aus wie eine Entschlüsselung der Schriftsprache einer ausgestorbenen alten Zivilisation.

Der alte John Carmack von Id Software sah sich diese Schande an, sagte "Ja, es ging ..." und beschloss, mit einer anderen API zu schreiben: OpenGL.

Die andere Seite dieser verwirrenden Geschichte war jedoch, dass Microsoft mit SGI zusammengearbeitet hat, um OpenGL für Windows zu implementieren. Die Idee war, Entwickler typischer GL-Anwendungen für Workstations zu gewinnen: CAD, Modellierungssysteme und dergleichen. Die Spiele waren das Letzte, was sie dachten. Dies betraf hauptsächlich Windows NT, aber Microsoft entschied sich, OpenGL auch zu Windows 95 hinzuzufügen.

Um Entwickler von Software für Workstations unter Windows anzulocken, hat Microsoft beschlossen, sie mit Zugriff auf neue 3D-Beschleuniger zu bestechen. Sie implementierten ein Protokoll für installierte Client-Treiber: Eine Grafikkarte könnte die OpenGL-Software von Microsoft durch ihre Hardware-Implementierung ersetzen. Der Code verwendete automatisch Hardware OpenGL, falls verfügbar.

In jenen Tagen hatten Consumer-Grafikkarten jedoch keine OpenGL-Unterstützung. Dies hinderte Carmack nicht daran, Quake auf einer SGI-Workstation auf OpenGL zu portieren. In der Readme-Datei von GLQuake können Sie Folgendes lesen:

, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

Dies war die Geburt der miniGL-Treiber. Sie entwickelten sich schließlich zu vollwertigen OpenGL-Implementierungen, sobald die Hardware leistungsfähig genug wurde, um diese Funktionalität in der Hardware zu unterstützen. nVidia war das erste Unternehmen, das eine vollständige Implementierung von OpenGL anbot. Andere Anbieter waren immer noch langsam, was einer der Gründe für den Übergang zu Direct3D war, der von einer größeren Auswahl an Geräten unterstützt wurde. Am Ende blieben nur nVidia und ATI (jetzt AMD) übrig, und beide hatten gute OpenGL-Implementierungen.

Morgendämmerung von OpenGL

Die Teilnehmer sind also definiert: Direct3D gegen OpenGL. Dies ist wirklich eine erstaunliche Geschichte, wenn man bedenkt, wie schlecht die D3D v3 war.

Das OpenGL Architectural Review Board (ARB) ist die Organisation, die für die Wartung und Entwicklung von OpenGL verantwortlich ist. Sie geben viele Erweiterungen frei, enthalten ein Repository mit Erweiterungen und erstellen neue Versionen der API. ARB ist ein Komitee, das sich aus einer großen Anzahl von Akteuren der Computergrafikindustrie und einigen Betriebssystemherstellern zusammensetzt. Apple und Microsoft waren zu unterschiedlichen Zeiten auch Mitglieder von ARB.

3Dfx betritt die Szene mit seinem Voodoo2. Dies ist die erste Grafikkarte, mit der Sie Multitexturing durchführen können, die zuvor in OpenGL nicht bereitgestellt wurde. Während 3Dfx stark gegen OpenGL war, war nVidia, der nächste Hersteller des Multitexturing-Chips (TNT1), verrückt nach OpenGL. Dann veröffentlichte ARB die Erweiterung GL_ARB_multitexture, die den Zugriff auf mehrere Texturen ermöglichte.

In der Zwischenzeit wird Direct3D v5 angezeigt. Jetzt ist D3D wirklich eine API geworden , kein Unsinn. Was ist das Problem? In Abwesenheit von Multitexturing.

Ups

Dies verursachte jedoch keine derartigen Unannehmlichkeiten, da fast niemand mehrere Texturen verwendete. Multitexturing beeinträchtigt die Leistung fast nicht, und in vielen Fällen ist der Unterschied vor dem Hintergrund von Multi-Pass unsichtbar. Und natürlich lieben Spieleentwickler ihre Spiele sehr, wenn sie sicher auf der alten Hardware arbeiten, die keine Unterstützung für mehrere Texturen bietet. Daher wurden viele Spiele ohne diese Hardware veröffentlicht.

D3D atmete erleichtert auf.

Die Zeit verging und nVidia brachte die GeForce 256 auf den Markt (nicht zu verwechseln mit der allerersten GeForce GT-250) und stoppte den Kampf auf dem Grafikkartenmarkt für die nächsten zwei Jahre. Der Hauptwettbewerbsvorteil dieses Boards war die Fähigkeit, Scheitelpunkte und Beleuchtung (Transformation & Beleuchtung, T & L) in Hardware zu transformieren. Aber das ist nicht alles: nVidia OpenGL so sehr geliebt , dass ihr T & L-Engine tatsächlich gewesen OpenGL. Fast buchstäblich! Soweit ich weiß, haben einige ihrer Register direkt numerische Werte von Variablen vom Typ GLenum erhalten.

Direct3D v6 kommt heraus. Schließlich kamen mehrere Texturen rechtzeitig an ... aber ohne die Hardware-T & L. OpenGL immerEs gab eine T & L-Pipeline, die jedoch vor GeForce 256 in Software implementiert war. Für nVidia erwies es sich daher als recht einfach, die Softwareimplementierung in eine Hardwarelösung umzuwandeln. In D3D erschien Hardware T & L nur in der siebten Version.

Morgendämmerung des Shader-Zeitalters, OpenGL im Dunkeln

Dann kam GeForce 3. Gleichzeitig passierten viele interessante Dinge.

Microsoft entschied, dass sie nicht mehr zu spät kommen würden. Anstatt zu prüfen, was nVidia tun wird, und ihre Entwicklung bereits post-factum zu kopieren, traf Microsoft daher eine erstaunliche Entscheidung: Gehen Sie und sprechen Sie. Und sie verliebten sich und bekamen eine gemeinsame kleine Konsole.

Die laute Scheidung ereignete sich später, aber das ist eine ganz andere Geschichte.

Für den PC-Markt bedeutete dies, dass GeForce 3 gleichzeitig mit D3D v8 herauskam und es leicht zu erkennen ist, wie sich GeForce 3 auf die D3D v8-Shader auswirkte. Die Pixel-Shader von Shader Model 1.0 waren sehrstark geschärft für nVidia-Geräte. Es wurde kein einziger Versuch unternommen, nVidia von Eisen zu abstrahieren. Für das Shader-Modell 1.0 wurde die GeForce 3 entwickelt.

Als ATI mit seiner Radeon 8500 in das Grafik-Performance-Rennen einstieg, gab es ein Problem. Die Radeon 8500-Pixel-Pipeline erwies sich als leistungsstärker als die nVidia. Aus diesem Grund hat Microsoft das Shader Model 1.1 veröffentlicht, für das der 8500 im Grunde genommen

gedacht ist. Es klingt nach einer D3D-Niederlage, aber Erfolg und Misserfolg sind relative Begriffe. Tatsächlich erwartete OpenGL einen epischen Fehler.

NVidia mochte OpenGL sehr und nach der Veröffentlichung von GeForce 3 veröffentlichten sie eine ganze Reihe von Erweiterungen für OpenGL. ProprietärErweiterungen, die nur auf nVidia funktionierten. Als das 8500-Board erschien, konnte es natürlich keines von ihnen verwenden.

Auf D3D 8 können Sie also mindestens SM 1.0-Shader ausführen. Natürlich musste ich neue Shader schreiben, um die ganze Coolness des 8500 nutzen zu können, aber der Code funktionierte zumindest .

Um alle Shadern auf der OpenGL Radeon 8500, hatte ATI einige Erweiterungen zu OpenGL zu entwickeln. Proprietäre Erweiterungen, die nur mit ATI funktionierten. Damit Entwickler erklären konnten, dass sie Shader an ihre Engine angeschraubt hatten, mussten sie separaten Code für nVidia und separaten Code für ATI schreiben.

Sie fragen sich vielleicht: "Und wo war das ARB-Komitee, das OpenGL flott unterstützen sollte?" Und dort landeten viele Komitees: Sie saßen und waren dumm.

Bitte beachten Sie, dass ich oben ARB_multitexture erwähnt habe, da diese Erweiterung stark in die gesamte Situation involviert ist. Einem externen Beobachter schien es, dass ARB die Idee von Shadern generell vermeiden möchte. Sie entschieden, dass, wenn sie einer festen Pipeline genügend Konfigurierbarkeit verleihen, diese in ihren Fähigkeiten einer programmierbaren Shader-Pipeline entspricht.

ARB hat nacheinander Erweiterungen veröffentlicht. Jede Erweiterung mit den Worten "textur_env" im Namen war ein Versuch, dieses alternde Design zu reparieren. Schauen Sie sich die Liste der Erweiterungen an: Acht solcher Erweiterungen wurden veröffentlichtTeile, und viele von ihnen wurden in die Kernfunktionalität von OpenGL übersetzt.

Zu dieser Zeit war Microsoft Teil von ARB und ließ es nur für die Veröffentlichung von D3D 9 übrig. Vielleicht hat Microsoft OpenGL auf irgendeine Weise sabotiert. Persönlich bezweifle ich diese Theorie aus zwei Gründen. Erstens müssten sie die Unterstützung anderer Mitglieder des Ausschusses sicherstellen, da jedes Mitglied nur eine Stimme hat. Zweitens, und was noch wichtiger ist, brauchte das Komitee nicht die Hilfe von Microsoft, um alles zu vermasseln, was wir später sehen werden.

Infolgedessen erwachte ARB, höchstwahrscheinlich unter dem Druck von ATI und nVidia (beide sind aktive Teilnehmer), schließlich und führte Assembler-Shader in den Standard ein.

Willst du eine noch verrücktere Geschichte?

Hardware T & L. Dies ist, was OpenGL ursprünglich hatte.. Um die höchstmögliche T & L-Leistung der Hardware zu erzielen, müssen Sie Vertex-Daten auf der GPU speichern. Dennoch ist die GPU der Hauptverbraucher von Vertex-Daten.

In D3D v7 führte Microsoft das Konzept der Vertex-Puffer ein, die Speicherblöcke in der GPU zuweisen und dort Vertex-Daten platzieren.

Möchten Sie wissen, wann gleichwertige Funktionen in OpenGL verfügbar sind? Ja, nVidia hat als größter OpenGL-Fan seine Erweiterung zum Speichern von Vertex-Arrays auf der GPU bereits zum Zeitpunkt der Veröffentlichung von GeForce 256 veröffentlicht. Aber wann hat ARB solche Funktionen eingeführt?

Zwei Jahre später. Es war danachwie es Vertex- und Fragment-Shader (Pixel in Bezug auf D3D) genehmigt hat. ARB brauchte so viel Zeit, um eine plattformübergreifende Lösung zum Speichern von Vertex-Daten im GPU-Speicher zu entwickeln. Und das ist , was Sie brauchen , um Hardware-T & L maximale Kapazität erreicht hat.

Eine Sprache, um sie alle zu töten

OpenGL ist also seit einiger Zeit kaputt. In der GPU gab es keine plattformübergreifenden Shader und keinen hardwareunabhängigen Vertex-Speicher, während D3D-Benutzer beides genossen. Könnte es noch schlimmer werden?

Man könnte sagen, dass es könnte. Treffen Sie: 3D Labs .

Sie fragen: Wer sind sie? Sie sind eine tote Firma, die ich für den wahren Killer von OpenGL halte. Natürlich machte das allgemeine Versagen des Komitees OpenGL anfällig, während es D3D in Stücke reißen sollte. Aber meiner Meinung nach ist 3D Labs vielleicht der einzige Grund für die aktuelle Marktposition von OpenGL. Was haben sie dafür getan?

Sie entwickelten eine Shader-Sprache für OpenGL.

3D Labs war eine aussterbende Firma. Ihre teuren GPUs wurden durch den ständig wachsenden Druck von nVidia aus dem Workstation-Markt verdrängt. Und im Gegensatz zu nVidia wurden 3D Labs nicht auf dem Verbrauchermarkt eingeführt. Der Sieg von nVidia würde für 3D Labs den Tod bedeuten.

Was letztendlich passiert ist.

Um in einer Welt über Wasser zu sein, in der ihre Produkte nicht benötigt wurden, zeigten sich 3D Labs auf der Spieleentwicklerkonferenz mit einer Präsentation dessen, was sie "OpenGL 2.0" nannten. Es war eine OpenGL-API, die von Grund auf neu geschrieben wurde. Und das machte Sinn, denn damals war die OpenGL-API voller Müll (der jedoch bis heute dort bleibt). Schauen Sie sich zumindest an, wie esoterisch das Laden und Binden von Texturen erfolgt.

Ein Teil ihres Vorschlags war die Shader-Sprache. Ja, das ist er. Im Gegensatz zu den vorhandenen plattformübergreifenden Erweiterungen war ihre Shader-Sprache jedoch "High Level" (C ist ein High Level für die Shader-Sprache).

Gleichzeitig arbeitete Microsoft an einer eigenen Shader-Sprache. Was sie, einschließlich all ihrer kollektiven Vorstellungskraft, als ... High Level Shader Language (HLSL) bezeichneten. Ihre Herangehensweise an die Sprache war jedoch grundlegend anders.

Das größte Problem bei 3D Labs war, dass es einbettbar war. Microsoft hat seine eigene Sprache vollständig bestimmt. Sie veröffentlichten einen Compiler, der Assembly-Code für SM 2.0-Shader (oder höher) generierte, der wiederum an D3D weitergeleitet werden konnte. In den Tagen von D3D v9 hat HLSL D3D nie direkt berührt. Er war eine gute, aber optionale Abstraktion. Der Entwickler hatte immer die Möglichkeit, den Compiler-Auspuff für maximale Leistung zu optimieren.

3D Labs hatte nichts davon. Sie geben dem Treiber eine C-ähnliche Sprache und es wird ein Shader erstellt. Das ist alles Kein Assembler-Shader, nichts, was etwas anderem zugeführt werden kann. Nur ein OpenGL-Objekt, das einen Shader darstellt.

Für OpenGL-Benutzer bedeutete dies, dass sie den Launen von OpenGL-Entwicklern ausgesetzt waren, die gerade gelernt hatten, Assembler-ähnliche Sprachen zu kompilieren. OpenGL Shader Language Compiler (GLSL) toben über Fehler. Um die Sache noch schlimmer zu machen: Wenn Sie den Shader dazu bringen konnten, auf verschiedenen Plattformen korrekt zu kompilieren (was an sich schon eine große Leistung war), unterlag er immer noch Optimierern jener Zeit, die nicht so optimal waren, wie sie sein konnten.

Dies war ein großer, aber nicht der einzige Nachteil von GLSL. Weit davon entfernt, der einzige zu sein.

In D3D können Sie wie in den alten OpenGL-Assembler-Sprachen Vertex- und Fragment-Shader auf jede mögliche Weise mischen und anpassen. Sie können jeden Vertex-Shader mit jedem kompatiblen Fragment-Shader verwenden, wenn diese über dieselbe Schnittstelle interagieren. Darüber hinaus war sogar eine gewisse Inkompatibilität zulässig: Beispielsweise konnte der Vertex-Shader einen Wert ausgeben, der vom Fragment-Shader nicht verwendet wurde.

In GLSL gab es nichts Vergleichbares. Der Scheitelpunkt und die Fragment-Shader verschmolzen zu einem sogenannten "Software-Objekt" von 3D Labs. Für die gemeinsame Verwendung mehrerer Vertex- und Fragment-Shader in verschiedenen Kombinationen war es daher erforderlich, mehrere Programmobjekte zu erstellen. Dies verursachte das zweitgrößte Problem.

3D Labs hielten sie für die klügsten. Sie nahmen C / C ++ als Grundlage für das GLSL-Kompilierungsmodell. In diesem Fall nehmen Sie eine C-Datei und kompilieren sie in eine Objektdatei. Nehmen Sie dann mehrere Objektdateien und komponieren Sie sie zu einem Programm. So kompiliert GLSL: Zuerst kompilieren Sie einen Vertex- oder Fragment-Shader in ein Shader-Objekt, fügen diese Objekte dann in ein Programmobjekt ein und fügen sie schließlich zu einem Programm zusammen.

Theoretisch konnten so coole Dinge wie "Bibliotheks" -Shader angezeigt werden, die Code enthalten, der vom Haupt-Shader aufgerufen wird. In der Praxis führte dies dazu, dass Shader zweimal kompiliert wurden: Einmal in der Kompilierungsphase und ein zweites Mal in der Kompilierungsphase. Insbesondere der Compiler von nVidia war dafür bekannt. Es wurde kein Zwischenobjektcode generiert. Er hat zu Beginn kompiliert, das Ergebnis verworfen und im Stadium der Kompilierung erneut kompiliert.

Um den Vertex-Shader an zwei verschiedene Fragment-Shader anzuhängen, war es daher erforderlich, viel mehr als in D3D zu kompilieren. Insbesondere wenn man bedenkt, dass die gesamte Kompilierung offline erfolgt und nicht bevor das Programm direkt ausgeführt wird.

GLSL hatte andere Probleme. Vielleicht wäre es falsch, 3D Labs die Schuld an allen Fehlern zu geben, da ARB am Ende die Sprache der Shader in OpenGL genehmigt und aufgenommen hat (aber nichts anderes aus den Vorschlägen von 3DLabs). Die ursprüngliche Idee war jedoch immer noch für 3D Labs.

Und jetzt das Traurigste: 3D Labs hatten (meistens) recht . GLSL ist zu diesem Zeitpunkt keine Vektorsprache wie HLSL. Dies geschah, weil die Hardware von 3D Labs skalar war (wie die moderne Hardware von nVidia) und sie bei der Wahl der Richtung, der viele Gerätehersteller später folgten, völlig richtig waren.

Sie hatten Recht mit der Wahl des Kompilierungsmodells für die "Hochsprache". Sogar D3D kam endlich dazu.

Das Problem ist, dass 3D Labs zur falschen Zeit richtig waren . Und bei dem Versuch, vorzeitig in die Zukunft zu gelangen, bei dem Versuch, für die Zukunft gerüstet zu sein, legen sie die Gegenwart beiseite. Es sieht aus wie die T & L-Funktionalität in OpenGL, die schon immer darin enthalten war. Außer die OpenGL T & L-Pipeline war nützlichund vor dem Aufkommen von Hardware T & L war GLSL eine Belastung, bevor der Rest der Welt ihn einholte.

GLSL ist jetzt eine gute Sprache . Aber was war damals? Er war schrecklich. Und OpenGL litt darunter.

Auf dem Weg zur Apotheose

Ich unterstütze die Ansicht, dass 3D Labs OpenGL einen tödlichen Schlag versetzt hat, aber der letzte Nagel im Sarg wurde von ARB selbst erzielt.

Sie haben diese Geschichte vielleicht gehört. In den Tagen von OpenGL 2.1 hatte OpenGL große Probleme. Er hatte eine Menge Kompatibilität. Die API war nicht mehr einfach zu bedienen. Eines kann auf fünf verschiedene Arten geschehen, und es ist nicht klar, welches schneller ist. Sie könnten OpenGL mit einfachen Tutorials „lernen“, aber Sie haben OpenGL nicht gelernt, das echte Grafikleistung und -leistung bietet.

ARB beschloss, einen weiteren Versuch zu unternehmen, OpenGL zu erfinden. Es war wie "OpenGL 2.0" von 3D Labs, aber besser, weil ARB hinter diesem Versuch stand. Sie nannten es "Longs Peak".

Was ist so schlimm daran, ein wenig Zeit damit zu verbringen, die API zu verbessern? Die schlechte Nachricht ist, dass Microsoft in einer ziemlich prekären Lage ist. Dies war die Zeit für ein Upgrade auf Vista.

In Vista hat Microsoft beschlossen, überfällige Änderungen an Grafiktreibern vorzunehmen. Sie zwangen die Treiber, sich zur Virtualisierung des Grafikspeichers und vieler anderer an das Betriebssystem zu wenden.

Sie können lange über die Vorzüge dieses Ansatzes streiten und darüber, ob dies überhaupt möglich war, aber die Tatsache bleibt: Microsoft hat D3D 10 nur für Vista und höher entwickelt. Selbst auf einer D3D- kompatiblen Hardware war es unmöglich, eine D3D-Anwendung ohne Vista auszuführen.

Sie erinnern sich vielleicht, dass Vista ... sagen wir, es hat nicht sehr gut funktioniert. Wir hatten also ein gemächliches Betriebssystem, eine neue API, die nur auf diesem Betriebssystem funktioniert, und eine neue Generation von Hardware, die diese API und dieses Betriebssystem benötigt, um mehr als nur die Leistung der vorherigen Generation zu übertreffen.

Entwickler könnten jedoch D3D 10-Level-Funktionen über OpenGL verwenden. Das heißt, sie könnten, wenn ARB nicht damit beschäftigt wäre, an Long Peaks zu arbeiten.

ARB hat gut anderthalb bis zwei Jahre an der Verbesserung der API gearbeitet. Als OpenGL 3.0 veröffentlicht wurde, war der Übergang zu Vista beendet, Windows 7 war auf dem Weg und Spieleentwickler kümmerten sich nicht mehr um die Funktionalität der D3D 10-Version. Am Ende funktionierte die Ausrüstung für D3D 10 perfekt mit Anwendungen auf D3D 9. Mit der zunehmenden Portierung von PC auf Konsole (oder mit dem Übergang von PC-Entwicklern zum Konsolenmarkt) benötigten Entwickler immer weniger die Funktionalität von D3D 10.

Wenn Entwickler auch unter Windows XP auf diese Funktionalität zugreifen könnten, könnte die Entwicklung von OpenGL eine lebensspendende Belastung für Lebendigkeit darstellen. Aber ARB hat diese Gelegenheit verpasst. Möchten Sie wissen, was das Schlimmste ist?

ARB fehlgeschlagenErfinden Sie die API von Grund auf neu, obwohl Sie zwei kostbare Jahre damit verbracht haben, dies zu tun. Daher gaben sie den Status Quo zurück und fügten nur einen Mechanismus hinzu, um die Funktionalität für veraltet zu erklären.

Infolgedessen verpasste ARB nicht nur die wichtigsten Gelegenheiten, sondern versäumte es auch, die Arbeit zu erledigen, die sie zu dieser Unterlassung führte. Es war ein epischer Fehlschlag in alle Richtungen.

Dies ist die Geschichte der Konfrontation zwischen OpenGL und Direct3D. Die Geschichte verpasster Gelegenheiten, größter Dummheit, absichtlicher Rücksichtslosigkeit und banaler Absurditäten.