Hallo UbuntuNutzer,

ich habe mich die letzten Tage mit OpenGL und selbstgemachten Spielen beschäftigt, doch ich bekomme die letzten Fragen nicht beantwortet :/ Mein aktueller Stand ist, dass man dem eigenen Programm, welches OpenGl verwenden will, mittels z.B. GLUT oder GLEW oder SDL(MESA?), ein "Fenster" zur Verfügung stellen muss, wo dann die Grafik reingemalt wird. Ich laß mir mehrere Tutorials, Wikiartikel und Foren durch, doch es wurde mir nicht ersichtlich, was GLUT, GLEW, MESA und SDL genau unterscheidet und wann man was verwendet. Ich habe mal ein Bild gemalt, wie ich mir die Beziehung vorstelle, bzw. wo Begriffe wie DRI oder GLX stehn. Kommt das hin? Das größte Fragezeichen steht über GLUT und GLEW GLU!

Ich bin kein grosser Freund dieser "Mindmaps" (deine sieht schon ganz gut aus soweit), die machen mich eher noch konfuser als eine Stichwortliste wie diese hier:

• Kernel - Drm/Dri - Grafiktreiber - interessiert zum Programmieren von Anwendungen nicht.

• MESA: eine "OpenGL Implementation". Kann ein Software-Renderer sein, der urlangsam ist, und nicht von der Grafikkarte beschleunigt...Die Freien Treiber (radeon,nouveau,intel) nutzen aber auch MESA als Hauptschnittstelle zwischen Karte/Treiber und Programm. Sprich "MESA ist ein OpenGL", zwei anderen mögliche sind etwa die ogl Schnittstellen, die die nvidia und amd Treiber mitbringen.

• X-Server: Verwaltet Grundfunktionen der Grafischen Oberfläche, bestimmte Eingabemethoden usw. Deine Desktopoberfläche läuft auf einem X-Server.

• GLX: Schnittstelle, um OpenGL auf dem X-Server zu bekommen (vollbild/fenster). Interessant, wenn man kein SDL nutzen will. "EGL" ist übrigends eine Variante davon, die ohne X-Server auskommt, bringen die freien Treiber glaube ich schon mit!

• SDL: Bibliothek, die das Nutzen von Grafik/Sound/Eingabemethoden vereinfachen soll, vor allem für Spiele. Kann über GLX (macht dann alles SDL, braucht man also nicht zu lernen) auch OpenGL-Kontext erzeugen, und hat ein paar ganz simple Funktionen, den zu konfigurieren. SDL ist "gut", weil läuft auf vielen Platformen mit dem gleichen Code

• GLUT: so 'ne Art SDL in "Sparversion" Traditionell eine der Ersten Schnittstellen, um ein OpenGL Fenster zu bekommen, das unter jedem Betriebssystem (GLX, oder WGL(windosw)) funktioniert. Ignorier's lieber, und nutz' gleich SDL.

• GLEW: eine Bibliothek, die einem "das Leben leichter machen" will, indem sie sämtliche ihr bekannten (und das sind viele!) OpenGL-Erweiterungen bei Programmstart lädt - der Programmierer muss dann keine unnötige Tipparbeit machen (und die ist wegen der ellenlangen Funktions-/Variablennamen der Erweiterungsfunktionen echt ein Kreuz!), und kann die Erweiterungen leicht auf Vorhandensein prüfen und direkt benutzen. OpenGL Erweiterungen ("Extensions") sind fast der Regelfall, will man neuere Funktionalität moderner Grafikkarten nutzen, dementsprechend gibt es wie gesagt recht viele (http://www.opengl.org/registry/, die Liste unten zeigt schon die meisten)...

• GLU: "gehört zu OpenGL" und bringt ein paar kleine Erweiterungsunktionen mit, mit denen bestimmte Aufgabenlösungen vereinfacht werden sollen, etwa einfache Rotationen, Projektionsmatrix komfortabler konfigurieren, 'nen schönen Teepott malen - meiner Ansicht nach eher unnötig, fang' lieber gleich damit an, dir eine eigene Vektor/Matrixbibliothek zu basteln, oder nutz' eine vorhandene Opensource, damit fährt man besser.

Ich hoffe, damit konnte ich ein paar Fragen klären

Als erstes einmal, Wenn du dich schon mit der Hrdware beschäftigst, machst du etwas grundverkehrt.
Desweiteren ist es nicht sehr ratsam Spiele mit "reinem" OpenGL zu programmieren - Wenn du dir einige beispiele anschaust, wirst du schnell merken, dass OpenGL sehr langatmig ist.

Was ich dir empfehlen würde, ist dir eine fertige Engine zu suchen, zb Blender.
Blender bietet bereits eine engine, zudem kannst du mit Blender deine Spielelogik in Python schreiben. Ausserdem wurden auch schon einige Filme mit Blender erstellt. Erfahrung mit blender hab ich allerdings nicht, möglich ist es allerdings durchaus.

Hier muss man allerdings zwischen zwei dingen unterscheiden:
+ 3D Engines - Diese bieten 3D funktionalität, meist allerdings auch noch vieles anderes, wie zb Audio, Scripting, etc. Beispiele hierfür wären Ogre3D oder Irrlicht. + Game Engine - Eine vollkommen fertige Engine, wo lediglich die Logik des Spieles erstellt werden muss (Actors, Objekte, Maps, Stories, etc). Solche engines sind meist **nicht** OpenSource, sind allerdings oft für mehrere Platformen verfügbar. Einige der OpenSource Game Engines basieren meist auf der alten Engine Logik von Quake 3.

Wofür du dich entscheidest sei dir überlassen. Aber tu dir selber einen gefallen, und suche dir eine fertige engines, sonst wirst du die ersten Monate mit nichts anderem verbringen als die Engine halbwegs zum laufen zu bringen.

Naja, stimmt, wenn man noch nicht soviel Programmiererfahrung hat, und von Gebastel schnell frustriert ist: es gibt so einige Alternativen dazu, alles gleich komplett selber machen zu müssen! Und selbst wenn man's doch alles selber machen will, lohnenswert andere Programme/Engines zu studieren ist's immer.

Aber vielleicht geht es dem Threadersteller ja grade darum, eine eigene Engine zu bauen? Mit fertigen Lösungen spart man sehr viel Zeit und Frust auf dem Weg zum Ziel/Spiel; hat man aber ein ungewöhnliches Spielkonzept (aus dem Ramen des Möglichen für die bereits verfügbaren Engines, modernere Technologien als in den Engines verfügbar sollen genutzt werden,...), oder ein sehr einfaches Spiel vor (wo eine "grosse" Engine overkill wäre)...oder Lizenzrechtlich, weil's mal verkauft werden soll...

Aber gut, der Hinweis auf "vorgefertigte Lösungen" kann gut Frust ersparen...

Oh wie schön! Das hat geholfen, danke

Tja, eine eigene 3D-mega-ultra-Crysis-Engine wäre sehr cool, doch da bleib ich einfach mal realistisch und freue mich drauf, wenn sich bald ein Klotz durchs Bild dreht (und nach 1000jahren alle libraries und header, ohne fehler gelinkt sind!) Blender,co. werde ich mir genauer anschauen, sieht auf den ersten Blick gut aus! Bevor ich richtig anfange, muss ich wohl eh noch 1-2 Kumpels überreden, sich auch einzulesen...und auf, zu neuen Tutorials

Ich befasse mich ja gerade auch mit dem Thema sehr intensive . Auch wenn selber machen Frust bringen kann überwiegt doch die Freude beim Erfolg zu mindestens für mich. Da wurde vorhin Quake erwähnt "öhmmm ja Einarbeitung Overkill" also sich in Irrlicht einzuarbeiten finde ich dann für einen Anfänger sehr hart "WARNUNG" da verlieren sich auch erfahrene Programmierer! Ich persönlich finde den weg über SDL,GlU,Opengl sehr gut z.B. nen eigenen Objekt Texturloader schreiben um das Verständnis für die Sachen zu bekommen da lernt man ne Menge. Zu dem Thema gibs auch gute Tutorials online. Man kann ja jetzt sagen ich nimm so was als fertig klar geht das, aber ich finde durch das da hinter schauen entwickelt man sich auch weiter lernt Programmiertechniken kennen (Problemlösungen, Algorithmen) die einem auch so mal weiterhelfen können.Allerdings gibs in diesem bereich auch Tutorials die nicht so toll sind wo man sich dann schon fragt was der Tutor da macht. Wenn er C++ nutzt aber Sachen wie using namspace std; nicht nutzt. Learning by doing!

mfg darkstar999

Noch ein Gedanke zum Thema "Selber machen/Engine einfach nutzen":

Will man eine komplexe 3d Engine wirklich gut/souverän nutzen können, braucht man echt Ahnung von der Materie 3d-Grafik. Wie schon erwähnt, sind diese Engines sehr komplex, und setzen tiefes wissen im Themenbereich vorraus, wenn man etwas wirklich gutes damit anstellen will - und wirklich gute Dokumentationen/Tutorials für Einsteiger, die einem dieses Grundwissen jenseits des erstellens eines einfachen Projektes vermitteln, gibt es nicht wirklich "für lau".

Das beste was man also machen kann, um das Verständnis von 3d-Grafik auf einen Level zu bringen, dass man auch mit den "grossen Teilen" gut klarkommt: an der Basis forschen und probieren. Also erstmal kleine Animationen/Progrämmchen selbst aufbauen, mit OpenGL beschäftigen, Dokumenten, die bestimmte Techniken beschreiben mal naiv folgen, und versuchen so viel wie möglich von der grundsätzlichen Theorie zu verstehen...dann weiss man auch irgendwann was warum und wie in so einer Engine gelöst ist, was es bedeutet und wie man es benutzt. Noch bevor man in der Lage wäre, es so professionell umzusetzen - man weiss wenigstens, was es ist!

Zum Thema Tutorials: es gibt sicher viele verlockende Kurztutorials, die Schritt für Schritt zu irgendwas führen - aber die meisten erklären nicht das wie und warum. Sobald man grundlegendes am laufen hat empfiehlt sich also, Suchmaschinen mit den richtigen englischen Schlagwörtern zu füttern, um pseudo-/halb-/vollwissenschaftliche Texte zu finden, die einzelne Techniken gut erklären. Wikipedia ist auch ein guter Einstiegspunkt, da sind viele IT Themen gut "angeritzt" und grob erklärt, mit weiterführenden Links unten. Nicht vergessen: verschiedene Sprachen haben manchmal verschieden gute/ausführliche Artikel parat...ich suche immer deutsch und englisch, und vergleiche...

Viel Glück und Spass mit den "Tanzende Pixelz™"...jetzt hab' ich auch meine Klappe auch weit genug aufgerissen, so weit bin ich selber noch nicht, was die Praxis angeht...

Tjach diese Dreick-Quader-tutorials haben auch schnell ihren Reiz verloren Die Techniken bleiben aber interessant! Bei Blender muss man sich dagegen ja gar keine Gedanken über Code mehr machen, bis auf die kleinen Phytonskripte. Man kommt schon deutlich besser vorran, als wenn man sich OpenGL-Tutorials reinzieht. Ich, für meinen Teil, werde mich wohl auch erstmal in Blender austoben und wenn die Neugier nach dem "Wie wirds gemacht" bleibt, gehts weiter mit OpenGL. Danke für eure Ratschläge