spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

OpenGL ist genauso an die Hardware gebunden wie DirectX.

Teilweiße ist der Softwarerenderer eventuell besser.
Aber der ist in der Regel so langsam, dass er sowieso nichts taugt.

Manchmal können aber neuere Features mit Extensions auch in ältere Versionen verfügbar sein.


Wenn man mit OpenGL neu anfängt, sollte man sich noch überlegen, ob man das "alte" OpenGL oder das "neue" OpenGL (ab Version 3) verwendet.

Zitat von »Mirac«

Hab gerade darüber nachgedacht OpenGL statt DirectX zu nehmen, hab aber dazu eine (kleine) Frage:

Ist OpenGL, genau so stark wie DirectX durch die Hardware eingeschränkt? Zum Beispiel kann meine 3 Jahre alte Graka (damals 350€ teuer) nichts mit DX11 anfangen

OpenGL Versionen erscheinen ja in größeren Abständen (oder täusche ich mich da? )



mfg Mirac

Nun, mit den Versionen ist es etwas komplizierter bei OpenGL.

OpenGL bietet erstmal Extensions. D.h. zum einen, das Nvidia und ATI neue Features ihrer GPUs so schon anbieten können, bevor irgendjemand (Microsoft für DirectX, oder das ARB für OpenGL) eine allgemeine API für dieses Feature spezifiziert hat. Und über diese Extensions sind neue Features auch in älteren Versionen verfügbar.

Dann gibt es ab und an eine neue Version. Ab und an passiert dabei etwas besonderes, meistens aber werden dann nur einige bestehende Extensions in OpenGL (ohne Extensions) integriert. Der Wert für den Entwickler? Ich glaub nahe bei null.

Vom Prinzip her ist OpenGL aber, wie bereits schon geschrieben worden ist, genauso hardwareabhängig wie DirectX. Deine Karte wird mit OpenGL jetzt nicht auf wundersameweiße anfangen Tesselation in dem Stil von DX11 zu unterstützen, auch wenn das mit OpenGL prinzipiell natürlich genauso möglich wäre.

Zitat

Wenn man mit OpenGL neu anfängt, sollte man sich noch überlegen, ob man das "alte" OpenGL oder das "neue" OpenGL (ab Version 3) verwendet.

Sollte man nicht. Einfach ab OpenGL 3.x anfangen. Alles andere ist veraltet und man lern nur Unsinn.

Das alte ist aber pädagogisch schöner. Es macht einfach keinen Spaß, direkt Vertexbuffer zu erstellen oder Shader zu schreiben. Für den Anfang ist es viel einfacher, glVertex zu benutzen und die States zu setzen, die man gerne hätte.
Aber eben auch nur, um so ein Gefühl dafür zu bekommen, letztendlich benutzen sollte man es natürlich nicht mehr.

Das würde ich gar nicht mal so sagen. Wenn man die neue Art gleich richtig gelernt bekommt, ist es deutlich ansprechender, weil man wirklich sieht was in den einzelnen Schritten passiert und nicht irgendwelche magischen Befehle ausführt und dann hat man plötzlich ein Bild.

Hauptproblem ist oft nur die Herangehensweise. Denn meist kommen die Leute und sagen sich "Jetzt will ich was in 3D machen, deshalb schau ich mir jetzt OpenGL/DirectX an". Was man eigentlich tun müsste ist "Jetzt will ich was in 3D machen, jetzt schau ich mir erstmal an, wie man heutzutage von einem 3D Model zu einem gerenderten Bild kommt und schaue mir dann an, wie das OpenGL/DirectX umsetzt".

Den meisten fehlt der Hintergrund, warum man Vertexbuffer und Shader verwendet und wie das alles zusammenhängt. Dann versteht man auch nicht die Unterschied zwischen Model-, View, und Projectionspace und kann dann auch nicht nachvollziehen, wofür man die ganzen Matrizen braucht und wie man sie richtig erstellt.

Und wenn man gleich mit OpenGL 3+ anfängt, kann man sich auch nicht immer vor der Shaderprogrammierung drücken!
Ich selbst bastele gerade eine 2D-Engine mit neuem OpenGL.

Das war mal so. Prinzipiell ist es egal welche API du verwendest, heutzutage mehr denn je. Beide APIs tun mehr oder weniger genau das gleiche und sind am Ende nur eine eher dünne Schicht zwischen dir und dem Grafiktreiber. Nimm was dir besser gefällt. Wenn du nur für Windows entwickelst, dann wäre Direct3D meine definitive Empfehlung, aber die übliche Direct3D vs OpenGL Diskussion führen wir hier so regelmäßig, dass eine kurze Forensuche dich sicherlich auf die entsprechenden Threads bringen wird