Warum bevorzugen Spieleentwickler Windows?

396

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

M.Sameer
quelle
55
Falsche Prämisse - Wo gibt es Hinweise darauf, dass Spieleentwickler Windows bevorzugen? Ich denke, @ user17674 hatte es genauer - sie wollen für Plattformen entwickeln, damit sie mehr verkaufen und mehr Geld verdienen können :-)
Rory Alsop
258
Virenentwickler bevorzugen auch Windows. Es dreht sich alles um die Nutzerbasis.
CesarGon
4
Warum Windows-Programmierer DirectX gegenüber OpenGL bevorzugen, ist historisch gesehen wahrscheinlich eine interessantere Frage. Wie der unten stehende Link zum Carmack-Interview zeigen könnte, war DX früher verabscheut. Es wäre interessant zu wissen, wie es genügend Benutzer für MS hielt, um es zu unterstützen, bis Xbox und moderne Umschreibungen es populärer machten. Oder vielleicht war es einfach immer gut genug, also hielten die Leute daran fest.
CodexArcanum
100
Warum rauben die Leute Banken aus? Denn dort ist das Geld .
GrandmasterB
7
@CesarGon: Das liegt nicht nur an der Benutzerbasis, sondern auch an der einfachen Entwicklung.
Giorgio

Antworten:

1154

Viele der Antworten hier sind wirklich sehr, sehr gut. Aber das OpenGL und Direct3D (D3D) Problem 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 SNES und Sega Genesis fantastisch waren und viele Action-Spiele und so weiter spielten. Und sie haben DOS gesehen . Entwickler codierten DOS-Spiele wie Konsolenspiele: direkt auf das Metall. Im Gegensatz zu Konsolen, bei denen ein Entwickler, der ein SNES-Spiel entwickelte, wusste, welche Hardware der Benutzer haben würde, mussten DOS-Entwickler für mehrere mögliche Konfigurationen schreiben. Und das ist schwieriger als es sich anhört.

Und Microsoft hatte ein größeres Problem: Windows. Sehen Sie, Windows wollte die Hardware besitzen, im Gegensatz zu DOS, mit dem Entwickler so ziemlich alles machen können. Der Besitz der Hardware ist erforderlich, um die Zusammenarbeit zwischen den Anwendungen zu gewährleisten. Kooperation ist genau das, was Spieleentwickler hassen, weil sie wertvolle Hardwareressourcen in Anspruch nimmt, mit denen sie großartig sein könnten.

Um die Spieleentwicklung unter Windows voranzutreiben, benötigte Microsoft eine einheitliche API auf niedriger Ebene, die unter Windows ausgeführt werden konnte, ohne dass dies zu Lasten der Hardware ging . Eine einzige API für alle Grafik-, Sound- und Eingabehardware.

So 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 Bit-Blits zwischen verschiedenen zugewiesenen Speicherbereichen.

Also kaufte Microsoft ein Stück Middleware und baute es in Direct3D Version 3 um. Es wurde allgemein verunglimpft. Und das aus gutem Grund. Ein Blick auf D3D v3-Code ist wie ein Blick in die Bundeslade.

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

Sehen Sie, ein weiterer Teil des vielköpfigen Biests Microsoft war damit beschäftigt, mit SGI an einer OpenGL-Implementierung für Windows zu arbeiten. Die Idee dabei war, Entwickler typischer GL-Anwendungen zu werben: Workstation-Apps. CAD-Tools, Modellierung, so etwas. Spiele waren die am weitesten entfernte Sache in ihrem Kopf. Dies war in erster Linie eine Windows NT-Sache, aber Microsoft beschloss, sie auch Win95 hinzuzufügen.

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

In den Anfängen hatten Consumer-Videokarten jedoch keine Unterstützung für OpenGL. Das hat Carmack nicht davon abgehalten, Quake einfach auf OpenGL (GLQuake) auf seiner SGI-Workstation zu portieren. Wie wir aus der GLQuake-Readme lesen können:

Theoretisch läuft glquake auf jedem kompatiblen OpenGL, das die Texturobjekterweiterungen unterstützt. Das Spiel ist jedoch nicht akzeptabel, es sei denn, es handelt sich um eine sehr leistungsfähige Hardware, die alles Notwendige beschleunigt. Wenn es Software-Emulationspfade durchlaufen muss, wird die Leistung wahrscheinlich deutlich unter einem Frame pro Sekunde liegen.

Gegenwärtig (März '97) ist die einzige Standard-OpenGL-Hardware, die Glquake vernünftigerweise spielen kann, ein Intergraph-Realizmus, der eine SEHR teure Karte ist. 3dlabs hat seine Leistung erheblich verbessert, aber mit den verfügbaren Treibern ist es immer noch nicht gut genug zum Spielen. Einige der aktuellen 3dlabs-Treiber für Glint- und Permedia-Boards können auch beim Beenden eines Vollbildlaufs zum Absturz von NT führen. Daher empfehle ich, glquake nicht auf 3dlabs-Hardware auszuführen.

3dfx hat eine opengl32.dll bereitgestellt, die alles implementiert, was glquake benötigt, aber keine vollständige opengl-Implementierung ist. Es ist sehr unwahrscheinlich, dass andere OpenGL-Anwendungen damit arbeiten. Betrachten Sie es also als einen „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 Hersteller hatten Probleme, was ein Grund ist, warum Entwickler Direct3D bevorzugten: Sie waren mit einer größeren Auswahl an Hardware kompatibel. Schließlich blieben nur noch nVidia und ATI (jetzt AMD) übrig, und beide hatten eine gute OpenGL-Implementierung.

OpenGL Ascendant

Damit ist die Bühne frei: 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 Erweiterungs-Repository und erstellen neue Versionen der API. Das ARB ist ein Komitee, das sich aus vielen Akteuren der Grafikindustrie sowie einigen OS-Herstellern zusammensetzt. Apple und Microsoft waren zu verschiedenen Zeiten Mitglied des ARB.

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

In der Zwischenzeit kommt Direct3D v5 heraus. Jetzt ist D3D zu einer wirklichen API geworden , anstatt etwas, das eine Katze erbrechen könnte. Das Problem? Kein Multitexturing.

Hoppla.

Nun, das würde nicht annähernd so weh tun, wie es hätte sein sollen, weil die Leute Multitexturing nicht oft benutzten. Nicht direkt. Multitexturing schadete der Performance ziemlich und in vielen Fällen war es das nicht wert, verglichen mit Multi-Passing. Und natürlich lieben es Spieleentwickler sicherzustellen, dass ihre Spiele auf älterer Hardware funktionieren, die kein Multitexturing hatte, so viele Spiele werden ohne diese ausgeliefert.

D3D wurde somit eine Atempause eingeräumt.

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

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

Dawn of Shaders, Twilight von OpenGL

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

Microsoft hatte entschieden, dass sie nicht wieder zu spät kommen würden. Anstatt sich anzusehen, 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 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. Die Pixel-Shader von Shader Model 1.0 waren extrem spezifisch für die NVIDIA-Hardware. Es wurde keinerlei Versuch unternommen, die NVIDIA-Hardware zu abstrahieren. SM 1.0 war genau das, was die GeForce 3 tat.

Als ATI mit der Radeon 8500 ins Rennen der Leistungsgrafikkarten einstieg, gab es ein Problem. Die Pixel-Verarbeitungs-Pipeline des 8500 war leistungsstärker als die von NVIDIA. Also gab Microsoft Shader Model 1.1 heraus, das im Grunde genommen "Whatever the 8500 does" war.

Das mag nach einem Fehler von D3D klingen. Aber Misserfolg und Erfolg sind graduell. Und in OpenGL-Land geschah ein episches Scheitern.

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

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 funktionierte Ihr Code .

Um Shader jeglicher Art auf Radeon 8500 in OpenGL zu haben, musste ATI eine Reihe von OpenGL-Erweiterungen schreiben. Proprietäre OpenGL-Erweiterungen: Nur ATI. Also brauchten Sie 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 Gremien oft landen: dumm sein.

Siehe, ich habe ARB_multitexture oben erwähnt, weil es all dies tief einbezieht. Der ARB schien (aus der Sicht eines Außenstehenden) die Idee von Shadern ganz 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 veröffentlichte der ARB eine Erweiterung nach der anderen. Jede Erweiterung mit den Worten "texture_env" war ein weiterer Versuch, dieses alternde Design zu patchen. Überprüfen Sie die Registrierung: Zwischen den Erweiterungen ARB und EXT wurden acht dieser Erweiterungen vorgenommen. Viele wurden zu OpenGL-Kernversionen befördert.

Microsoft war zu diesem Zeitpunkt Teil des ARB. Sie gingen um die Zeit, als D3D 9 traf. Es ist also durchaus möglich, dass sie OpenGL auf irgendeine Weise sabotieren wollten. Ich persönlich bezweifle diese Theorie aus zwei Gründen. Erstens hätten sie dazu Hilfe von anderen ARB-Mitgliedern erhalten müssen, da jedes Mitglied nur eine Stimme hat. 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 (beiden aktiven Mitgliedern) bedroht war, den Kopf so weit heraus, dass er tatsächlich Shader im Assembly-Stil bereitstellte.

Willst du etwas noch dümmeres?

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

In D3D v7 hat Microsoft das Konzept der Vertex-Puffer eingeführt. Diesen werden Gruppen von GPU-Speichern zum Speichern von Vertex-Daten zugewiesen.

Möchten Sie wissen, wann OpenGL das Äquivalent dazu hat? Oh, NVIDIA, ein Liebhaber von OpenGL (sofern 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 geschah, nachdem Vertex- und Fragment-Shader (Pixel in D3D-Sprache) genehmigt wurden. 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, die alle ruiniert

Daher war die OpenGL-Entwicklungsumgebung für einige Zeit fehlerhaft. 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önnte man so sagen. Betreten Sie 3D Labs .

Wer sind sie, könnten Sie fragen? Sie sind eine nicht mehr existierende Firma, die ich für die wahren Killer von OpenGL halte. 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 wichtigste Grund für die aktuelle Marktlage von OpenGL. Was hätten sie möglicherweise tun können, um das zu verursachen?

Sie entwarfen die OpenGL Shading Language.

3D Labs war eine sterbende Firma. Ihre teuren GPUs wurden durch den zunehmenden Druck von NVIDIA auf den Workstation-Markt an den Rand gedrängt. 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, um Präsentationen für etwas zu halten, das sie "OpenGL 2.0" nannten. Dies wäre eine vollständige Neufassung der OpenGL-API von Grund auf. Und das macht Sinn; Zu dieser Zeit gab es in OpenGLs API eine Menge Cruft (Anmerkung: Diese Cruft existiert immer noch). 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 Schattierungssprache jedoch "hoch" (C ist für eine Schattierungssprache hoch. Ja, wirklich).

Jetzt arbeitete Microsoft an einer eigenen, übergeordneten Shading-Sprache. Was sie in aller kollektiven Fantasie von Microsoft als High Level Shading Language (HLSL) bezeichneten. Ihre Herangehensweise an die Sprachen war jedoch grundlegend anders.

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 daraus den Assembler-Code Shader Model 2.0 (oder höher) generiert, den Sie in D3D einfügen würden. In den Tagen von D3D v9 wurde HLSL nie direkt von D3D berührt. Es war eine schöne Abstraktion, aber es war 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 nichts davon. Sie haben dem Treiber die C-ähnliche Sprache gegeben, und es wurde ein Shader erstellt. Ende der Geschichte. Kein Assembler-Shader, nichts, was man noch füttert. Das eigentliche OpenGL-Objekt, das einen Shader darstellt.

Dies bedeutete, dass OpenGL-Benutzer den Launen der Entwickler ausgesetzt waren, die gerade den Dreh und Angelpunkt beim Kompilieren von Assembler-ähnlichen Sprachen hatten. Compiler - Fehler lief zügellos in der neu getauft 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 konnten.

Dies war zwar der größte Fehler bei GLSL, aber nicht der einzige. Bei weitem .

In D3D und in den älteren Assemblersprachen in OpenGL konnten Sie Vertex- und Fragment-Shader (Pixel) mischen und anpassen. Solange sie mit derselben Schnittstelle kommunizierten, konnten Sie jeden Vertex-Shader mit jedem kompatiblen Fragment-Shader verwenden. Und es gab sogar Inkompatibilitätsniveaus, 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" zusammengefügt. Wenn Sie Vertex- und Fragment-Programme gemeinsam nutzen wollten, mussten Sie mehrere Programmobjekte erstellen. Und dies verursachte das zweitgrößte Problem.

Sehen Sie, 3D Labs dachten, sie wären schlau. Sie basierten das GLSL-Kompilierungsmodell auf C / C ++. Sie nehmen eine C- oder CPP-Datei und kompilieren sie in eine Objektdatei. Dann nehmen Sie eine oder mehrere Objektdateien und verknüpfen sie zu 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 ermöglichte, wie beispielsweise "Bibliotheks" -Shader, die zusätzlichen Code enthielten, den die Hauptshader 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 im Grunde zweimal ausführte. Es wurde keine Art Objektcode-Vermittler generiert. es hat es nur einmal kompiliert und die Antwort weggeworfen und dann zur Link-Zeit erneut kompiliert.

Selbst wenn Sie Ihren Vertex-Shader mit zwei verschiedenen Fragment-Shadern verknüpfen möchten, müssen Sie wesentlich mehr Kompilierungsschritte ausführen als in D3D. Zumal das Kompilieren einer C-ähnlichen Sprache offline erfolgte und 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 genehmigte und einbezog (aber nichts anderes von ihrer "OpenGL 2.0" -Initiative). Aber es war ihre Idee.

Und hier ist der wirklich traurige Teil: 3D Labs hatte (größtenteils) recht . GLSL ist keine vektorbasierte Schattierungssprache, wie es HLSL damals war. Dies lag daran, dass die Hardware von 3D Labs eine skalare Hardware war (ähnlich der modernen NVIDIA-Hardware), aber letztendlich stimmten sie mit der Richtung überein, in die sich viele Hardware-Hersteller mit ihrer Hardware begaben.

Sie hatten Recht, ein Online-Kompilierungsmodell für eine "Hochsprache" zu wählen. D3D hat sogar irgendwann darauf umgestellt.

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

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

Fallen in Richtung Apotheose

Während ich behaupte, dass 3D Labs den tödlichen Schlag versetzt hat, war es der ARB selbst, der den letzten Nagel in den Sarg treiben würde.

Dies ist eine Geschichte, von der Sie vielleicht schon gehört haben. Zum Zeitpunkt von OpenGL 2.1 stieß OpenGL auf ein Problem. Es hatte viel altes Zeug. Die API war nicht mehr einfach zu bedienen. Es gab 5 Möglichkeiten, Dinge zu tun, und keine Ahnung, welche am schnellsten war. Sie könnten OpenGL mit einfachen Tutorials "erlernen", aber Sie haben nicht wirklich die OpenGL-API gelernt, die Ihnen echte Leistung und grafische Leistung bietet.

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 dahintersteckte. Sie nannten es "Longs Peak".

Was ist so schlimm daran, sich Zeit zu nehmen, um die API zu verbessern? Das war schlimm, weil Microsoft sich selbst verwundbar gemacht hatte. Sehen Sie, dies 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 Grafikspeichervirtualisierung und verschiedene andere Dinge an das Betriebssystem zu wenden.

Während man darüber diskutieren kann, ob dies tatsächlich möglich war oder nicht, bleibt die Tatsache, dass Microsoft D3D 10 nur für Vista (und höher) hält. Auch wenn Sie Hardware hatte , das war der Lage 10 von D3D, könnten Sie nicht laufen D3D 10 Anwendungen ohne auch Vista ausgeführt wird .

Vielleicht erinnerst du dich auch an Vista ... ähm, lass uns einfach sagen, dass es nicht gut geklappt hat. Sie hatten also ein unterdurchschnittliches Betriebssystem, eine neue API, die nur auf diesem Betriebssystem ausgeführt wurde, und eine neue Generation von Hardware, für die diese API und dieses Betriebssystem mehr brauchten , als schneller als die vorherige Generation zu sein.

Entwickler konnten jedoch über OpenGL auf Funktionen der D3D 10-Klasse zugreifen. Nun, sie könnten es, wenn der ARB nicht am Longs Peak gearbeitet hätte.

Grundsätzlich hat der ARB gut anderthalb bis zwei Jahre an der Verbesserung der API gearbeitet. Als OpenGL 3.0 herauskam, war die Einführung von Vista bereits abgeschlossen, Win7 stand vor der Tür, um Vista hinter sich zu lassen, und die meisten Spieleentwickler interessierten sich sowieso nicht für die Funktionen der D3D-10-Klasse. Immerhin lief auf der D3D 10-Hardware D3D 9-Anwendungen einwandfrei. Und mit dem Aufkommen von PC-zu-Konsole-Ports (oder PC-Entwicklern, die die Entwicklung von Konsolen vorantreiben. Treffen Sie Ihre Wahl), benötigten Entwickler keine Funktionen der D3D 10-Klasse.

Hätten Entwickler früher über OpenGL auf WinXP-Computern Zugriff auf diese Funktionen, hätte die OpenGL-Entwicklung möglicherweise die dringend benötigte Chance erhalten. Aber die ARB haben ihre Chance verpasst. Und willst du das Schlimmste wissen?

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

Die ARB hat also nicht nur ein entscheidendes Zeitfenster verpasst , sondern auch nicht die Aufgabe erledigt, die sie veranlasst hat, diese Chance zu verpassen. Überall ziemlich epische Fehler.

Und das ist die Geschichte von OpenGL vs. Direct3D. Eine Geschichte über verpasste Gelegenheiten, grobe Dummheit, vorsätzliche Blindheit und einfache Dummheit.

Nicol Bolas
quelle
24
Hattest du das irgendwo aufgeschrieben oder hast du oben auf dem Kopf geschrieben?
Kristofer Hoch
38
@Kristofer: Ich weiß nicht, ob man es für etwas, das ungefähr eine Stunde gedauert hat, "aus dem Häuschen" nennen kann, aber ich hatte es nicht irgendwo aufgeschrieben.
Nicol Bolas
18
@ F.Aquino: Also sind Sie bereit, dies dem Rendering-System zuzuschreiben, das FPS-Spiele verwenden, und nicht der Engine selbst? Auch wenn CS auf Half-Life 1 basiert, welches basiert auf Quake? Es tut uns leid; Ich kaufe es nicht. Zugegeben, ich gehe nicht davon aus, dass neue FPS kein E-Sport-Potenzial haben, obwohl es viele E-Sport-Turniere gibt, bei denen es um neuere FPS geht. Sie mögen nicht die gleiche Anziehungskraft haben, die CS auf einige Spieler ausübt, aber machen Sie nicht den Fehler zu glauben, dass diese Spieler alle E-Sportarten von FPS ausmachen.
Nicol Bolas
165
Beeindruckend. Das meiste interessiert mich gar nicht und es ist immer noch eine großartige Lektüre!
Peter Rowell
12
Which they, in all of Microsoft's collective imagination, called... the High Level Shading Language (HLSL).Ich habe mehr als 6 Minuten lang daran gearbeitet.
ApprenticeHacker
133

Ich fand es seltsam, dass sich jeder auf die Nutzerbasis konzentriert, wenn die Frage "Spieleentwickler" ist, nicht "Spieleditoren".

Für mich als Entwickler ist Linux eine blutige Sauerei. 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 (versuchen), damit sie zu seiner einzigartigen Kombination aus Paketen, Bibliotheken und passt Einstellungen, es ist ein Albtraum !

Andererseits 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-Versionen, ohne dass die richtigen DX- oder VC-Weiterverteilungsdateien installiert sind usw.

Eine letzte Sache, BITTE JEDER IM INTERNET STOPPEN IM VERGLEICH VON OPENGL UND DIRECTX! Vergleichen Sie Direct3D mit OpenGL oder tun Sie dies nicht . DirectX bietet Unterstützung für Eingaben, Sound, Filmwiedergabe usw., die OpenGL nicht unterstützt.

jv42
quelle
40
"Für mich als Entwickler ist Linux eine blutige Sauerei." Tatsächlich! Ich arbeite in einer Umgebung mit Fedora und Ubuntu. Wir haben sogar Probleme zwischen diesen beiden. (Ich muss hinzufügen, dass ich ein Linux-Fan bin.)
David Poole
48
@ jv42: Dies scheint ein weit verbreitetes Missverständnis zu sein: Fast alle dieser Versionen und Desktop-Manager und UI-Kits usw. sind für die Einrichtung eines funktionierenden Spiels ziemlich irrelevant. Wenn Ihr Spiel (wie ausgeliefert) von mehr als libGL, libX11 und libasound (oder libopenal oder libao oder liboss) abhängt, machen Sie etwas falsch.
greyfade am
19
@greyfade "Wenn dein Spiel (wie ausgeliefert) von mehr als libGL, libX11 und libasound (oder libopenal oder libao oder liboss) abhängt, machst du etwas falsch." - Und dann verlinken Sie auf libao-0.0.4alpha, und Ihr Benutzer hat libao-0.0.5beta und nichts funktioniert.
quant_dev
17
Es ist nicht so schwer, eine Binärdatei so zu packen, dass sie auf allen Linux-Distributionen läuft. Mist, die Blender-Entwickler machen das mit jeder Veröffentlichung. Es gibt nur das eine (nun zwei, 32-Bit- und 64-Bit-) Linux-Release-Paket von Blender.
Datenwolf
88

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

Arjun Bajaj
quelle
24
@ Mahmoud Hossam: Das stimmt nicht. Die Verwendung von OpenGL bedeutet nicht, dass Ihre gesamte Anwendung auf magische Weise unter einer * nix-Umgebung funktioniert. Es bedeutet, dass die Grafik-Engine (und selbst dann nicht, dass es unter Windows (zum Beispiel) keine Macken gibt, die dies nicht tun) gibt es unter Linux und umgekehrt). Das ist nicht der gesamte Warenkorb, und die Wartung des Codes für mehrere Plattformen ist definitiv mit erheblichen Kosten verbunden.
Ed S.
5
@ Mahmoud: Genau. Und wenn Sie sich ohnehin nicht die Mühe machen, auf Linux / Mac OS zu portieren, warum nicht die native Bibliothek verwenden? DirectX wird unter Windows viel besser unterstützt als OpenGL.
Dean Harding
10
@ Mahmoud: Die ganze Prämisse der Frage lautet "Warum bevorzugen Entwickler Windows?". Antwort: Das ist es, was Gamer benutzen. Es macht keinen Sinn, auf Linux / Mac zu portieren, wenn es nur 2% Ihres Marktes ausmacht, und in diesem Fall macht es keinen Sinn, OpenGL zu verwenden, wenn Sie es sowieso nicht portieren.
Dean Harding
4
@ Mahmoud, es ist nicht die Aufgabe der Spieleentwickler, die Leute zum Umstieg auf Linux zu bewegen.
GroßmeisterB
6
@ John 10+ Millionen World of Warcraft-Spieler möchten mit Ihnen sprechen. Und das ist nur ein Spiel.
Marcelo
50

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, ist unerheblich. Die Wahrnehmung ist da und beeinflusst die Entscheidungen der Menschen.

Mason Wheeler
quelle
1
Wenn Entwickler OpenGL verwenden, wird es sowohl Windows als auch Linux unterstützen, so dass es ein Marketingvorteil ist, Linux-Benutzer anzulocken, die bereit sind zu zahlen und Linux verwenden, weil sie glauben, dass es besser ist.
M.Sameer
9
Selbst mit OpenGL entstehen Kosten für die Entwicklung und das Testen von Cross-Plattformen, die der Linux-Markt nicht rechtfertigt. Directx ist derzeit (leider) auch eine bessere Plattform für PC-Spiele als OpenGL - es gibt nur sehr wenige neue Spiele auf PCs, die auf OpenGL basieren.
Martin Beckett
25
Cross Platforming ist nicht so einfach wie "Nur Code für OpenGL".
System Down
13
Das stimmt eigentlich nicht, dass Linux-Benutzer nicht für Software bezahlen. Das Humble Indie Bundle (ein Bundle von Spielen, die Sie für jede Menge Geld bekommen können, die Sie bezahlen möchten) wurde jetzt zweimal durchgeführt und jedes Mal, wenn Linux-Benutzer mehr als Windows-Benutzer für das Bundle bezahlten.
Htbaa
9
@Htbaa Natürlich haben sie mehr bezahlt, sie waren verzweifelt, es ist wahrscheinlich das einzige Spiel, das sie auf ihrem Betriebssystem spielen können.
Marcelo
11

Da Windows von einer großen Organisation unterstützt wird, haben sie vor mehr als einem Jahrzehnt beschlossen , dass die Spieleentwicklung auf ihrer Plattform stattfinden soll .

Dies stimmte nicht für den Mac, und es stimmt jetzt nicht. Nicht einmal für iOS. Apple bietet keine Tools für die iOS-Spieleentwicklung an. Aber es ist ein riesiger Markt (es gibt mehr iPhones als 1995) mit relativ geringer Konkurrenz, also machen die Leute es trotzdem.

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

Um heute ein PC-Spiel zu erstellen, braucht man viele 2D / 3D-Künstler, Game-Designer, Drehbuchautoren, Schauspieler, Tester und was nicht. Für die eigentliche Programmierung können Sie einfach eine eigentliche Game-Engine (CryEngine, Unreal Engine, Quake Engine, Source Engine) verwenden. Sie könnten also in der Lage sein, das Ganze ohne echte Programmierer zu machen.

Aus diesem Grund und aufgrund der Art der Unternehmen haben Programmierer wenig Einfluss darauf, für welche Plattform sie sich entscheiden. Und in der Regel suchen Manager nach Unterstützung, die Microsoft angeblich anbietet, und nach Lösungen, die für ihre Gedankenmuster irgendwie greifbar sind, was Open Source nicht ist.

Aus diesem Grund wird der Großteil der kommerziellen Endbenutzersoftware unter Windows entwickelt.
Ich arbeite für ein Unternehmen, das Flash-Spiele erstellt und somit nicht an eine bestimmte Plattform gebunden ist. Wir entwickeln jedoch alle unter Windows, da die meisten von uns verwendeten Tools nicht für Linux verfügbar sind.

back2dos
quelle
2
"Sie könnten also in der Lage sein, das Ganze ohne echte Programmierer zu machen." Du hast den Sarkasmus vergessen.
Allon Guralnek
@ AllonGuralnek: Kein Sarkasmus da. Bei der Entwicklung klassischer Spiele für große Spiele werden Programmierer Engines und Mittel erstellen, um Inhalt und Verhalten bereitzustellen (durch visuelle Editoren oder tatsächliche Skripterstellung), und dann werden Spiele- / Level- / Missionsdesigner diese Mittel verwenden. Wenn Sie einen funktionierenden und ausreichend leistungsstarken Motor kaufen, können Sie im Grunde den ersten Schritt streichen.
back2dos
2
Haben Sie ein konkretes Beispiel für ein einigermaßen bemerkenswertes Spiel, das erstellt wurde, ohne eine einzige Codezeile zu schreiben?
Allon Guralnek
1
@AllonGuralnek: Ich habe nicht gesagt, dass irgendjemand Spiele ohne Code erstellen würde , aber ohne Programmierer . Sie müssen kein Programmierer sein, um einen völlig wegweisenden Mod zu erstellen. DotA ist das beliebteste, das mir auf den ersten Blick einfällt.
back2dos
1
@ AllonGuralnek: Nein. Menschen, die Code schreiben, sind Menschen, die Code schreiben. Leveldesigner müssen ein gewisses Verständnis für Skripterstellung haben. Viele Programmierer müssen häufig über bestimmte Managementfähigkeiten verfügen. Es macht weder den ersten zum Programmierer noch den zweiten zum Manager. Auch Ihre Einschätzung von DotA ist falsch. Erstens ist es völlig Spiel verändernden, ein RTS in eine neue Wende Genre und zum anderen ist es als separates Spiel von vielen eSports - Ligen in Betracht gezogen , einschließlich der ESWC
back2dos
10

Wie einige bereits gesagt haben, ist der wichtigste Teil die Benutzerbasis. 95% der PC-Benutzer verwenden Windows. PC-Spieler verwenden fast ausschließlich Windows. Sogar 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 kostenlose Tools mit vollem Funktionsumfang , 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.

vartec
quelle
3
Hinweis für zeitreisende Leser: Ab April 2014 ist XNA offiziell tot. Die letzte Version (4.0) wurde 2010 veröffentlicht und wird bis zum Sonnenuntergang (2013) keine neue Version mehr sehen.
Aren
1
Ein weiterer Hinweis für zeitreisende Leser: Die Entwicklung von Windows 8 (und höher) wird in Zukunft nicht mehr kostenlos sein.
Fouric
6

Ewwww, ich nicht. Ich benutze fast ausschließlich Linux. Ich boote doppelt nach Windows, 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 trifft dies möglicherweise nicht zu, aber wir machen Top - Casual - Games (siehe Website - CSI: NY, Murder She Wrote und die beiden kommenden 2011er sind Beispiele für Titel mit wichtigen Lizenzen, The Verlorene Fälle von Sherlock Holmes 1 und 2 waren ebenfalls recht erfolgreich)

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

ggambett
quelle
3
gedit ist für die Programmierung unterschätzt
Alexander
2
@Alexander, unterschätzt beginnt nicht einmal zu erklären
Shahbaz
3
Sorry, ich habe gedit am Ende aufgegeben. Ich benutze jetzt gvim und ich bin viel glücklicher :)
ggambett
4
  1. Trägheit. Wenn Sie in der Vergangenheit Windows verwendet haben, ist der Wechsel zu etwas anderem mühsam. Wenn Sie mit Windows DirectX arbeiten, ist es einfacher und mit höherer Wahrscheinlichkeit besser als mit OpenGL.
  2. Marktanteil. Der Marktanteil von Windows auf dem Desktop ist größer als der von OS X, der wiederum größer als der von Linux ist. Geldgespräche.
  3. Marke. DirectX ist besser bekannt als SDL (das 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 ein Intro für modernes OpenGL verwenden? Kapitel 1: Die Grafik-Pipeline auf Ihrer Linux-Version?

Heutzutage ist Linux eher eine Kuriosität, wenn es um Spieleentwicklung geht, und die meisten Entwickler sind besser dran, eine OS X-Port-Version vor einer Linux-Version zu erstellen (siehe Steam). Selbst dann ist der Konsolenmarkt mehr wert als diese beiden Plattformen in Kombination für Spiele ...

Wenn Sie eine Monoplattform wollen, ist DirectX in Ordnung. Wenn Sie plattformübergreifend sein möchten, besteht eine große Chance, dass Sie OpenGL auf mindestens einigen der anderen Plattformen einsetzen müssen.

Anon
quelle
2
Die Antwort auf Frage 4 lautet: 2+. Mesa3D unterstützt bis zu OpenGL 2.1, was bedeutet, dass alle Grafiktreiber für 3D-Hardware für X11 mindestens OpenGL 2.1 seit Mesa Version 6.8 unterstützen. Dies gilt für alle Linux-Distributionen, die in den letzten Jahren veröffentlicht wurden, sowie für Binärtreiber, die von NVIDIA und AMD ab Version 3.0 unterstützt werden. Dies gilt nicht für Benutzer des Intel895, sie wurden jedoch als veraltet eingestuft.
greyfade
1
Ich fürchte, das ist nicht der Fall. Computer mit i915 / i945-Chipsätzen (GMA 900/950) werden (noch) verkauft und sind nicht veraltet. Selbst auf modernen Distributionen von vor einigen Monaten (Ubuntu 11.04 / Fedora 15) wird glxinfo eine OpenGL-Version nicht höher als 1.4 (Mesa 7.11-devel) zurückgeben. Solche Intel-Hardware kann spätere Versionen einfach nicht ohne Software-Hilfe ausführen. Solange Softpipe nicht standardmäßig verfügbar ist, wird Linux auf solchen Karten niemals eine höhere Version von OpenGL ausführen. Durch die Ausrichtung auf OpenGL 2.0 (oder höher) wird ein Programm gestoppt, das auf einer Vielzahl von Linux-Desktopsystemen ausgeführt wird ...
Anon
Trotzdem sehe ich die Besorgnis nicht. Dieselben Chipsätze haben Einschränkungen für Windows, sodass die meisten grafikintensiven Spiele sowieso nicht in
greyfade
4

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

Wenn Sie sich jemals die Frage stellen, warum jemand ... tut, denken Sie daran, dass Geld die Welt in Bewegung setzt.

Russell Horwood
quelle
1
Ja, aber Sie können ein plattformübergreifendes Spiel
erstellen
Plattformübergreifend zu sein ist nicht alles. Wenn die Anzahl der zusätzlichen Benutzer, die Sie erhalten, relativ gering ist, müssen Sie die zusätzlichen Entwicklungskosten und die laufenden Supportkosten gegen die zusätzlichen Kosten abwägen und eine fundierte Entscheidung treffen, die auf tatsächlichen harten Daten basiert. Es gibt keine global richtige oder falsche Antwort auf diese Frage, aber es gibt eine richtige oder falsche Antwort für jedes einzelne Programm, und was für ein Programm richtig ist, kann für ein anderes falsch sein.
Maximus Minimus
4

Werkzeuge, Werkzeuge, Werkzeuge.

Darauf kommt es an. Wenn Sie unter Windows entwickeln, erhalten Sie Zugriff auf einige der besten Entwicklungstools der Welt. Nichts kommt auch nur annähernd an den Debugger von Visual Studio heran, die DirectX-Debug-Laufzeiten sind fantastisch, PIX ist fantastisch und vergleichbare Entsprechungen existieren 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 diejenigen, die MS bereitstellt, sind dem Rudel nur so weit voraus (ehrenwerte Ausnahme: Valgrind), dass es nicht einmal lustig ist.

Unterm Strich helfen Ihnen diese Tools. Sie helfen Ihnen, 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 ringen, die sich nie so verhält, wie es dokumentiert ist.

Maximus Minimus
quelle
PIX ist großartig. Das Debuggen von Shadern, indem Sie auf ein störendes Pixel klicken und sehen, was passiert ist, ist großartig!
Chris Pitman
4

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.

Sehen Sie, wenn Sie auf einer Nintendo-Konsole sitzen möchten, müssen Sie die Erlaubnis von Nintendo einholen, bei Nintendo einkaufen, die Gemeinkosten von Nintendo bezahlen, mit Walmart verhandeln, sich um die Lagerhaltung kümmern , um alle Versicherungen zu machen, und so weiter.

Wenn du auf die XBox willst, sicher, dass es XBLA gibt, aber du brauchst immer noch den Segen von Microsoft, du musst warten, bis du an der Reihe bist, es sind Zehntausende von Dollar, nur um einen Patch zu veröffentlichen usw.

Unter iOS muss Apple noch in Ordnung sein, und sie können (und tun) Sie launisch ziehen.

Bei Steam benötigen Sie noch die Erlaubnis von Valve 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 bei der Entwicklung eines Spiels ist so viel * schreckliches * los, dass ich verspreche, einfach eine Binärdatei auf eine Site zu hauen und mich 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".

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

Windows bietet jedoch drei enorme Vorteile: eine wirklich offene Entwicklung, eine wirklich offene Bereitstellung und einen sehr großen, sehr aktiven Kundenstamm, der an eigenartigen Dingen interessiert ist.

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

John Haugeland
quelle
3

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

Ich denke, MS hat sich für DX gegenüber openGL entschieden, weil sie es mögen, Menschen daran zu hindern, ihr eigenes Betriebssystem zu verwenden.

Mahmoud Hossam
quelle
4
nein, sie DX erstellt , da OGL für Windows nicht optimiert ist, kann schnell die Vorteile der neuen Hardware und Betriebssystementwicklungen nehmen nicht erweitert werden, klingt nicht übernehmen, Steuereingang etc. etc ..
jwenting
2
iow DX ist aus Performancegründen auf Windows spezialisiert und ermöglicht es Microsoft, dies beizubehalten und neue Technologien schnell zu integrieren, sobald sie verfügbar sind. OpenGL ist auf dem Niveau der Grafikhardware-Unterstützung festgefahren, das es vor 5 Jahren gegeben hat, vielleicht mehr, weil es eine Komiteebemühung ist.
Jwenting
1
@jwenting Ich glaube nicht, dass Leistung der einzige Grund war, warum sie es nicht auf andere Plattformen portierten. Ich meine, wenn sie es portieren wollten, hätten sie es zumindest als Open-Source-Lösung bereitgestellt und es der Community überlassen, es zu implementieren es.
Mahmoud Hossam
1
Sie haben kein Open-Source-C # -Programm erstellt und die Sprachspezifikation den Normungsgremien vorgelegt. Microsoft ist Mitglied dieser Normungsgremien und tut dies die ganze Zeit (sie haben zum Beispiel große Beiträge zu HTML, Javascript und anderen Normen). Open Sourcing hätte zur Folge gehabt, dass der Quellcode für den Compiler und die Bibliotheken unter so etwas wie der APL veröffentlicht worden wäre.
Jwenting
1
@jwenting: Um es auf den Punkt zu bringen, es gibt eine Implementierung von Direct3D 10 und 11 unter Linux, die auf das Gallium3D-Framework abzielt. (Und es hat nichts mit Wine zu tun.) Ich würde auch Ihrer Behauptung widersprechen, dass "OGL nicht für Windows optimiert ist". Dies ist ein Problem bei der Implementierung von Hardwaretreibern, keine Einschränkung von OpenGL.
greyfade
1

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

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

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

D3D und OpenGL sind zwei sehr unterschiedliche APIs. Es liegt am Entwickler zu entscheiden, welche für Ihre Bedürfnisse geeignet ist.

bezaubern
quelle
0

Einfach, weil Linux als Desktop-System schrecklich versagt hat. Wie jemand früher betonte, 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 feine (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 mit dem Namen binaryApiNonsense.txt oder etwas in den Kernel-Quellen.) Allerdings wird unter Linux nur Nvidia-Hardware ordnungsgemäß unterstützt. Sie können die meisten ID-Softwarespiele mit Nvidia-Hardware unter Linux spielen.

Als nächstes Entwicklungstools. 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. Außerdem können Sie mit .net schnell GUI-Tools erstellen. Viele Spielestudios programmieren ihre Tools für den internen Gebrauch mit dem .net-Framework.

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

Nils
quelle
4
Hmm? Meine Intel- und ATI-Karten funktionieren unter Linux einwandfrei ... Und was stimmt nicht mit X11? Ich hatte immer das Gefühl, dass es aufgrund seiner Client-Server-Architektur viel besser ist als die Alternativen für andere Betriebssysteme (insbesondere Windows).
Alternative
Nein, sie geben keine glxinfo ein und sehen, ob es in Ordnung ist oder nicht! X11 ist schrecklich kaputt, nur ein Beispiel theinvisiblethings.blogspot.com/2010/08/…
Nils
und wenn Sie den letzten Satz lesen, hat Linus selbst den Kernel-Level-Patch implementiert - keinen X11-Patch.
Alternative
1
Ich weiß nicht viel über Grafiksysteme (Sie haben vielleicht einen Punkt), aber zu sagen, dass Linux als Desktop-System versagt hat, ist nicht wahr oder zumindest nicht genau. Ich bin von Windows zu Linux gewechselt und fühle mich seitdem sehr produktiv. Die Leistung von Linux ist und war Windows auf allen von mir verwendeten Computern überlegen. Ich codiere auch kein C ++ und möchte wissen, wo Eclipse als C ++ - IDE im Vergleich zu Visual Studio steht.
M.Sameer
Stell die Flammenwerfer ab. Ich denke, die allgemein akzeptierte Meinung ist, dass VS die beste IDE ist. Eclipse ist jedoch noch jung und hat noch viel zu tun - wir werden sehen. Ich finde es einfach toll, wie einfach unter Linux alles skript- und pipebar ist!
Vorac