4. Warum ist OpenGL unter Windows so unbekannt?

Warum ist OpenGL unter Windows so unbekannt?

  • A

    Hallo,

    einfache Frage: warum wird OpenGL im Vergleich zu DirectX unter Windows so wenig genutzt? Ich weiß zwar, dass die prozedurale API OpenGL im Vergleich zum objektorientierten DirectX deutlich schwerer zu meistern ist, aber ist das der Grund? Ich mein, warum gibt es keine Firmen, die sich auf Engines mit OpenGL spezialisiert haben, die ebenfalls objektorientiert aufgebaut sind, nur eben auf OpenGL basieren? Das würde den Umgang mit OpenGL vereinfachen.

    In der Industrie ist OpenGL ja nach wie vor vorherrschend. Ist DirectX mittlerweile so mächtig, dass sich niemand mehr zutraut ein Konkurrenzprodukt zu entwickeln?

    0
  • C

    Dieser Thread wurde von Moderator/in nman aus dem Forum Themen rund um den PC in das Forum Spiele-/Grafikprogrammierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • K

    Wie kommst du zu diesesn Annahmen? OGL wird ebenso wie DX ziemlich vielseitig genutzt.

    0
  • O

    DirectX ist aufgrund der massenweise vorhandenen Hilfsfunktionen viel angenehmer als OpenGL. Hinzu kommt, dass es für DirectX ein echtes SDK mit vielen Beispielen und Code gibt, das einem das Leben erleichtert. Es gibt eine ordentliche Referenz und eine gute Dokumentation. Auch ist DirectX immer eine Idee schneller, wenn es um neue Grafikkartenfeatures geht. Da OpenGL ein gemeinsamer Standard ist, braucht es immer eine Weile, bis neue Features darin aufgenommen wurden. Bis dahin muss man sich auf die Herstellerspezifischen Erweiterungen verlassen.

    Es liegt definitiv nicht daran, dass OpenGL nicht objektorientiert ist.

    In der Industrie ist OpenGL vorherrschend, weil Windows dort eine wesentlich schlechtere Position hat. Die Software muss also nicht nur unter Windows, sondern auch unter Unixderivaten lauffähig sein(Linux, MacOSX...), sodass man sich DirectX als Plattform nicht erlauben kann. Auch ist dort die Langsamkeit von OpenGL kein Nachteil, da die Meisten Industrieanwendungen die neuen Features gar nicht verwenden. Im Gegenteil, da wird oft Code verwendet, der so alt ist, dass die entsprechende DirectX Version unter Windows gar nicht mehr lauffähig wäre 🙂

    0
  • F

    Hallo Otze,

    da bin ich nicht ganz deiner Meinung! Was ist mit den Standard Werken Red Book, Orange Book und OpenGL Superbibl reichen die nicht als Doku und Anleitung wie man etwas programmieren kann?

    DirectX finde ich da viel Schlimmer, dort findet man meistens nur das Was und nicht das Wie.

    Schöne Grüße

    Fireball

    0
  • O

    FireballGFX schrieb:

    da bin ich nicht ganz deiner Meinung! Was ist mit den Standard Werken Red Book, Orange Book und OpenGL Superbibl reichen die nicht als Doku und Anleitung wie man etwas programmieren kann?

    Red Book ist absolut veraltet. Wer OpenGL >=3.2 verwenden möchte, kommt damit keinen Millimeter weit.

    Orangebook und OpenGL Superbible sind im Gegensatz zum SDK nicht gratis verfügbar. Auch ist die Superbible in der momentanen Version ebenso veraltet, obwohl ein komplettes Rewrite demnächst kommt. Die aktuelle 4th Edition ist von 2007 und ist daher in etwa so modern wie das Redbook. Das Orange Book befasst sich nur mit Shadern, und ich weiß nicht, wie modern das ist.

    In Conclusio gibt es zum zeitpunkt dieses Posts keinen vollumfänglichen Einstieg in OpenGl seit der API-Channge von 2008/2009.

    //edit nein, ganz stimmt das nicht. Ich hatte hier mal ein paar Schritte dokumentiert, die zum ersten OpenGL Programm mit Shadern >=3.1 führen. Das ist aber alles nur aus Tutorials wie zum beispiel aus dem OpenGL wiki zusammengeklaubt.

    0
  • *

    Deine initiale Annahme ist schon falsch. Was soll den das heissen: "Warum ist OpenGL unter Windows so unbekannt?"

    OpenGL ist unter Windows mindestens so bekannt, wie auf anderen Platformen. Auch der professionelle und industrielle Bereich werden auf Windows mit entsprechender Hardware und Software abgedeckt, wie auf keiner anderen Platform.

    Der Unterschied ist nur, dass Direct3D noch viel bekannter ist und weitaus mehr genutzt wird, allerdings mehr im Bereich Entertainment. Das liegt daran, dass man, wenn man wirklich state of the art Grafik umsetzen will, fast auf Direct3D setzen muss, weil dort Microsoft (unter Mitsprache der Hardwarehersteller) de Facto alle Interfaces diktieren kann - und so für die neuste Hardware sehr schnell eine einheitliche Programmierschnittstelle bereitstellen kann - wärend das Konsortium hinter OpenGL teilweise Jahre darüber diskutiert und am Ende, wie bei OpenGL 3.0 fast alle relevanten Änderungen versanden können.

    OpenGL muss aber auch ein wesentlich breiteres Spektrum an Anwendungen abdecken, weshalb diese Entwicklung verständlich ist. Direct3D kennt keine Spezifikation abgesehen von der Dokumentation, die Microsoft für die aktuellste Version veröffentlicht - und wenn es sein muss (bzw. wenn die Marketingabteilung es für notwendig hält, siehe Umstieg Windows XP auf Vista & 7), wird halt die Kompatibilität gestrichen, wie beim Schritt von 9.0 auf 10.0. Bei OpenGL geht sowas nicht. Die Industrie ist auf Kontinuität angewiesen, und es gibt 20 Jahre alte Software, welche noch laufen muss wie damals.

    0
  • A

    Ich hätte dazu schreiben sollen, dass ich mich mit 'unbekannt' (oder noch besser 'selten genutzt')auf die Spieleprogrammierung beziehe.

    OpenGL hinkt vllt. ein wenig bei der Aktualität hinterher. Aber das ist meines Erachtens kein Argument um sich gegen OpenGL zu entscheiden. Ich mein, wie viele Spieleentwickler nutzen schon alle Features, die eine Graka bietet? Das sind die Wenigsten.
    Brauchbare (Spiele-)Engines für OpenGL gibt es aber trotzdem fast keine. Dass fehlende Dokumentation OpenGL dabei ebenfalls im Weg steht leuchtet mir auch nicht so ganz ein. Leute, die eine eigene Engine programmieren haben ein bisschen mehr drauf als der Hobbyentwickler, der irgendwelche Minispiele entwickelt, die niemand spielen will. Diese Leute stört fehlende Doku nicht so sehr. Und die Engine sollte man dann natürlich bestmöglich dokumentieren.

    Vllt. liegt es ja daran, dass OpenGL eben nur eine Schnittstelle für graphische Sachen ist. DirectX bietet mittlerweile ja für jede erdenkliche Hardwarekomponente irgendeine Schnittstelle. Da hat man dann ein Softwarepaket, das einem (fast) alles bietet.

    0
  • K

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

    0
  • ?

    Nur als Korrektur:
    OpenGL Superbible 5.0 ist bereits erschienen 🙂
    http://www.starstonesoftware.com/OpenGL/
    rya.

    0
  • ?

    Antoras schrieb:

    Vllt. liegt es ja daran, dass OpenGL eben nur eine Schnittstelle für graphische Sachen ist. DirectX bietet mittlerweile ja für jede erdenkliche Hardwarekomponente irgendeine Schnittstelle. Da hat man dann ein Softwarepaket, das einem (fast) alles bietet.

    Ich denke, das ist ein guter Punkt. Mit OpenGL kriegst du "nur" die Grafik. Wenn du jetzt noch Sound und Netzwerk willst, muss man sich nach weiteren Bibliotheken umsehen. Und das ist dann meistens unschön, weil sich diese Bibliotheken irgendwie einen "Main-Loop" teilen müssen, um ihre IO-Aufgaben zu erledigen. Das führt dann meistens zu recht ekeligen Verrenkungen.

    0
  • ?

    ProgChild schrieb:

    Antoras schrieb:

    Vllt. liegt es ja daran, dass OpenGL eben nur eine Schnittstelle für graphische Sachen ist. DirectX bietet mittlerweile ja für jede erdenkliche Hardwarekomponente irgendeine Schnittstelle. Da hat man dann ein Softwarepaket, das einem (fast) alles bietet.

    Ich denke, das ist ein guter Punkt. Mit OpenGL kriegst du "nur" die Grafik. Wenn du jetzt noch Sound und Netzwerk willst, muss man sich nach weiteren Bibliotheken umsehen. Und das ist dann meistens unschön, weil sich diese Bibliotheken irgendwie einen "Main-Loop" teilen müssen, um ihre IO-Aufgaben zu erledigen. Das führt dann meistens zu recht ekeligen Verrenkungen.

    Kann ich absolut nicht nachvollziehen. Ich programmiere mit OpenGL, SDL, libsigc++ und für Sound nehme ich irrKlang. Und ich sehe in meiner MainLoop keine "ekligen Verrenkungen" um das zu erreichen was ich möchte. Noch dazu läuft irrKlang von Haus aus in threads und kann daher jederzeit parallel gestartet werden. irrKlang ist daher in der MainLoop gar nicht vorhanden.
    Selbst das übergeben von Tastaturanschlägen an sowas wie CEGUI wäre minimaler Aufwand und das ohne in die MainLoop direkt einzugreifen.
    Es kommt immer drauf an wie etwas realisiert wird.

    Hier meine Main Loop:
    http://code.google.com/p/nightlighttv/source/browse/NightLight/trunk/NightLightDLL/NLWindowGL.cpp#109

    rya.

    0
  • ?

    scorcher24@public.pc schrieb:

    Kann ich absolut nicht nachvollziehen. Ich programmiere mit OpenGL, SDL, libsigc++ und für Sound nehme ich irrKlang. Und ich sehe in meiner MainLoop keine "ekligen Verrenkungen" um das zu erreichen was ich möchte. Noch dazu läuft irrKlang von Haus aus in threads und kann daher jederzeit parallel gestartet werden. irrKlang ist daher in der MainLoop gar nicht vorhanden.

    Threads sind ekelig. 😃 Da hast du genau das Problem, das ich meine.

    Ich verwende OpenGL, SDL und für den Sound ebenfalls die SDL. Nur für das Netzwerk will ich nicht SDL_net verwenden, weil die IMHO extrem schlecht ist. Jetzt habe ich ein blockierendes select und einen Blockierenden SDL main Loop. Klar gibts da mehrere Workarounds um das jetzt miteinander zu kombinieren - einer davon sind halt threads - aber schön ist das meiner Meinung nach nicht.

    Wenn die SDL ne vernünftige Möglichkeit hätte, auf IO-Events zu reagieren, fände ich das schon schöner.

    0
  • ?

    Und warum sind Threads eklig oder unschön? Noch dazu wo es MultiCore Prozessoren gibt? Ich verstehe Dein Argument nicht so wirklich. Das hat aber alles nichts mit OpenGL zu tun. OpenGL ist genauso fähig den Job zu erledigen wie DirectX und auch in der schönen DirectX Welt gibt es Threads ;).

    Netzwerk gehört zu einer Grafikschnittstelle nun imho auch nicht gerade dazu. Dass DirectX das mit DirectPlay anbietet ist mir bekannt, aber wird das heutzutage noch ernsthaft genutzt? Hab von DirectX ehrlich gesagt nicht sooo viel Ahnung, aber ich fand bisher OpenGL immer elegant genug um meinen Spaß damit zu haben.
    rya.

    0
  • ?

    scorcher24@public.pc schrieb:

    Und warum sind Threads eklig oder unschön?

    Weil sie gewisse Probleme mit sich bringen. Wenn man mit Threads programmiert muss man immer aufpassen, dass man sich nicht den Speicher kaputt macht.

    scorcher24@public.pc schrieb:

    Noch dazu wo es MultiCore Prozessoren gibt?

    Bei einem solchen Einsatzzweck kannst du aber aus einem MultiCore System nicht wirklich Profit schlagen. Da muss man schon etwas mehr investieren.

    scorcher24@public.pc schrieb:

    Ich verstehe Dein Argument nicht so wirklich. Das hat aber alles nichts mit OpenGL zu tun. OpenGL ist genauso fähig den Job zu erledigen wie DirectX und auch in der schönen DirectX Welt gibt es Threads ;).

    Wie Direct3D, ja. Ich sage ja nicht, dass DirectX toll ist. Ich sage nur, wo ich im Moment ein Problem mit OpenGL, bzw. genauer mit der SDL habe. Und ich habe keine plattformunabhängige Bibliothek gefunden, die genau das tut, was ich will...

    Wenn ich wollte, könnte ich ja auch den kompletten Main-Loop selber schreiben. Das würde ja genau so gehen, wie ich es gerne hätte. Aber ich habe auch keine Lust, mich in plattformspezifischen Details zu verstricken.

    Und genau das ist der Nachteil, wenn deine Bibliotheken nicht so gut aufeinander abgestimmt sind.

    scorcher24@public.pc schrieb:

    Netzwerk gehört zu einer Grafikschnittstelle nun imho auch nicht gerade dazu.

    Nicht? Wäre ich jetzt nicht drauf gekommen. Aber darum ging es auch garnicht. Sondern um die Dinge, die du für ein Spiel brauchst.

    0
  • K

    ProgChild schrieb:

    Jetzt habe ich ein blockierendes select und einen Blockierenden SDL main Loop.

    Dann nimm doch etwas nicht-blockierendes. Mit SDL hatte ich bisher keine Probleme. Wenn dir die Bibliothek nicht zusagt, dann probiere doch mal http://www.sfml-dev.org/ .

    0
  • ?

    knivil schrieb:

    ProgChild schrieb:

    Jetzt habe ich ein blockierendes select und einen Blockierenden SDL main Loop.

    Dann nimm doch etwas nicht-blockierendes.

    Ebenfalls ein unschöner Workaround.

    knivil schrieb:

    Mit SDL hatte ich bisher keine Probleme. Wenn dir die Bibliothek nicht zusagt, dann probiere doch mal http://www.sfml-dev.org/ .

    Ich benutzte die SDL, weil ich sie schon für die beste der Möglichkeiten halte.

    0
  • N

    ProgChild schrieb:

    Ich benutzte die SDL, weil ich sie schon für die beste der Möglichkeiten halte.

    Im Bezug auf was?

    Ich habe früher auch die SDL benutzt, und bin der Meinung, in SFML ist vieles besser und intuitiver gelöst. Zumindest die Teile, die ich von SDL her kannte (hauptsächlich Grafik-Modul).

    0
  • ?

    Nexus schrieb:

    ProgChild schrieb:

    Ich benutzte die SDL, weil ich sie schon für die beste der Möglichkeiten halte.

    Im Bezug auf was?

    Im Bezug auf das, was ich vor habe.

    Nexus schrieb:

    Ich habe früher auch die SDL benutzt, und bin der Meinung, in SFML ist vieles besser und intuitiver gelöst. Zumindest die Teile, die ich von SDL her kannte (hauptsächlich Grafik-Modul).

    Ich brauche eigentlich nur ein möglichst leichtgewichtige Initialisierung von OpenGL, Tastatur, Maus, Joystick, Sound und IO Multiplexing. SFML tut mir da an manchen Stellen schon zu viel.

    0
  • K

    @ProgChild: Also alles ist irgendwie unschoen? Vielleicht ist dein Design einfach nur schlecht!

    Weil sie gewisse Probleme mit sich bringen. Wenn man mit Threads programmiert muss man immer aufpassen, dass man sich nicht den Speicher kaputt macht.

    Keine Ahnung, was du damit meinst. Ist mir noch nie passiert.

    0
Anmelden zum Antworten