C/C++: Mit OpenGL Programme/Oberflächen/Spiele programmieren - Tutorials, etc?

[LastChosenOne]

Hallo

und zwar suche ich derzeit nach guten und aktuellen (!) tutorials, um direkt mit OpenGL in C/C++ GUIs zu programmieren.
Im Internet finde ich derzeit nur ältere Tutorials (>2 Jahre alt) oder eben mit SDL, QT, Mesa 3D, GLUT/OpenGLUT oder ähnlichen Bibliotheken.
Ich möchte aber alles soweit selber programmieren und keine vordefinierten Bibliotheken verwenden. (Also C/C++ Projekt + OpenGL-Library, mehr nicht)
oder ist es sinnvoll, diese Bibliotheken (ich würde hier glaube ich GLUT wenn dann verwenden) zu benutzen..?

Ich habe vor mir einerseits kleinere Spiele zu programmieren, aber auch "normale" GUI-Programmierung mit OpenGL durchzuführen (ich möchte hier OpenGL verwenden, bitte also keine Vorschläge von wegen "nimm lieber QT/GTK+" oder so, danke) - alles zu lernzwecken und verinnerlichung ^-^

Ich hoffe ihr könnt mir weiterhelfen.

 

[asdfman]

Die Antwort ist plattformabhängig. Auch ist dein Vorhaben nicht durchführbar. Du wirst mindestens die xlib oder win32-API benutzen müssen. Viel Spaß beim wahnsinnig werden mit beidem.

 

[LastChosenOne]

Die Antwort ist plattformabhängig. Auch ist dein Vorhaben nicht durchführbar. Du wirst mindestens die xlib oder win32-API benutzen müssen. Viel Spaß beim wahnsinnig werden mit beidem.

OpenGL ist soweit ja Plattform-Unabhängig, genauso wie C und C++, also warum wäre es dann plattformabhängig?

 

[GuaRdiaN]

OpenGL und C++ haben beide anfänglich nichts mit der Plattform zu tun. Sobald du aber optimierte Binaries erzeugen möchtest kommst du selten darum herum mit den Compositoren (XWindow API unter Linux und das WIndows Pendant) zu "sprechen".

Habe aus reinem Interesse mal mit OpenGL begonnen und versucht damit einfache grafische Darstellungen zu ermöglichen (Shader-Programmierung habe ich ebenfalls versucht). Das geht sehr schnell ins Eingemachte was die Konzepte hinter den verwendeten Sprachen angeht, weil der Code performant sein muss, damit da etwas bei heraus kommt.

Daher war das "Viel Spaß beim wahnsinnig werden" nicht ganz unbegründet.

 

[QDOS]

OpenGL ist soweit ja Plattform-Unabhängig, genauso wie C und C++, also warum wäre es dann plattformabhängig?

OpenGL ist plattformunabhängig, aber das erzeugen des OpenGL Kontexts ist plattformspezifisch (WGL, XGL, ...)!

Und unter Windows brauchst du für alles über OpenGL 1.1 sowieso eine externe Lib, wenn du nicht x imports manuell machen willst…

 

[LastChosenOne]

@GuaRdiaN: ok, danke soweit - aber ich will es mal versuchen
für Linux und Windows (Linux-Laptop und Windows-Gaming-PC)

OpenGL ist plattformunabhängig, aber das erzeugen des OpenGL Kontexts ist plattformspezifisch (WGL, XGL, ...)!

inwiefern OpenGL Kontext,..? Was genau meinst du damit?

 

[QDOS]

inwiefern OpenGL Kontext,..? Was genau meinst du damit?

An den OpenGL Kontext werden die ganzen Zeichenbefehle gesendet. Ohne Kontext, kein OpenGL. Ohne Plattform-APIs kein Kontext…

 

[LastChosenOne]

und wie könnte ich es dann machen, auch plattformunabhängig,..? wird doch auch irgendwie funktionieren, oder nicht?

 

[QDOS]

und wie könnte ich es dann machen, auch plattformunabhängig,..? wird doch auch irgendwie funktionieren, oder nicht?

Indem du für jedes OS spezifischen Code schreibst…

 

[LastChosenOne]

angenommen, ich würde es jetzt nur unter/für Linux schreiben, bräuchte ich dann noch irgendwas auser eben die OpenGL-Bibliothek? Oder sollte ich dort dann auch irgendwelche externe Bibliotheken verwenden?

 

[QDOS]

Unter Linux wirst du mit GLX interagieren müssen um unter X11 einen Kontext zu erzeugen, ob du sonst auch noch was brauchst kann ich dir nicht sagen. Wir verwenden für den Kontext immer GLFW, da es (IMHO) keinen Sinn macht sowas immer wieder selbst zu programmieren…

 

[aphex.matze]

OpenGL ist leider ein schwieriges Thema. Es gibt viele unterschiedliche Versionen und deren Eigenheiten führen dazu, dass die allermeisten Tutorials schwer zu gebrauchen sind. Achte darauf, konsequent nur eine OpenGL Version (Major) zu verwenden. Welche das ist, entscheidest du. 4 ist aktuell aber es wird wenige Tutorials geben. Alte sind auf die 4 schwer anwendbar.
http://www.g-truc.net/ ist vielleicht hilfreich.

Weiterhin haben manche schon erwähnt, dass OpenGL nur eine API für "3D" ist. Es hat nichts mit Fenster, Mauseingaben oder GUI Elementen zu tun. Die Kontext- und Fenstererzeugung sind plattformabhängig. Weiterhin kann die OpenGL ohne weiteres weder Maus- noch Tastatureingaben oder ähnliches liefern. Diese Dinge bekommst du aber mit der wirklich empfehlenswerten GLFW geliefert. Ohne diese Dinge, gibt's schlussendlich keine GUI.
GUI-Elemente gibt es nach o.g. Erklärung also auch nicht. Buttons etc. musst du dir selbst bauen. An der Stelle sei gesagt, dass das ein größeres Unterfangen ist. Wenn du es aber angehen möchtest...

 

[Yogi666]

Um mit OpengL wirklich was anfangen zu können solltest du die Grundlagen von Vektorrechnung/Matritzenrechnung beherrschen.

 

[resusseleman]

Als Tutorial zu aktuellem OpenGL könntest du dir diese Playlist angucken http://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaOhnm9FxmzHpbY

Dass dort (in den ersten Folgen) Qt benutzt wird hat einen Grund. Ohne dessen Hilfe würde man bei jedem Projekt erstmal ne ganze Menge Code schreiben müssen, der auch noch für jedes OS anders ist, bis man überhaupt mit OpenGL was auf dem Bildschirm zeichnen kann.

Alternativ kannst du auch SDL2 nehmen, was dir wenn nötig neben der OpenGL-Einrichtung auch noch leichteren Zugriff auf diverse Eingabegeräte, Sound und grundlegende Netzwerkunterstützung bietet.

Beide Varianten haben den Vorteil, dass du dich auf auf den eigentlichen Programcode konzentrieren kannst, ohne dich vorher lange mit diversersen platformabhängigen Initialisierungen (Fenster erzeugen, OpenGL per GLX, WGL oder was anderem) aufzuhalten.

Angucken kann man sich die entsprechenden Wege, der Vollständigkeit halber, ja trotzdem einmal. Nur wird man später selber an einen Punkt ankommen, wo man den Code dafür auslagert, um den nicht bei jedem Programm für jede benötigte Platform immer wieder schreiben zu müssen.

 

[daemon777]

Ich versuche die Problematik nochmal in meinen Worten zu erklären. Die Programmiersprache mitsamt der STL ist zwar standartisiert und macht auf jeder Platform sehr wahrscheinlich das, was sie tun soll, solange du eben keine platform-spezifischen Bibliotheken benutzt. OpenGL ist ebenfalls platformunabhängig und somit dürften wir ja gar kein Problem bekommen oder?
Tja ein kleiner Schritt fehlt hier leider noch. Damit wir überhaupt etwas auf den Bildschirm zeichnen können benötigen wir vom Betriebssystem den Zugriff zu einem Teil bzw. zum ganzen Bildschirm. Diesen Bereich müssen wir also mit dm Betriebssystem kommunizieren und ihm sagen, dass wir hier gerne ein paar Pixel manipulieren möchten, alle Eingaben verwalten wollen usw.
Um also ein Fenster/Kontext usw zu erstellen benötigen wir leider einen winzig kleinen Teil Betriebssystemaufrufe, die leider leider eben nicht standartisiert sind. Unter Windows könnten wir hier die Win32API aber auch sämtliche Andere, wie MFC, benutzen. Auf anderen Platformen eben entsprechende andere APIs.

Lösung 1: Einfach in unserem Code Makros einfügen, die checken unter welcher Platform wir arbeiten, und anschließend für jede Platform einen eigenen Fenstercode schreiben. Das ist natürlich etwas aufwändig aber theoretisch auch noch machbar, wenn man diesen Teil sehr minimalistisch auslegt. Das Problem bläht sich aber natürlich auf, wenn man immer mehr Platformen oder einfach nur andere APIs unterstützen möchte.

Lösung 2: Du benutzt eben nur für diesen Teil eine weitverbreitete Bibliothek, die das einfach für dich erledigt. Ich persönlich habe hier zwar noch nicht wirklich ernsthafte Versuche mit Qt + OpenGL unternommen aber die Idee finde ich gar nicht so schlecht. Die IDE von Qt ist mir jedoch etwas zu langsam, weshalb ich mir irgendwie überlegen würde, wie ich in einer anderen IDE entwickeln kann und nur den Grund OpenGL-Aufruf und das Fenster-Setup im Qt-Creator durchführen kann (zB Qt-Creator erstellt Fenster und ruft dann dlls auf, die im VC++ erstellt werden. Sicher nicht die eleganteste Lösung aber das zeigt wie sehr mich da die Wartezeiten nerven ). Eventuell geht es auch irgendwie genau andersrum (Fensteraufruf in ne dll?).

 

[LastChosenOne]

Ok, danke euch allen soweit

Welche Bibliothek würdet ihr dann verwenden, wenn ihr ganze Oberflächen( und GUIs mit OpenGL programmieren (wollen) würdet?

Würdet ihr versuchen, alles mit OpenGL oder z.B. das Fenster mit QT und den Rest mit OpenGL zu machen?

Ich möchte gerne auch versuchen, eine komplette Oberfläche so zu programmieren (also wie in Linux z.B. Gnome, LXDE, etc ) - wie würdet ihr das machen?

 

[daemon777]

Ingame-GUI musst du wohl komplett in OpenGL machen. Ob es da Bibliotheken für gibt weiß ich allerdings nicht. Vielleicht findet sich ja hier noch jemand zu, der sich da mal näher mit befasst hat.

Bei einer kompletten Oberfläche wäre es vielleicht doch wieder ganz interessant das in Qt zu machen (da 2D und erstmal einfacher).

 

[[GP] mino]

kann dir davon abraten OpenGL direkt aufzurufen, weil du schon bei kleineren vorhaben dir ein kreuz hebst diesen automaten in griff zu bekommen. und eher du dich versiehst, bist du dabei diverse loader und die millionste engine zu proggen. weißt, nimm lieber OpenSceneGraph. über die bekommst du alles für dein vorhaben und kannst dich auf das konzentrieren, worauf es wirklich ankommt. anderenfalls werden deine mannstunden nur für einen screensaver ausreichen.

ps: für QT bringt OSG dir auch das entsprechende widget mit. oberflächenprogrammierung in einer 3d scene nennt sich HUD. weil OSG sowie QT opensource ist, bekommst jedes erdenkliche beispiel für lau mitgeliefert, das du komplett über den gebugger durchsteppen kannst.

last but not least: solltest du wirklich ein zock proggen wollen, erarbeite dir ein voher ein detailliertes spielkonzept, bzw. steck dort deine ganze kraft rein. egal ob's tetris oder skyrim werden soll. jenes konzept selbst wird dir offenbaren, was dir fehlt und was du noch aufholen musst. aus erfahrung kann ich dir sagen, dass man bestenfalls im stande ist rage-comics mit paint zu zeichnen. urplötzlich wird aber hintergrundmelodie, animierte modelle, visuelle effekte etc pp. abverlangt. spiele sind die facherübergreifendsten biester, die mir je unter die augen gekommen sind - und sind prinzipiell nicht durch eine person zeitgemäß umsetzbar. falls du diese tatsache ignorierst, wird es dir ca. so ergehen wie crytek.

bezüglich softwareentwicklung kann ich dir sagen, nutze alles was da ist: du willst shader? nimm zb. die von doom3 oder anderen opensource-teilen. mach nicht den fehler von null zu beginnen und zu meinen, dass dein ansatz der heilige gral ist - das haben schon millionen vor dir versucht. das problem ist nämlich nicht deine kompetenz, sondern die mannstunden, die für die umsetzung notwendig sind. das wäre nämlich so, als würdest du versuchen einen wolkenkratzer mit backsteinen zu bauen - nimm kräne! diese sind nämlich schon alle vorhanden und warten darauf dir zu helfen. bezahlt wirst du in der zukunft dafür technologien zu beherrschen und nicht dafür räder neu zu erfinden.

solltest du all das bewusst irgnorieren wollen, zieh dir die demos von farbrausch ([1], achte auf die kleine dateigröße) rein. wirklich tolle teile, die 1000% mehr abverlangen; du dafür aber nicht mal einen blumentopf bekommst.

 

[kuddlmuddl]

Wieso hängst du dich immer so an OpenGL auf? Wegen der Hardwarebeschleunigung? Wenn man die WinApi nutzt (oder QT, was dann diese verwendet) sind die GUIs auch hardwarebeschleunigt.
Wenn du unbedingt OpenGL beschleunigte GUIs willst aber in absehbarer Zeit Ergebnisse erzielen willst könntest du QML2 verwenden (QT aber nicht QWidget). Das läuft auf allen Plattformen (desktop und mobile) und nutzt OpenGL.

 

[LastChosenOne]

@daemon777: Da würde ich einfach bissel rum-probieren, wäre mir soweit auch egal

@[GP]mino: Danke, auch wenn es "blöd" klingt, aber eben sowas wie bei farbrausch.com möchte ich selber programmieren, weil ich es einfach interessant finde und es als eine herausforderung sehe.
hast du noch mehr davon? )

@kuddlmuddl: Es geht mir nicht direkt um die Hardware-Beschleunigung, sondern auch um die Möglichkeiten die ich dabei habe.