DirectX oder OpenGL

[Raven280438]

Hi,

ich möchte mich näher mit der Spieleprogrammierung beschäftigen.
Ich habe Erfahrung in C++/C#/Java.

Meine Frage ist, mit was soll ich mich beschäftigen? DirectX oder OpenGL?
Was ist besser dokumentiert und für Einsteiger besser geeignet? Welches von beiden hat einen größeren Funktionsumfang?
Viele Tutorials die ich gefunden habe sind inzwischen schon veraltet.

Bibliotheken wie SFML etc. wollte ich erstmal nicht verwenden.


Gruß

[Krishty]

Willst du nur Windows unterstützen oder auch andere Plattformen?

[Raven280438]

Hi,

stimmt, ist natürlich ein wichtiger Punkt den ich vergessen habe.
Erstmal wollte ich nur für Windows programmieren.



Gruß

[kimmi]

DirectX ist die "native" Landessprache unter Windows, um mit der Grafik-Programmierung zu beginnen. Von da aus läge es nahe, damit anzufangen. DIe Prinzipien sind ähnlich zu OpenGL.

Gruß Kimmi

[Chromanoid]

Willst Du auch mal später für mobile Endgeräte entwickeln? Wie sieht es perspektivisch mit WebGL aus?
Wenn Du nichts highendmäßiges planst, würde ich aus diesen Gründen zu OpenGL greifen.

[Raven280438]

Hi,

gibt es irgendwelche gravierenden Gründe bzw. Nachteile, die gegen OpenGL sprechen?


Gruß

[Krishty]

Ich habe mal vom Schwager der Kusine des Verlobten meiner Maniküre gehört, dass die Windows-Treiber nicht so pralle sein sollen. Aber da musst du wen fragen, der auch tatsächlich damit arbeitet.

[kimmi]

Ich persönlich habe schon des öfteren Probleme mit miesen OpenGL-Treibern auf Intel-Chips gehabt. Ansonsten finde ich persönlich OpenGL3.0 und größer besser als DirectX. Aber man hat halt auch mehr Probleme. Gute Debugger kosten, Treiber sind nicht alle gut gepflegt und die Doku, die man im Netz beziehen kann, ziehlt gern ncoh auf OpenGL <3.0 ab.

Gruß Kimmi

[Matthias Gubisch]

Vom Funktionsumfang nehmen sich die beiden nicht viel, auch Performancemäßig habe ich bisher keine gravierenden Probleme mit OpenGL festgestellt.
Treiberprobleme hatt ich bisher auf Nvidia-Karten keine größeren (solang ich nicht versucht hab OGL mit CUDA zu kombinieren)

Ich finde OpenGL ab der Version4 eigentlich ganz angehm zu benutzen, zur benutzung von DirectX kann ich nichts sagen da es schon etwas her ist seit ich damit zum letzen mal gearbeitet habe (war noch DirectX10).
Nachteil bei OpenGL ist dass man sich die Doku mehr oder weniger selber zusammensuchen muss, vor allem weil viele Tutorials wie Kimi schon gesagt hat veraltet sind. Da hat DirectX sicher einen Vorteil.

[NytroX]

Hm, komisch, das ist das erste Mal dass ich auf so eine Frage vernünftige Antworten in einem Forum sehe :D

Es kommt tatsächlich darauf an, was genau du erreichen willst.
Wenn du z.B. wie ich so hobby-mäßig damit hantieren willst, macht es Sinn, sich einzuschränken, was Kompatibilität angeht.
Ich persönlich würde nur noch DX >= 11 oder OGL >=4.2 nehmen. Das haben zwar nicht alle, aber die APIs sind doch wesentlich angenehmer in der Nutzung und funktionieren eigentlich fehlerfrei mit neueren Treibern, wenn man einfach davon ausgeht, dass ein bestimmter Mindeststandard erfüllt wird.
Ich würde zudem nur auf neuere Funktionalitäten zurückgreifen, d.h. Shader in höheren Versionen, keine Fixed-Function-Zeugs mehr und nur noch neuere Buffer-typen.
Das ist denke ich leichter zu verstehen und zu lernen, und der Gesamtumfang an Wissen, den man braucht, ist wesentlich kleiner.

Dann gibt es auch zwischen DX und OGL quasi keine Unterschiede was den Funktionsumfang betrifft.

Detaillierter könnte man vielleicht noch sagen, dass OGL etwas komplizierter ist, bis man mal ein Grundgerüst hat (es sei denn, man verwendet entsprechende Libraries), aber bei DirectX muss man besser aufs sein Software-Design achten, sonst kommt man sich mit den Objekt-Abhängigkeiten irgendwann evtl. selbst in die Quere (hat sich meiner Meinung nach von DX10 zu DX11 verschlimmert).

Und obwohl du es explizit nicht verwenden willst: für einen Schnellstart habe ich gute Erfahrungen mit Java+SFML gemacht.
Kein Compiler-Konfigurier-Marathon, kein Versions-Chaos, sondern einfach den Krams Installieren und es läuft ohne viel Gefrickel; auch auf anderen Systemen (wenn man mal kurz einen Freund was ausprobieren lassen will); da war ich echt positiv überrascht.

[dot]

Dann gibt es auch zwischen DX und OGL quasi keine Unterschiede was den Funktionsumfang betrifft.

Eine Sache, die mir an OpenGL persönlich abgeht, ist die Möglichkeit, Shader zur Buildtime kompilieren. Ansonsten ist OpenGL 4.3 praktisch das gleiche wie Direct3D 11, wird aber genaugenommen bisher nur von NVIDIA supported...

Mein Rat wär, erstmal mit SFML anzufangen...

[Artificial Mind]

Eine Sache, die mir an OpenGL persönlich abgeht, ist die Möglichkeit, Shader zur Buildtime kompilieren.

Von welchen Funktionen sprichst du dort genau? gl(Get)ProgramBinary? Wenn ja, dann kannst du das zwar zum Entwickeln nutzen aber deployen musst du trotzdem den Source, denn:

A program binary may fail to load if the implementation determines that there has been a change in hardware or software configuration from when the program binary was produced such as having been compiled with an incompatible or outdated version of the compiler.

Diese Funktionalität ist wirklich nur zum Cachen von Shadern gedacht, damit diese schneller laden. Laut g-truc funktioniert das auch noch nicht unter Mac.

[Sternmull]

Ich sehe auch keinen Grund gegen OpenGL. D3D hab ich allerdings seit über 10 Jahren nicht mehr angefasst, kann also nicht sagen ob das besser oder schlechter ist.

Für OpenGL dürfte wohl die breitere Plattformunterstützung sprechen: D3D bietet z.B. nicht so was wie WebGL oder Android-Unterstützung. Wobei natürlich zu überlegen ist inwieweit das in diesem konkreten Fall überhaupt eine Rolle spielt.

Unter Android kann man auf nicht ganz veralteten Gräten davon ausgehen das OpenGL ES 2.0 verfügbar ist. Das dürfte in entwa einem OpenGL 3.1 entsprechen. Weil es ab OpenGL 3.1 keine fixed function pipeline und kein glBegin/glEnd etc. gibt, würde ich also dringend dazu raten gleich von Anfang an darauf zu verzichten (in den neueren Versionen ist das halt abgeschafft). Das erfordert allerdings ein bisschen mehr Arbeit vom Programmierer (Shader statt fixed function pipeline, Matrizen selber zusammenbauen statt glFrustum etc. zu verwenden, Vertex-Puffer bestücken und verwenden statt glVertex usw.). Um da nicht beim Urschleim anfangen zu müssen empfehle ich die Verwendung einer Bibliothek für lineare Algebra. Die sollte dann so was wie Matrix-Manipulation übernehmen. Wichtig ist dabei das die Bibliothek OpenGL-kompatible Datenstrukturen verwendet, so das man die Rotationsmatrix dann z.B. direkt ins OpenGL laden kann. Ich hab bei meinen letzten OpenGL-Spielereien Eigen verwendet und war damit auch ganz zufrieden. Aber es gibt sicherlich diverse Alternativen.

[Artificial Mind]

Wenn wir schon bei OpenGL-Empfehlungen sind:

GLM ( http://glm.g-truc.net/ ) als Mathelib ist sehr angenehm, da es mehr oder minder direkt glsl in C++ ist. (Gleiche Funktionsnamen und Datentypen usw.)
Als Tutorial kann ich immer http://www.opengl-tutorial.org/ empfehlen, das ist modern und einfach.

[Jonathan]

Die beiden Empfehlungen von Artivicial Mind kann ich bestätigen.

Darüberhinaus benutze ich glLoadGen als Extension-Loader (man braucht Lua um die Quellcodedateien zu generieren, hat dafür aber ein paar ganz nette Optionen zur Auswahl, z.b. alle deprecated Funktionen gar nicht erst in den Header zu packen).

Darüberhinaus benutze ich GLFW um OpenGL zu initialisieren und FreeImage um Bilddateien zu laden. Und Assimp um Modelldateien zu laden. OpenGL ist halt nur fürs Rendern, für alles weitere braucht man Zusatzbibliotheken.


DirectX habe ich vor langer Zeit mal benutzt. Bei OpenGL hast du halt nur Funktionen, bei DX ein irgendwie Objektorientiertes Interface (kenne aber nur das von Version 9, es hat sich gewiss einiges geändert). Letztendlich musst du aber eh raussuchen, wie du was machst, es ist nie besonders hübsch so eine low-level API zu benutzen (gilt für DX und OpenGL), egal ob sie jetzt objektorientiert ist, oder nicht. Und da beides nur Abstraktionen von der Grafikkarte sind, ist der Funktionsumfang und die Geschwindigkeit auch quasi gleich, es mag bei jeder neuen Version kleine Schwankungen geben, aber im großen und ganzen tut sich da nicht viel.


Ich benutze OpenGL weil ich auch irgendwann für Linux kompilieren will. Aber ich habe auch gehört, dass der DX Debugger von Microsoft (PIX oder so) ziemlich cool sein soll. Das Beste, was ich bisher für OpenGL gefunden habe, ist Code XL, aber das ist in vielen Fällen auch eher so meh (weil teilweise sinnfreie Dinge angezeigt werden und so).

[antisteo]

Ich persönlich habe schon des öfteren Probleme mit miesen OpenGL-Treibern auf Intel-Chips gehabt.

Unter Windows definitiv. Unter Linux ist es genau andersrum.

Hi,

gibt es irgendwelche gravierenden Gründe bzw. Nachteile, die gegen OpenGL sprechen?


Gruß

Siehe kimmi, allerdings gibt es deutlich mehr Gründe, die gegen DX sprechen.

Als Debugger für OpenGL kann ich Apitrace empfehlen.

[dot]

Ich persönlich habe schon des öfteren Probleme mit miesen OpenGL-Treibern auf Intel-Chips gehabt.

Unter Windows definitiv. Unter Linux ist es genau andersrum.

Wie siehts mit OpenGL 4.x Support aus? Irgendwie ist das bei uns ständig ein Problem...

Hi,

gibt es irgendwelche gravierenden Gründe bzw. Nachteile, die gegen OpenGL sprechen?


Gruß

Siehe kimmi, allerdings gibt es deutlich mehr Gründe, die gegen DX sprechen.

Das Hauptproblem mit Direct3D ist, dass es von Microsoft ist. Technische Aspekte werden vor diesem Hintergrund von vielen leider völlig ignoriert... ;)

[waigie]

Wie siehts mit OpenGL 4.x Support aus? Irgendwie ist das bei uns ständig ein Problem...

Die Intel Treiber unter Linux nutzen die Mesa OpenGL Implementierung. Version 10 unterstützt OpenGL 3.3 komplett. OpenGL 4.x wird nicht offiziel supportet und es stehen nicht alle nötigen OpenGL Erweiterungen zur Verfügung.

[suke]

Was OpenGL-Support unter Linux angeht, ist man ein paar Jahre hinten. OpenGL 3.3 wurde erst vor kurzem vollständig implementiert, aber dafür ist OpenGL ES 3.0 (so gut wie) fertig. Laut http://www.phoronix.com/scan.php?page=n ... px=MTUyNzg gibt es OpenGL 3.3 nur für die Intel Ivy Bridge und Haswell-Chips. Für Sandy Bridge gibt es einige Hürden für den OpenGL 3.3-Support.
Den aktuellen Status der OpenGL-Unterstützung der freien Treiber, kann man hier nachschauen http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

[Artificial Mind]

Was OpenGL-Support unter Linux angeht, ist man ein paar Jahre hinten. OpenGL 3.3 wurde erst vor kurzem vollständig implementiert, aber dafür ist OpenGL ES 3.0 (so gut wie) fertig. Laut http://www.phoronix.com/scan.php?page=n ... px=MTUyNzg gibt es OpenGL 3.3 nur für die Intel Ivy Bridge und Haswell-Chips. Für Sandy Bridge gibt es einige Hürden für den OpenGL 3.3-Support.
Den aktuellen Status der OpenGL-Unterstützung der freien Treiber, kann man hier nachschauen http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

Du beziehst dich nur auf die freien Treiber, aber ich würde die von NVidia und ATI angebotenen Treiber für Linux schon unter "OpenGL-Support unter Linux" zählen. Und dort ist NVidia immer sehr aktuell und ATI hat mit Ausnahme von ein paar Bugs (die wahrscheinlich auch unter Windows existieren) auch aktuelle Treiber.

[glassbear]

Du beziehst dich nur auf die freien Treiber, aber ich würde die von NVidia und ATI angebotenen Treiber für Linux schon unter "OpenGL-Support unter Linux" zählen. Und dort ist NVidia immer sehr aktuell und ATI hat mit Ausnahme von ein paar Bugs (die wahrscheinlich auch unter Windows existieren) auch aktuelle Treiber.

AMD hat unter OpenGL auf allen OS vor allem nur 50-70% der Performance von ihren D3D-Treibern. Laesst sich einfach mittels Unigine Valley nachpruefen.
Deren Linux binary Treiber sind ein Witz (meine XFX Radeon 7970 ist "Unsupported Hardware", die wurde vor ueber einem Jahr released...), genauso wie die OS X Treiber.

Da ja schon einige mit Phoronix-Links ankamen, hier die neuen R290 unter Linux: http://www.phoronix.com/vr.php?view=19371 und aeltere Karten sind nicht besser :roll: Dafuer kann man die APUs langsam verwenden, mit OSS Treibern.

[suke]

Du beziehst dich nur auf die freien Treiber, aber ich würde die von NVidia und ATI angebotenen Treiber für Linux schon unter "OpenGL-Support unter Linux" zählen. Und dort ist NVidia immer sehr aktuell und ATI hat mit Ausnahme von ein paar Bugs (die wahrscheinlich auch unter Windows existieren) auch aktuelle Treiber.

Da die Closed source-Linux-Treiber einen Großteil des Codes mit dem Windows-Treiber teilen, sind die Treiber beider Plattformen vergleichbar. Natürlich muss man beim Vergleich achten. Ich habe in letzter Zeit bemerkt, dass immer mehr Leute ihr Linux-System mit den OSS-Treiber benutzen, weil sie out-of-the-box funktionieren und halbwegs stabil und benutzbar sind.

Die Entwickler des Dolphin-Emulators haben einen Artikel geschrieben, wo sie über ihre Erfahrung mit den OpenGL-Treibern von Windows-, Linux- und Android-Systemen berichten.

@OP: Falls du irgendwann auch für kleinere Systeme, wie Smartphones, Spiele schreiben willst, so ist dort OpenGL ES dominant. Die WinPhones haben Direct3D drauf, aber davon habe ich zuwenig Ahnung. OpenGL ES 2.0 setzt sich langsam auch auf dem Desktop durch. Dort unterstützen die Treiber die ARB_ES2_compatibility-Extension oder man kann auf Libraries, wie ANGLE, zugreifen.

[glassbear]

Und noch was anderes zu OpenGL: Funktioniert nicht unter Windows 8(.1) bei 64 Bit: http://connect.microsoft.com/VisualStud ... s-8-64-bit :roll:

[Raven280438]

Hi,

ich hab mich jetz doch erstmal für DirectX entschieden.

Meine nächste Frage: Lohnt es sich, direkt mit DirectX 11.1 anzufangen, oder doch erstmal DirectX10/11?

Braucht man für DirectX11.1 eine moderne Grafikkarte, oder geht das auch mit etwas älternen Modellen?


Gruß

[antisteo]

Du brauchst für DirectX11 ein aktuelles Windows. (Und auch eine aktuelle Grafikkarte, aber das ist kein Problem, da du eh ein paar Jahre entwickelst und das Ding bis dahin jeder hat)

[Schrompf]

Nicht ganz. Leider ist die Nomenklatur da etwas verwirrend.

Es gibt DirectX10/11 als Schnittstelle. Das ist eine banale API, die ab Vista aufwärts verfügbar ist. Davon kannst Du verschiedene Schnittstellen anfordern, die jeweils den Funktionsumfang von Direct3D 10.0, 10.1, 11.0 usw. bereitstellen. Welches Direct3D Du also benutzt, ist eine Entscheidung bei Programmstart. Es gibt über diese Schnittstelle sogar ein Direct3D9, das dann auch mit Prä-DX10-Hardware läuft.

Du bekommst diese Schnittstelle aber nur, wenn die Hardware das auch unterstützt. Da dürfte heutzutage alles D3D11.0 sein, mit ein paar Ausnahmen, die einige Jahre älter sind. 11.1 gibt es aber nur für Windows8.1, warum auch immer. Das 11.1 kannst Du aber auch ignorieren, glaube ich. Da stecken keine so bahnbrechenden Verbesserungen mehr drin, als dass Dich das irgendwie aufhalten würde. 11.0 ist ein gutes Ziel für alle Vorhaben, und selbst mit 10.0 wirst Du lange Zeit an keine Grenzen stoßen.

[eXile]

Es ist sogar noch etwas komplizierter.

Treibermodell:

• WDDM driver—mind. Windows Vista
• WDDM 1.1 driver—mind. Windows 7
• WDDM 1.2 driver—mind. Windows 8 (kein Windows 7 jedweder Art)
• WDDM 1.3 driver—mind. Windows 8.1

DXGI runtime:

• DXGI runtime—mind. Windows Vista
• DXGI 1.1 runtime—mind. Windows Vista SP2 mit Platform Update
• DXGI 1.2 runtime—mind. Windows 7 mit Platform Update
• DXGI 1.3 runtime—mind. Windows 8.1

Direct3D runtime:

• Direct3D 10 runtime—mind. Windows Vista
• Direct3D 10.1 runtime—mind. Windows Vista SP1
• Direct3D 11 runtime—mind. Windows Vista SP2 mit Platform Update
• Direct3D 11.1 runtime—partiell mind. Windows 7 SP1 mit Platform Update, vollständig mind. Windows 8
• Direct3D 11.2 runtime—mind. Windows 8.1

Feature levels:

• D3D_FEATURE_LEVEL_9_1
• D3D_FEATURE_LEVEL_9_2
• D3D_FEATURE_LEVEL_9_3
• D3D_FEATURE_LEVEL_10_0—mind. Direct3D 10 runtime, und entsprechende GPU
• D3D_FEATURE_LEVEL_10_1—mind. Direct3D 10.1 runtime, und entsprechende GPU
• D3D_FEATURE_LEVEL_11_0—mind. Direct3D 11 runtime, und entsprechende GPU
• D3D_FEATURE_LEVEL_11_1—mind. Direct3D 11.1 runtime, mind. WDDM 1.2, und entsprechende GPU
• Es gibt kein D3D_FEATURE_LEVEL_11_2.

Optionale Features:

• D3D11_FEATURE_DATA_THREADING—mind. Direct3D 11 runtime
• D3D11_FEATURE_DATA_DOUBLES—mind. Direct3D 11 runtime
• D3D11_FEATURE_DATA_FORMAT_SUPPORT—mind. Direct3D 11 runtime
• D3D11_FEATURE_DATA_FORMAT_SUPPORT2—mind. Direct3D 11 runtime
• D3D11_FEATURE_DATA_D3D10_X_HARDWARE_OPTIONS—mind. Direct3D 11 runtime
• D3D11_FEATURE_DATA_D3D11_OPTIONS—mind. Direct3D 11.1 runtime
• D3D11_FEATURE_DATA_ARCHITECTURE_INFO—mind. Direct3D 11.1 runtime
• D3D11_FEATURE_DATA_D3D9_OPTIONS—mind. Direct3D 11.1 runtime
• D3D11_FEATURE_DATA_SHADER_MIN_PRECISION_SUPPORT—mind. Direct3D 11.1 runtime
• D3D11_FEATURE_DATA_D3D9_SHADOW_SUPPORT—mind. Direct3D 11.1 runtime
• D3D11_FEATURE_DATA_D3D11_OPTIONS1—mind. Direct3D 11.2 runtime
• D3D11_FEATURE_DATA_D3D9_SIMPLE_INSTANCING_SUPPORT—mind. Direct3D 11.2 runtime
• D3D11_FEATURE_DATA_MARKER_SUPPORT—mind. Direct3D 11.2 runtime

Das ist es zumindest, was ich aus der MSDN aus vollkommen verstreut liegenden Orten rausziehen konnte. Keine Garantie für Korrektheit. ;)

[Jörg]

Nur unwesentlich kürzer als http://www.khronos.org/registry/gles/ ;)
Immerhin ist die Diversität auf GLES3-Platformen noch gering (was Extensions angeht).

[eXile]

Wie man sieht, hat Microsoft ab Direct3D 11/D3D_FEATURE_LEVEL_11_0 meiner Meinung nach den Fehler gemacht, wieder die Features optionaler zu machen (wir sehen von Format-Support ab, es geht nur um Feature-Support):

• Ab Direct3D 10:
  • Mit D3D_FEATURE_LEVEL_10_0/1 ausschließlich obligatorische Features,
  • und gar keine optionalen Features.
• Ab Direct3D 11/11.1:
  • Mit D3D_FEATURE_LEVEL_11_0/1 ein paar obligatorische Features,
  • und mit D3D11_FEATURE_DATA_* ein paar optionale Features.
• Ab Direct3D 11.2:
  • Gar keine neuen obligatorische Features,
  • und mit D3D11_FEATURE_DATA_* nur noch optionale Features.

Mit Direct3D 10 sollte eigentlich die schöne tolle Welt der festgemeißelten Feature-Levels beginnen. Doch mit den letzten Releases haben wir diese Transformation komplett rückgängig gemacht. Von nur noch obligatorisch zu nur noch optional.

Das schließt sich direkt an etwas an, was hier noch gar nicht zur Sprache gebracht wurde: Überhaupt ist Microsoft in der Lage, Feature-Levels zu forcieren. Wenn Microsoft sagt, Feature XY ist für Feature-Level Z obligatorisch, dann ist das von den IHVs umzusetzen.

Wenn sie es nicht tun, gibt es eben nicht dieses Feature-Level-Prädikat für die. Das hat in der Vergangenheit gut funktioniert, nur gegenwärtig sträuben sich die IHVs wohl extrem stark dagegen (daher wohl auch die vielen optionalen Features, und die aktuelle Verzagtheit hauptsächlich bei Nvidia).

Das Vorschreiben und Forcieren von Feature-Leveln ist ein definitiver Unterschied zur Khronos-Group.

Wenn man hier von Unterschieden sprechen will, dann wohl auch davon. ;)

[dot]

Und noch was anderes zu OpenGL: Funktioniert nicht unter Windows 8(.1) bei 64 Bit: http://connect.microsoft.com/VisualStud ... s-8-64-bit :roll:

Das scheint mir ein Problem mit MFC zu sein, OpenGL läuft unter 64 Bit Windows 8.1 völlig problemlos...