it-swarm-eu.dev

Warum bevorzugen Spieleentwickler Windows?

Ist DirectX einfacher oder besser als OpenGL, auch wenn OpenGL plattformübergreifend ist? Warum sehen wir keine wirklich leistungsstarken Spiele für Linux wie für Windows?

396
M.Sameer

Viele der Antworten hier sind wirklich sehr, sehr gut. Aber das Problem OpenGL und Direct3D (D3D) sollte wahrscheinlich behoben werden. Und das erfordert ... eine Geschichtsstunde.

Und bevor wir anfangen, weiß ich viel mehr über OpenGL als über Direct3D . Ich habe noch nie in meinem Leben eine Zeile D3D-Code geschrieben und Tutorials zu OpenGL geschrieben. Was ich also sagen werde, ist keine Frage der Voreingenommenheit. Es ist einfach eine Frage der Geschichte.

Geburt des Konflikts

Eines Tages, irgendwann in den frühen 90ern, sah sich Microsoft um. Sie sahen, dass die SNES und Sega Genesis fantastisch waren und viele Actionspiele und so weiter führten. Und sie sahen DOS . Entwickler codierten DOS-Spiele wie Konsolenspiele: direkt auf das Metall. Im Gegensatz zu Konsolen, bei denen ein Entwickler, der ein SNES-Spiel erstellt hatte, wusste, über welche Hardware der Benutzer verfügen würde, mussten DOS-Entwickler für mehrere mögliche Konfigurationen schreiben. Und das ist eher schwieriger als es sich anhört.

Und Microsoft hatte ein größeres Problem: Windows. Windows wollte die Hardware besitzen, im Gegensatz zu DOS, mit dem Entwickler so ziemlich alles tun konnten. Der Besitz der Hardware ist erforderlich, um zwischen den Anwendungen zusammenarbeiten zu können. Kooperation ist genau das, was Spieleentwickler hassen, weil sie wertvolle Hardwareressourcen beanspruchen, die sie verwenden könnten, um großartig zu sein.

Um die Spieleentwicklung unter Windows voranzutreiben, benötigte Microsoft eine einheitliche API, die auf niedriger Ebene lief, unter Windows lief, ohne von ihr verlangsamt zu werden, und vor allem hardwareübergreifend. Eine einzige API für alle Grafik-, Sound- und Eingabehardware.

Somit wurde DirectX geboren.

Einige Monate später wurden 3D-Beschleuniger geboren. Und Microsoft geriet in Schwierigkeiten. Siehe, DirectDraw, die Grafikkomponente von DirectX, befasste sich nur mit 2D-Grafiken: Zuweisen von Grafikspeicher und Ausführen von Bit-Blits zwischen verschiedenen zugewiesenen Speicherabschnitten.

Also hat Microsoft ein bisschen Middleware gekauft und daraus Direct3D Version 3 gemacht. Es wurde universell verleumdet. Und das aus gutem Grund; Das Betrachten des D3D v3-Codes ist wie ein Blick in die Bundeslade.

Der alte John Carmack von Id Software warf einen Blick auf diesen Müll und sagte: "Scheiß drauf!" und beschlossen, in Richtung einer anderen API zu schreiben: OpenGL.

Sehen Sie, ein anderer Teil des vielköpfigen Tieres, das Microsoft ist, war mit SGI an einer OpenGL-Implementierung für Windows beschäftigt. Die Idee hier war, Entwickler typischer GL -Anwendungen: Workstation-Apps. CAD Tools, Modellierung, so etwas. Spiele waren am weitesten entfernt) Dies war in erster Linie eine Windows NT-Sache, aber Microsoft hat beschlossen, sie auch zu Win95 hinzuzufügen.

Um Workstation-Entwickler für Windows zu begeistern, hat Microsoft beschlossen, sie mit Zugriff auf diese neuen 3D-Grafikkarten zu bestechen. Microsoft hat das Installable Client Driver-Protokoll implementiert: Ein Grafikkartenhersteller könnte die OpenGL-Softwareimplementierung von Microsoft durch eine hardwarebasierte Implementierung überschreiben. Code könnte automatisch nur eine Hardware-OpenGL-Implementierung verwenden, wenn eine verfügbar ist.

In den Anfangszeiten hatten Videokarten auf Verbraucherebene jedoch keine Unterstützung für OpenGL. Das hinderte Carmack nicht daran, Quake nur auf seiner SGI-Workstation nach OpenGL (GLQuake) zu portieren. Wie wir aus der GLQuake-Readme lesen können:

Theoretisch läuft glquake auf jedem kompatiblen OpenGL, das die Erweiterungen der Texturobjekte unterstützt. Wenn es sich jedoch nicht um eine sehr leistungsstarke Hardware handelt, die alles Notwendige beschleunigt, ist das Spiel nicht akzeptabel. Wenn Software-Emulationspfade durchlaufen werden müssen, wird die Leistung wahrscheinlich deutlich unter einem Frame pro Sekunde liegen.

Zu diesem Zeitpunkt (März 1997) ist die einzige Standard-OpenGL-Hardware, die Glquake vernünftig spielen kann, ein Intergraph-Realizm, eine SEHR teure Karte. 3dlabs hat seine Leistung erheblich verbessert, aber mit den verfügbaren Treibern ist es immer noch nicht gut genug, um zu spielen. Einige der aktuellen 3dlabs-Treiber für Glint- und Permedia-Boards können NT auch beim Beenden eines Vollbildlaufs zum Absturz bringen. Ich empfehle daher nicht, glquake auf 3dlabs-Hardware auszuführen.

3dfx hat eine opengl32.dll bereitgestellt, die alles implementiert, was glquake benötigt, aber es ist keine vollständige opengl-Implementierung. Es ist sehr unwahrscheinlich, dass andere OpenGL-Anwendungen damit funktionieren. Betrachten Sie es daher im Grunde genommen als „Glquake-Treiber“.

Dies war die Geburt der miniGL-Treiber. Diese entwickelten sich schließlich zu vollständigen OpenGL-Implementierungen, da die Hardware leistungsfähig genug wurde, um die meisten OpenGL-Funktionen in Hardware zu implementieren. nVidia war das erste Unternehmen, das eine vollständige OpenGL-Implementierung anbot. Viele andere Anbieter hatten Probleme, weshalb Entwickler Direct3D bevorzugten: Sie waren mit einer größeren Bandbreite an Hardware kompatibel. Schließlich blieben nur nVidia und ATI (jetzt AMD) übrig, und beide hatten eine gute OpenGL-Implementierung.

OpenGL Aszendent

Damit ist die Bühne bereit: Direct3D vs. OpenGL. Es ist wirklich eine erstaunliche Geschichte, wenn man bedenkt, wie schlecht D3D v3 war.

Das OpenGL Architectural Review Board (ARB) ist die Organisation, die für die Wartung von OpenGL verantwortlich ist. Sie stellen eine Reihe von Erweiterungen aus, verwalten das Erweiterungsrepository und erstellen neue Versionen der API. Der ARB ist ein Komitee, das sich aus vielen Akteuren der Grafikbranche sowie einigen Betriebssystemherstellern zusammensetzt. Apple und Microsoft waren zu verschiedenen Zeiten Mitglied des ARB.

3Dfx kommt mit dem Voodoo2 heraus. Dies ist die erste Hardware, die Multitexturing ausführen kann, was OpenGL zuvor nicht konnte. Während 3Dfx stark gegen OpenGL war, war NVIDIA, Hersteller des nächsten Multitexturing-Grafikchips (TNT1), begeistert. Daher gab der ARB eine Erweiterung heraus: GL_ARB_multitexture, die den Zugriff auf Multitexturing ermöglichen würde.

Inzwischen kommt Direct3D v5 heraus. Jetzt ist D3D eine tatsächliche [~ # ~] api [~ # ~] geworden, anstatt etwas, das eine Katze erbrechen könnte. Das Problem? Keine Multitexturierung.

Hoppla.

Nun, das würde nicht annähernd so weh tun, wie es hätte sein sollen, weil die Leute Multitexturing nicht viel nutzten. Nicht direkt. Multitexturing beeinträchtigte die Leistung erheblich, und in vielen Fällen hat es sich im Vergleich zu Multi-Passing nicht gelohnt. Und natürlich lieben es Spieleentwickler, sicherzustellen, dass ihre Spiele auf älterer Hardware funktionieren, die keine Multitexturierung hatte, so viele Spiele werden ohne diese ausgeliefert.

D3D erhielt somit einen Aufschub.

Die Zeit vergeht und NVIDIA setzt die GeForce 256 (nicht GeForce GT-250; die allererste GeForce) ein und beendet damit den Wettbewerb bei Grafikkarten für die nächsten zwei Jahre. Das Hauptverkaufsargument ist die Fähigkeit, Vertex-Transformation und Beleuchtung (T & L) in Hardware durchzuführen. Nicht nur das, NVIDIA liebte OpenGL so sehr, dass ihre T & L-Engine effektiv war OpenGL. Fast wörtlich; Soweit ich weiß, haben einige ihrer Register tatsächlich OpenGL-Enumeratoren direkt als Werte verwendet.

Direct3D v6 kommt heraus. Endlich Multitexture, aber ... keine Hardware-AGB. OpenGL hatte immer eine T & L-Pipeline, obwohl sie vor dem 256 in Software implementiert war. Daher war es für NVIDIA sehr einfach, ihre Softwareimplementierung einfach in eine Hardwarelösung umzuwandeln. Es würde nicht bis D3D v7 dauern, bis D3D endlich Hardware-T & L-Unterstützung hatte.

Dawn of Shaders, Dämmerung von OpenGL

Dann kam GeForce 3 heraus. Und viele Dinge passierten gleichzeitig.

Microsoft hatte beschlossen, dass sie nicht wieder zu spät kommen würden. Anstatt zu schauen, was NVIDIA tat, und es dann nachträglich zu kopieren, nahmen sie die erstaunliche Position ein, zu ihnen zu gehen und mit ihnen zu sprechen. Und dann verliebten sie sich und hatten eine kleine Konsole zusammen.

Eine unordentliche Scheidung folgte später. Aber das ist für eine andere Zeit.

Für den PC bedeutete dies, dass GeForce 3 gleichzeitig mit D3D v8 herauskam. Und es ist nicht schwer zu sehen, wie GeForce 3 die Shader von D3D 8 beeinflusst hat. Die Pixel-Shader von Shader Model 1.0 waren extrem spezifisch für die NVIDIA-Hardware. Es wurde überhaupt kein Versuch unternommen, die Hardware von NVIDIA zu abstrahieren. SM 1.0 war genau das, was die GeForce 3 tat.

Als ATI mit der Radeon 8500 in das Performance-Grafikkartenrennen einstieg, gab es ein Problem. Die Pixelverarbeitungspipeline des 8500 war leistungsfähiger als die von NVIDIA. Deshalb hat Microsoft Shader Model 1.1 herausgegeben, das im Grunde genommen "Was auch immer der 8500 tut" lautete.

Das klingt vielleicht nach einem Fehler von D3D. Aber Misserfolg und Erfolg sind graduelle Fragen. Und episch In OpenGL-Land ist ein Fehler aufgetreten.

NVIDIA liebte OpenGL. Als GeForce 3 auf den Markt kam, veröffentlichten sie eine Reihe von OpenGL-Erweiterungen. Proprietary OpenGL-Erweiterungen: Nur NVIDIA. Als der 8500 auftauchte, konnte er natürlich keinen von ihnen verwenden.

Zumindest in D3D 8 könnten Sie Ihre SM 1.0-Shader auf ATI-Hardware ausführen. Sicher, Sie mussten neue Shader schreiben, um die Coolness des 8500 zu nutzen, aber zumindest Ihr Code hat funktioniert.

Um Shader von any auf Radeon 8500 in OpenGL zu haben, musste ATI eine Reihe von OpenGL-Erweiterungen schreiben. Proprietary OpenGL-Erweiterungen: Nur ATI. Sie brauchten also einen NVIDIA-Codepfad und einen ATI-Codepfad, um überhaupt Shader zu haben.

Nun könnten Sie fragen: "Wo war der OpenGL ARB, dessen Aufgabe es war, OpenGL auf dem neuesten Stand zu halten?" Wo viele Komitees oft landen: dumm zu sein.

Siehe, ich habe oben ARB_multitexture erwähnt, weil es all dies tief beeinflusst. Der ARB schien (aus der Sicht eines Außenstehenden) die Idee von Shadern insgesamt vermeiden zu wollen. Sie stellten fest, dass sie die Fähigkeit einer Shader-Pipeline erreichen könnten, wenn sie genügend Konfigurierbarkeit auf die Pipeline mit festen Funktionen übertragen würden.

Also hat der ARB eine Erweiterung nach der anderen veröffentlicht. Jede Erweiterung mit den Worten "textur_env" war ein weiterer Versuch, dieses alternde Design zu patchen. Überprüfen Sie die Registrierung: Zwischen ARB- und EXT-Erweiterungen wurden acht dieser Erweiterungen erstellt. Viele wurden zu OpenGL-Kernversionen befördert.

Microsoft war zu dieser Zeit ein Teil des ARB; Sie gingen ungefähr zu der Zeit, als D3D 9 traf. Es ist also durchaus möglich, dass sie in irgendeiner Weise an Sabotage OpenGL gearbeitet haben. Ich persönlich bezweifle diese Theorie aus zwei Gründen. Zum einen hätten sie dafür Hilfe von anderen ARB-Mitgliedern erhalten müssen, da jedes Mitglied nur eine Stimme erhält. Und vor allem zwei, der ARB brauchte nicht die Hilfe von Microsoft, um die Dinge zu vermasseln. Wir werden weitere Beweise dafür sehen.

Schließlich zog der ARB, der wahrscheinlich sowohl von ATI als auch von NVIDIA (beide aktive Mitglieder) bedroht war, seinen Kopf lange genug heraus, um tatsächliche Shader im Assembly-Stil bereitzustellen.

Willst du etwas noch dümmeres?

Hardware T & L. Etwas, das OpenGL hatte zuerst. Nun, es ist interessant. Um die maximal mögliche Leistung von Hardware-T & L zu erzielen, müssen Sie Ihre Vertex-Daten auf der GPU speichern. Schließlich ist es die GPU, die Ihre Scheitelpunktdaten tatsächlich verwenden möchte.

In D3D v7 hat Microsoft das Konzept der Vertex-Puffer eingeführt. Diesen werden Bereiche des GPU-Speichers zum Speichern von Scheitelpunktdaten zugewiesen.

Möchten Sie wissen, wann OpenGL das Äquivalent dazu hat? Oh, NVIDIA, ein Liebhaber aller OpenGL-Dinge (solange es sich um proprietäre NVIDIA-Erweiterungen handelt), hat die Vertex-Array-Range-Erweiterung veröffentlicht, als die GeForce 256 zum ersten Mal auf den Markt kam. Aber wann hat der ARB beschlossen, ähnliche Funktionen bereitzustellen?

Zwei Jahre später. Dies war nach sie genehmigten Vertex- und Fragment-Shader (Pixel in D3D-Sprache). So lange hat der ARB gebraucht, um eine plattformübergreifende Lösung zum Speichern von Vertex-Daten im GPU-Speicher zu entwickeln. Wieder etwas, das Hardware T & L benötigt, um maximale Leistung zu erzielen.

Eine Sprache, um sie alle zu ruinieren

Daher war die OpenGL-Entwicklungsumgebung eine Zeit lang zerbrochen. Keine hardwareübergreifenden Shader, kein hardwareübergreifender GPU-Vertex-Speicher, während D3D-Benutzer beides genossen. Könnte es noch schlimmer werden?

Du ... das könntest du sagen. Geben Sie D Labs ein.

Wer sind sie, könnte man fragen? Sie sind eine nicht mehr existierende Firma, die ich als die wahren Mörder von OpenGL betrachte. Sicher, die allgemeine Unfähigkeit des ARB machte OpenGL anfällig, wenn es D3D hätte besitzen sollen. Aber 3D Labs ist für mich vielleicht der größte Grund für den aktuellen Marktzustand von OpenGL. Was hätten sie möglicherweise tun können, um das zu verursachen?

Sie haben die OpenGL Shading Language entworfen.

Sehen Sie, 3D Labs war eine aussterbende Firma. Ihre teuren GPUs wurden durch den zunehmenden Druck von NVIDIA auf den Workstation-Markt an den Rand gedrängt. Und im Gegensatz zu NVIDIA waren 3D Labs auf dem Mainstream-Markt nicht präsent. Wenn NVIDIA gewann, starben sie.

Was sie getan haben.

Um in einer Welt, die ihre Produkte nicht haben wollte, relevant zu bleiben, kamen 3D Labs zu einer Spieleentwicklerkonferenz mit Präsentationen für etwas, das sie "OpenGL 2.0" nannten. Dies wäre eine vollständige Neufassung der OpenGL-API von Grund auf. Und das macht Sinn; Zu diesem Zeitpunkt gab es in der OpenGL-API einen lot Cruft (Hinweis: Dieser Cruft ist noch vorhanden). Schauen Sie sich nur an, wie das Laden und Binden von Texturen funktioniert. es ist halb arkan.

Ein Teil ihres Vorschlags war eine Schattierungssprache. Natürlich. Im Gegensatz zu den aktuellen plattformübergreifenden ARB-Erweiterungen war ihre Shading-Sprache jedoch "High-Level" (C ist High-Level für eine Shading-Sprache. Ja, wirklich).

Jetzt arbeitete Microsoft an einer eigenen Schattierungssprache auf hoher Ebene. Was sie in aller kollektiven Vorstellung von Microsoft ... die High Level Shading Language (HLSL) nannten. Aber es war eine grundlegend andere Herangehensweise an die Sprachen.

Das größte Problem mit der Shader-Sprache von 3D Labs war, dass sie integriert war. Siehe, HLSL war eine von Microsoft definierte Sprache. Sie haben einen Compiler dafür veröffentlicht und Shader Model 2.0 (oder spätere Shader-Modelle) Assembly-Code generiert, den Sie in D3D einspeisen würden. In den D3D v9-Tagen wurde HLSL von D3D nie direkt berührt. Es war eine schöne Abstraktion, aber rein optional. Und ein Entwickler hatte immer die Möglichkeit, hinter den Compiler zu gehen und die Ausgabe für maximale Leistung zu optimieren.

Die 3D Labs-Sprache hatte keine davon. Sie haben dem Treiber die C-ähnliche Sprache gegeben, und es wurde ein Shader erstellt. Ende der Geschichte. Kein Assembly-Shader, nichts, was Sie mit etwas anderem füttern. Das eigentliche OpenGL-Objekt, das einen Shader darstellt.

Dies bedeutete, dass OpenGL-Benutzer offen für die Launen von Entwicklern waren, die gerade den Dreh raus hatten, Assembly-ähnliche Sprachen zu kompilieren. Compiler-Fehler liefen weit verbreitet in der neu getauften OpenGL Shading Language (GLSL). Was noch schlimmer ist, wenn Sie es geschafft haben, einen Shader auf mehreren Plattformen korrekt zu kompilieren (keine leichte Aufgabe), waren Sie immer noch den Optimierern des Tages ausgesetzt. Welche waren nicht so optimal wie sie sein könnten.

Das war zwar der größte Fehler in GLSL, aber nicht der einzige. By far.

In D3D und in den älteren Assemblersprachen in OpenGL können Sie Vertex- und Fragment-Shader (Pixel-Shader) mischen und anpassen. Solange sie mit derselben Schnittstelle kommunizierten, konnten Sie jeden Vertex-Shader mit jedem kompatiblen Fragment-Shader verwenden. Und es gab sogar Unverträglichkeiten, die sie akzeptieren konnten; Ein Vertex-Shader könnte eine Ausgabe schreiben, die der Fragment-Shader nicht gelesen hat. Und so weiter.

GLSL hatte nichts davon. Vertex- und Fragment-Shader wurden zu einem sogenannten "Programmobjekt" von 3D Labs zusammengeführt. Wenn Sie also Scheitelpunkt- und Fragmentprogramme gemeinsam nutzen möchten, müssen Sie mehrere Programmobjekte erstellen. Und das verursachte das zweitgrößte Problem.

Sehen Sie, 3D Labs dachten, sie wären schlau. Sie basierten auf dem Kompilierungsmodell von GLSL auf C/C++. Sie nehmen eine .c oder .cpp und kompilieren sie in eine Objektdatei. Dann nehmen Sie eine oder mehrere Objektdateien und verknüpfen sie mit einem Programm. So kompiliert GLSL: Sie kompilieren Ihren Shader (Vertex oder Fragment) in ein Shader-Objekt. Anschließend fügen Sie diese Shader-Objekte in ein Programmobjekt ein und verknüpfen sie zu Ihrem eigentlichen Programm.

Während dies potenzielle coole Ideen wie "Bibliotheks" -Shader ermöglichte, die zusätzlichen Code enthielten, den die Haupt-Shader aufrufen konnten, bedeutete dies in der Praxis, dass Shader zweimal Kompiliert wurden. Einmal in der Kompilierungsphase und einmal in der Verknüpfungsphase. Insbesondere der NVIDIA-Compiler war dafür bekannt, dass er die Kompilierung grundsätzlich zweimal ausführte. Es wurde keine Art von Objektcode-Vermittler generiert. es hat es nur einmal kompiliert und die Antwort weggeworfen, dann zur Linkzeit erneut kompiliert.

Selbst wenn Sie Ihren Vertex-Shader mit zwei verschiedenen Fragment-Shadern verknüpfen möchten, müssen Sie viel mehr kompilieren als in D3D. Zumal das Kompilieren einer C-ähnlichen Sprache vollständig durchgeführt wurde offline, nicht zu Beginn der Programmausführung.

Es gab andere Probleme mit GLSL. Vielleicht scheint es falsch, 3D Labs die Schuld zu geben, da der ARB die Sprache schließlich genehmigt und integriert hat (aber nichts anderes von ihrer "OpenGL 2.0" -Initiative). Aber es war ihre Idee.

Und hier ist der wirklich traurige Teil: 3D Labs war richtig (meistens). GLSL ist keine vektorbasierte Schattierungssprache wie HLSL zu dieser Zeit. Dies lag daran, dass die Hardware von 3D Labs skalare Hardware war (ähnlich der modernen NVIDIA-Hardware), aber letztendlich genau in die Richtung, in die viele Hardwarehersteller mit ihrer Hardware gingen.

Sie hatten Recht, sich für ein Online-Kompilierungsmodell für eine "Hochsprache" zu entscheiden. D3D hat schließlich sogar darauf umgestellt.

Das Problem war, dass 3D Labs zur falschen Zeit richtig waren Zeit. Und wenn sie versuchen, die Zukunft zu früh zu beschwören, um zukunftssicher zu sein, werfen sie die Gegenwart beiseite. Es klingt ähnlich, wie OpenGL immer die Möglichkeit für T & L-Funktionen hatte. Abgesehen davon, dass die T & L-Pipeline von OpenGL vor der Hardware-T & L noch nützlich war, während GLSL eine Haftung war, bevor die Welt sie einholte.

GLSL ist eine gute Sprache jetzt. Aber für die Zeit? Es war schrecklich. Und OpenGL hat darunter gelitten.

Auf dem Weg zur Apotheose

Während ich behaupte, dass 3D Labs den tödlichen Schlag versetzte, war es der ARB selbst, der den letzten Nagel in den Sarg trieb.

Dies ist eine Geschichte, von der Sie vielleicht gehört haben. Zum Zeitpunkt von OpenGL 2.1 stieß OpenGL auf ein Problem. Es hatte eine Menge Legacy Cruft. Die API war nicht mehr einfach zu bedienen. Es gab 5 Möglichkeiten, Dinge zu tun, und keine Ahnung, welche die schnellste war. Sie konnten OpenGL mit einfachen Tutorials "lernen", aber Sie haben die OpenGL-API nicht wirklich gelernt, die Ihnen echte Leistung und grafische Leistung verlieh.

Daher beschloss der ARB, eine weitere Neuerfindung von OpenGL zu versuchen. Dies war ähnlich wie "OpenGL 2.0" von 3D Labs, aber besser, weil der ARB dahinter steckte. Sie nannten es "Longs Peak".

Was ist so schlimm daran, sich etwas Zeit zu nehmen, um die API zu verbessern? Das war schlecht, weil Microsoft sich selbst verwundbar gemacht hatte. Siehe, this war zum Zeitpunkt der Vista-Umstellung.

Mit Vista hat Microsoft beschlossen, einige dringend benötigte Änderungen an den Bildschirmtreibern vorzunehmen. Sie zwangen die Treiber, sich für die Virtualisierung des Grafikspeichers und verschiedene andere Dinge an das Betriebssystem zu wenden.

Während man die Vorzüge davon diskutieren kann oder ob es tatsächlich möglich war, bleibt die Tatsache bestehen: Microsoft betrachtete D3D 10 nur als Vista (und höher). Selbst wenn Sie Hardware hatten, die fähig von D3D 10 war, konnten Sie D3D 10-Anwendungen nicht ausführen, ohne auch Vista auszuführen.

Vielleicht erinnerst du dich auch an Vista ... ähm, sagen wir einfach, dass es nicht gut geklappt hat. Sie hatten also ein unterdurchschnittliches Betriebssystem, eine neue API, die nur auf diesem Betriebssystem lief, und eine neue Generation von Hardware, die benötigt diese API und das Betriebssystem, um mehr als nur schneller als die vorherige Generation zu sein.

Entwickler könnte greifen über OpenGL auf Funktionen der D3D 10-Klasse zu. Nun, sie könnten es, wenn der ARB nicht damit beschäftigt gewesen wäre, am Longs Peak zu arbeiten.

Grundsätzlich hat der ARB gut anderthalb bis zwei Jahre gearbeitet, um die API zu verbessern. Als OpenGL 3.0 tatsächlich herauskam, war die Übernahme von Vista abgeschlossen, Win7 stand vor der Tür, um Vista hinter sich zu lassen, und die meisten Spieleentwickler kümmerten sich sowieso nicht um die Funktionen der D3D-10-Klasse. Immerhin lief auf der D3D 10-Hardware D3D 9-Anwendungen einwandfrei. Und mit dem Aufkommen von PC-zu-Konsolen-Ports (oder PC-Entwicklern, die sich auf die Konsolenentwicklung stürzen. Treffen Sie Ihre Wahl), benötigten Entwickler keine Funktionen der D3D 10-Klasse.

Wenn Entwickler früher über OpenGL auf WinXP-Computern auf diese Funktionen zugreifen konnten, hat die OpenGL-Entwicklung möglicherweise einen dringend benötigten Schuss in den Arm bekommen. Aber der ARB verpasste ihre Gelegenheit. Und willst du das Schlimmste wissen?

Obwohl sie zwei kostbare Jahre damit verbracht haben, die API von Grund auf neu zu erstellen, sind sie immer noch gescheitert und haben einfach wieder den Status Quo erreicht (mit Ausnahme eines Verfallsmechanismus).

Der ARB hat also nicht nur ein entscheidendes Zeitfenster verpasst, sondern auch nicht einmal die Aufgabe erledigt, die ihn dazu gebracht hat, diese Chance zu verpassen. Ziemlich episch scheitern überall.

Und das ist die Geschichte von OpenGL vs. Direct3D. Eine Geschichte verpasster Gelegenheiten, grober Dummheit, vorsätzlicher Blindheit und einfacher Dummheit.

1154
Nicol Bolas

Ich fand es seltsam, dass sich alle auf die Benutzerbasis konzentrieren, wenn die Frage "Spieleentwickler" und nicht "Spieleeditoren" lautet.

Für mich als Entwickler ist Linux ein blutiges Durcheinander. Es gibt so viele Versionen, Desktop-Manager, UI-Kits usw. Wenn ich meine Arbeit nicht als Open Source verteilen möchte, kann der Benutzer sie neu kompilieren, damit sie zu seiner einzigartigen Kombination aus Paketen, Bibliotheken und Bibliotheken passt Einstellungen, es ist ein Albtraum!

Auf der anderen Seite bietet Microsoft (meistens) unglaubliche Abwärtskompatibilität und Plattformstabilität. Es ist möglich, eine ganze Reihe von Computern mit einem Closed-Source-Installationsprogramm anzusprechen, z. B. Computer mit Windows XP, Vista und 7-, 32- und 64-Bit-Varianten, ohne ordnungsgemäße DX- oder VC Redistributables installiert, usw...

Eine letzte Sache, BITTE JEDER IM INTERNET STOPPEN SIE DEN VERGLEICH VON OPENGL UND DIRECTX! Vergleichen Sie entweder Direct3D mit OpenGL oder tun Sie dies nicht . DirectX bietet Eingabeunterstützung, Soundunterstützung, Filmwiedergabe usw. usw., die OpenGL nicht bietet.

133
jv42

Das liegt daran, dass es auf dem Planeten mehr Windows-Benutzer gibt als Linux und Mac. Die Wahrheit ist, dass Menschen Dinge für den machen, der den größten Markt hat.
Dasselbe gilt für Mobiltelefone: Android und iPhone haben großartige Spiele, Windows Mobile und Symbian jedoch nicht ...

88
Arjun Bajaj

Weil Windows einen Marktanteil von über 90% hat und Linux (da Sie speziell nach Linux gefragt haben) den Ruf hat, viele Benutzer zu haben, die nicht gerne für Software bezahlen. Ob das stimmt oder nicht oder wie wahr es ist, spielt keine Rolle. Die Wahrnehmung ist da und beeinflusst die Entscheidungen der Menschen.

50
Mason Wheeler

Da Windows von einer riesigen Organisation unterstützt wird, hat sich das vor mehr als einem Jahrzehnt entschieden sie möchten, dass die Spieleentwicklung auf ihrer Plattform stattfindet .

Dies galt nicht für den Mac und gilt jetzt nicht mehr. Nicht einmal für iOS. Apple bietet keine Tools für die Entwicklung von iOS-Spielen. Aber es ist ein riesiger Markt (es gibt mehr iPhones als 1995) mit relativ wenig Konkurrenz, also machen die Leute es trotzdem.

Was Linux betrifft, gibt es nicht einmal eine zentrale Institution, die Prioritäten setzen könnte. Die Richtung, in die Linux geht, wird weniger von einer Reihe sehr guter, aber etwas weltfremder Programmierer bestimmt.

Um heute ein PC-Spiel zu erstellen, benötigen Sie viele 2D/3D-Künstler, Spieledesigner, Drehbuchautoren, Schauspieler, Tester und was nicht. Für die eigentliche Programmierung können Sie einfach eine tatsächliche Spiel-Engine verwenden (CryEngine, Unreal Engine, Quake Engine, Source Engine). So können Sie möglicherweise das Ganze ohne tatsächliche Programmierer erledigen.

Aus diesem Grund und aufgrund der Art der Unternehmen haben Programmierer wenig Einfluss darauf, welche Plattform ausgewählt wird. In der Regel suchen Manager nach Unterstützung, die Microsoft angeblich anbietet, und nach Dingen, die für ihre Gedankenmuster irgendwie greifbar sind, was Open Source nicht ist.

Aus diesem Grund wird die meiste kommerzielle Softwareentwicklung für Endbenutzer unter Windows durchgeführt.
Ich arbeite für ein Unternehmen, das Flash-Spiele erstellt und daher nicht an eine bestimmte Plattform gebunden ist. Wir entwickeln jedoch alle unter Windows, da die meisten von uns verwendeten Tools für Linux nicht verfügbar sind.

11
back2dos

Wie einige bereits gesagt haben, ist der wichtigste Teil die Benutzerbasis. 95% der PC-Benutzer verwenden Windows. PC-Spieler verwenden fast ausschließlich Windows. Selbst diejenigen, die Mac oder Linux verwenden, führen Windows-Spiele am häufigsten durch Virtualisierung oder Emulation aus (mit sehr, sehr wenigen Ausnahmen).

Aber demografisch ist nicht alles. Ich würde den Teil, den Microsoft tut, um die Plattform für Spieleentwickler attraktiver zu machen, nicht unterschätzen. Grundsätzlich erhalten Sie voll funktionsfähige Tools kostenlos , vor allem ) XNA Game Studio . Dies ermöglicht nicht nur die Entwicklung für Windows, sondern auch für Xbox360 . Und mit der neuesten Ausgabe auch für WP7-Handys. Da es sich um ein Microsoft-Tool handelt, wird offensichtlich DirectX und nicht OpenGL verwendet.

10
vartec

Ewwww, ich nicht. Ich benutze fast ausschließlich Linux. Ich starte Windows doppelt, um Windows-Builds zu erstellen, und verwende den Mac für die Mac-Builds, aber das war's.

Der Trick ist ein plattformübergreifendes Framework, das wir im Laufe der Jahre entwickelt haben. Unsere Spiele bauen darauf auf und verhalten sich unter Linux/OpenGL, Mac/OpenGL und Windows/Direct3D (und bald auch unter iOS/OpenGL) identisch.

Zugegeben, meine Firma macht keine AAA-Titel, daher gilt dies möglicherweise nicht für diese, aber wir machen Top-Casual-Games (siehe Website - CSI: NY, Murder She Wrote und die beiden kommenden 2011er sind Beispiele Bei den Titeln mit wichtigen Lizenzen waren auch The Lost Cases von Sherlock Holmes 1 und 2 recht erfolgreich.

Ich würde gedit + gcc + gdb + valgrind für nichts anderes aufgeben.

6
ggambett

Werkzeuge, Werkzeuge, Werkzeuge.

Darauf kommt es an. Entwickeln Sie unter Windows und Sie erhalten Zugriff auf einige der besten Entwicklungstools der Welt. Nichts kommt dem Debugger von Visual Studio auch nur annähernd nahe, die DirectX-Debug-Laufzeiten sind fantastisch, PIX ist fantastisch und vergleichbare Entsprechungen gibt es auf anderen Plattformen/APIs einfach nicht. Klar, da gibt es ein paar gute Sachen; Ich sage nicht, dass die Tools auf anderen Plattformen schlecht sind, aber die von MS bereitgestellten sind dem Rudel so weit voraus (ehrenwerte Ausnahme: Valgrind), dass es nicht einmal lustig ist.

Fazit ist, dass diese Tools Ihnen helfen. Sie helfen Ihnen dabei, Dinge zu erledigen, sie helfen Ihnen, produktiv zu sein, sie helfen Ihnen, sich auf Fehler in Ihrem eigenen Code zu konzentrieren, anstatt mit einer API zu kämpfen, die sich nie so verhält, wie sie dokumentiert ist.

4
Maximus Minimus

Ich habe all diese Antworten durchgesehen und als Spieleentwickler, der Code für Konsolenspiele in Walmart-Regalen hat, habe ich eine ganz andere Antwort.

Verteilung.

Wenn Sie auf einer Nintendo-Konsole sitzen möchten, müssen Sie die Erlaubnis von Nintendo einholen, in den Fabriken von Nintendo kaufen, die Gemeinkosten von Nintendo bezahlen, mit Walmart verhandeln, sich mit der Lagerhaltung befassen, Geld für die Herstellung, den Druck von Kartons und den Versand im Voraus benötigen , um die ganze Versicherung zu machen, und so weiter.

Wenn Sie auf die XBox wollen, sicher, dass es XBLA gibt, aber Sie immer noch den Segen von Microsoft brauchen, müssen Sie warten, bis Sie an der Reihe sind, es sind Zehntausende von Dollar, nur um einen Patch zu veröffentlichen usw.

Unter iOS brauchst du immer noch Apples Okay, und sie können (und tun) dich launisch ziehen.

Bei Steam benötigen Sie noch Valves Erlaubnis oder grünes Licht und viel Geld.

.

Unter Windows? Sie richten eine Website und einen Download-Button ein.

.

Ich sage nicht, dass die anderen Plattformen nicht wertvoll sind. Aber es gibt so * viel * schreckliches Zeug, wenn Sie versuchen, ein Spiel zu entwickeln, das für mich das Versprechen, einfach eine Binärdatei auf eine Site zu schlagen und sich auf die Arbeit zu konzentrieren - zumindest um loszulegen - senkt wirklich viele potenzielle Ausfallbarrieren.

"Wir können den XBLA-Port später machen, wenn die Dinge stabil sind" -Mentalität.

In geringerem Maße ist dies auch für Linux in Ordnung, und wenn sieben Kunden gut sind, können Sie dort beginnen.

Windows hat jedoch drei enorme Vorteile: eine wirklich offene Entwicklung, eine wirklich offene Bereitstellung und eine sehr große, sehr aktive Kundenbasis, die sich für skurrile Dinge interessiert.

Es ist schwer vorstellbar, wo ich sonst lieber anfangen würde.

4
John Haugeland

Die Antwort liegt auf der Hand. Das Ziel eines Spiels ist es, Geld zu verdienen. Mehr Endbenutzer verwenden Windows, daher gibt es einen größeren Markt und Sie würden erwarten, mit einem Windows-Spiel mehr Geld zu verdienen als mit einem Linux-Spiel. So einfach ist das.

Wenn Sie sich jemals die Frage stellen: "Warum macht jemand ...", denken Sie daran, dass Geld die Welt bewegt.

4
Russell Horwood
  1. Trägheit. Wenn Sie in der Vergangenheit Windows verwendet haben, ist der Wechsel zu etwas anderem ein Problem. Wenn Sie mit Windows DirectX arbeiten, ist dies einfacher und funktioniert mit größerer Wahrscheinlichkeit als OpenGL.
  2. Marktanteil. Der Marktanteil von Windows auf dem Desktop ist größer als der von OS X, der wiederum größer ist als der von Linux. Geldgespräche.
  3. Marke. DirectX ist besser bekannt als Dinge wie SDL (dies ist die Art von Dingen, die Sie benötigen würden, um einige der DirectX-Funktionen zu replizieren, die über OpenGL hinausgehen).
  4. Weniger Verwirrung. Unterstützt das Linux des Benutzers nur OpenGL 1.4 oder OpenGL 2+? Können Sie ein OpenGL 2.0-Tutorial wie Eine Einführung in das moderne OpenGL verwenden. Kapitel 1: Die Grafik-Pipeline auf Ihrer Linux-Version?

Heutzutage ist Linux eher ein Kuriosum, wenn es um die Entwicklung von Spielen geht, und die meisten Entwickler sind besser dran, eine OS X-Port-Version vor einer Linux-Version fiskalisch zu erstellen (siehe Dinge wie Steam). Selbst dann ist der Konsolenmarkt mehr wert als diese beiden Plattformen zusammen für Spiele ...

Wenn Sie Mono-Plattform DirectX wollten, ist in Ordnung. Wenn Sie plattformübergreifend sein möchten, besteht eine große Chance, dass Sie OpenGL zumindest auf einigen anderen Plattformen verwenden müssen.

4
Anon

Ich denke, Sie sollten mehr über die Geschichte von DirectX und Dieser Artikel lesen.

Ich denke, MS hat DX gegenüber openGL gewählt, weil sie die Leute gerne daran binden, ihr eigenes Betriebssystem zu verwenden.

3
Mahmoud Hossam

Viel hat mit Politik und Kontrolle zu tun. In den späten 90er Jahren einigten sich SGI und MS tatsächlich darauf, ihre Bemühungen zu bündeln:

http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

SGI investierte stark in das Projekt, MS nicht. SGI brauchte MS mehr als MS SGI. Der Rest ist Geschichte.

D3D und OpenGL sind zwei sehr unterschiedliche APIs. Es ist Sache des Entwicklers, die für Ihre Anforderungen geeignete auszuwählen.

1
quellish

Einfach, weil Linux als Desktop-System schrecklich versagt hat. Wie bereits erwähnt, ist Linux ein Chaos für Entwickler (verschiedene Bibliotheken, UI-Toolkits usw.)

Ein weiteres Problem ist der Freetardismus und die mangelnde Unterstützung für proprietäre Software. Nvidia bietet immer gute (proprietäre) Treiber für Linux, Ubuntu und andere Distributionen liefern sie jedoch nicht aus. Es gibt auch keine binäre Treiberschnittstelle für Linux wie für Windows. (Es gibt eine Textdatei namens binaryApiNonsense.txt oder etwas in den Kernel-Quellen.) Allerdings wird unter Linux nur Nvidia-Hardware ordnungsgemäß unterstützt. Sie können die meisten ID-Software-Spiele mit Nvidia-Hardware unter Linux spielen.

Als nächstes Entwicklungswerkzeuge. MSFT bietet hervorragende C++ - Unterstützung und der Visual Studio-Debugger ist in Bezug auf C++ besser als gdb. Zu guter Letzt fehlen weitere Tools wie Photoshop. Mit .net können Sie auch schnell GUI-Tools erstellen. Viele Spielestudios codieren ihre Tools für den internen Gebrauch mithilfe des .net-Frameworks.

Fast hätte ich vergessen: Das Grafiksystem ist schrecklich, damals, als sie X11 portiert haben, weil es das Einfachste war, was funktioniert hat. Sie konnten ein modernes Grafiksystem von OSx und Win nicht richtig entwerfen und implementieren.

0
Nils