Warum ist OpenGL unter Windows so unbekannt?

otze

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.

*rant*

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.

Antoras

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.

knivil

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

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

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.

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.

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.

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.

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.

knivil

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/ .

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.

Nexus

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).

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.

knivil

@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.

knivil schrieb:

@ProgChild: Also alles ist irgendwie unschoen?

Ja. Ich hätte gerne einen Main-Loop, der auf alle Events reagiert. Und zwar in einem Thread.

knivil schrieb:

[...]

Erspare mir einfach deine Arroganz, ok?

knivil

Ja. Ich hätte gerne einen Main-Loop, der auf alle Events reagiert. Und zwar in einem Thread.

Nee, ist unschoen. Auch widersprichst du dir selbst:

Und das ist dann meistens unschön, weil sich diese Bibliotheken irgendwie einen "Main-Loop" teilen müssen, um ihre IO-Aufgaben zu erledigen.

Auch stimmt das nicht, dass sich alle einen MainLoop/Thread teilen muessen. Aber vor Threads hast du ja auch irgendwie Angst. Alles wird mit unschoen oder eklig abgeschmettert, gepaart mit vagen Anforderungen a la "ich haette gern, dass SDL ... aber SFML macht mir da schon etwas zu viel". Ich schaue mir meine Programme mit SDL an und kann keinen deiner vagen Punkte ansatzweise nachvollziehen. Am besten du laesst den Rechner aus, dann hast du nichts unschoenes oder ekelhaftes.

Ich koennte jetzt sowas wie: "Erspare mir deine Ignoranz, ok?" oder anderes erwidern. Aber wo wuerde das hinfuehren ...

Husky Puppy

Wegen der MainLoop-Problematik benutze ich äußerst ungern irgendwelche Bibliotheken, die einen Blackbox-MainLoop haben. Da schreibe ich meinen MainLoop lieber selber. ^^
Für OpenGL benutze ich da GLX, für Tastatur/Maus XCB und für den Sound libao. :3

knivil schrieb:

Auch widersprichst du dir selbst

Nein. Ich habe mich nur möglicherweise für dich missverständlich ausgedrückt. Aber das letzte Zitat scheinst du ja dann doch noch richtig verstanden zu haben.

knivil schrieb:

Aber vor Threads hast du ja auch irgendwie Angst.

Nein. Ich finde es nur nicht schön, wenn ich sie verwenden muss, um Limitierungen in bestimmten Bibliotheken zu umgehen.

Und da Threads ihre eigenen Probleme mitbringen, setze ich sie ein, wo ich die Nachteile für gerechtfertigt halte.

knivil schrieb:

SFML

Wo bietet mir die SFML denn die Möglichkeit, über IO-Events benachrichtigt zu werden?

knivil schrieb:

Am besten du laesst den Rechner aus, dann hast du nichts unschoenes oder ekelhaftes.

Du kannst ja gerne qualifizierte Dinge von dir geben. Ich sehe hier aber ehrlich gesagt keinen Grund, warum du hier persönlich Diffamierungen loslassen musst.

Wenn mir dein Vorschlag nicht gefällt, dann akzeptiere das doch einfach. Ich habe ziemlich genau dargelegt, was ich will. Vielleicht kannst du ja nachvollziehen, dass so Tipps wie "Das was du willst ist aber Blödsinn, machst doch anders" nicht unbedingt gut ankommen.

knivil

du hier persönlich Diffamierungen loslassen musst

Ich liebe die Zitierfunktion:

Erspare mir einfach deine Arroganz, ok?

Genau dazu fuehrt sowas ... Das was du willst wurde wahrscheinlich schon 1000x geloest, nur nicht ganz so, wie du es in deinem Hirn hast. Da du nur dein Bild im Kopf akzeptierst und Alternativen argumentlos abgeschmettert werden, halte ich dich fuer beratungsresistent. Aber vielleicht bin ich ja beratungsresistent, da ich immer noch nicht verstehe, warum der MainLoop blockierend sein soll. Ist es der MainLoop eines Spiels das in "Echtzeit" laeuft, so macht blockierend keinen Sinn.

PS: Jede Tastatureingabe ist eine IO-Operation. Und wahrscheinlich arbeitet jedes asynchrone Eventsystem irgendwie mit Threads ... ach verdammt, jedes Programm hat ja mindestens einen Thread.Wir haben da z.B. boost::asio, Events -> Qt hat da auch was mit Netzwerkstreams, epoll ... nein, ich kenne mich nur oberflaechlich damit aus. Keine Ahnung, ob diese dein Problem loesen, da ich das immer noch nicht mitbekommen habe ...