4. [gelöst] OpenGL modern programmieren ist noch nicht "in"?

[gelöst] OpenGL modern programmieren ist noch nicht "in"?

  • S

    Hallo,
    ich bin in einen meiner letzten Threads darauf hingewiesen worden, das glBegin()/glEnd() ja sowas von "out" ist und ich mich doch mit dem Thema modernes OpenGL (4.x, etc) beschäftigen soll. Das hab ich auch gemacht und ich finde es klasse, was da alles so geht (auch wenn ich es noch nicht kann, aber ich will es ja lernen).

    Jetzt ist bei mir der Weg das Ziel und ich hab mal versucht meine ersten GLSL-Versuche zu basteln. Bin natürlich gnadenlos an Anfängerfehlern gescheitert und hab mich mit Hilfe von Tuts und "Try-and-Error" durchgeboxt.

    "Am Besten lernt man von den großen" war mein nächster Plan. Also hab ich mir fertige 3D-Engines heruntergeladen. Beispiele sind "Irrlicht" und "Crystal Space". Aber was sehen meine müden Augen? Die nutzen alle noch glBegin() und glEnd()???

    Was verstehe ich gerade nicht. Den Erklärungen nach reicht das doch gerade mal für "ein paar einfache Dreiecke" aber doch nicht für die großen Spiele und die perfekten Engines?!?!

    Nunja, die Referenzliste der beiden Engines liest sich aber sehr gut. Namhafte Spiele sind auch dabei und Irrlicht hat den Ruf ja supi schnell zu sein auch mit tausenden von Dreiecken.

    Also ist Vertex-Programmierung noch nicht "in"? Ist es zu schwer eine Engine anhand von Vertex zu programmieren? Wo ist das Problem und warum haben die Engines noch glBegin()?

    Ich sehe diesen Thread mal als Einstieg für Diskussionen und Meinungen.

    Kurz noch, was ich machen will: Eine Engine zu schreiben die Anhand von OpenGL meine Minispiele (Niveau Bomberman) und Anwendungen (Niveau Noteneditor) darstellen kann. Ist OpenGL 4 dafür zu groß? Sollte ich mal besser werden und mich an größere Spielekonzepte ran wagen (natürlich nicht alleine, der Zeitaufwand würde es verhindern) ist dann OpenGL 2 oder OpenGL 3 zu klein und ich kann das nicht mehr mit glBegin()/glEnd() realisieren?

    Ich habe viele viele Tuts und Threads zum Thema "OpenGL Vertex modern", etc gelesen. Was ein bisschen fehlt ist das "Best Practice" und Meinungen zum Thema "ist glBegin zu alt"?

    Natürlich sehe ich, dass GLSL sehr viele Vorteile hat, aber kann man damit auch "über das Ziel hinaus schießen"?

    Dann mal her mit eueren Meinungen?

    Danke,
    Stefan

    0

  • Ich kann mir kaum vorstellen dass Irrlich tatsächlich für irgendwas größeres glBegin()/glEnd() verwendet. Aber ganz unabhängig davon, von allen Engines die du dir hättest aussuchen können hast du dir mit den beiden doch tatsächlich zwei lebende Fossile rausgepickt. Mich wundert dass man Crystal Space (erster Release 1997) heute überhaupt noch findet ohne explizit danach zu googlen, Irrlicht (erster Release 2003) wird ja zumindest noch von ein paar Leuten verwendet. Ich kenn die beiden Engines nicht persönlich aber einen besonders Guten Ruf hat keine davon (gut, vor 10 Jahren war der mal besser, aber damals waren sich auch noch aktuell. Wenn du solche Meinungen liest solltest du unbedingt immer das Datum checken ;)). Wenn du dir eine OpenSource Engine anschauen willst könntest du dir Ogre vornehmen. Die ist afaik zwar langsam auch schon in die Jahre gekommen aber zumindest etwas zeitgemäßer...

    stefanjann schrieb:

    Kurz noch, was ich machen will: Eine Engine zu schreiben die Anhand von OpenGL meine Minispiele (Niveau Bomberman) und Anwendungen (Niveau Noteneditor) darstellen kann. Ist OpenGL 4 dafür zu groß? Sollte ich mal besser werden und mich an größere Spielekonzepte ran wagen (natürlich nicht alleine, der Zeitaufwand würde es verhindern) ist dann OpenGL 2 oder OpenGL 3 zu klein und ich kann das nicht mehr mit glBegin()/glEnd() realisieren?

    Es ist gut zu sehen dass du dir realistische Ziele setzt. Allerdings würd ich mich nicht damit aufhalten eine Engine zu schreiben wenn du Spiele entickeln willst. Die Vorstellung dass man eine Engine braucht um ein Spiel zu schreiben ist ein weit verbreiteter Mythos. Aber ich spars mir mal jetzt einen langen Aufsatz drüber zu schreiben und verweise einfach auf das hier.

    stefanjann schrieb:

    Natürlich sehe ich, dass GLSL sehr viele Vorteile hat, aber kann man damit auch "über das Ziel hinaus schießen"?

    Inwiefern meinst du "übers Ziel hinaus schießen"!? Ob du nun OpenGl 2, 3 oder 4 verwendest macht nichtmehr ganz so viel aus. Wichtig ist einfach nur auf den ganzen alten Kram zu verzichten. Wenn du mit Shadern, VBOs, generischen Vertexattributen und FBOs arbeitest bist du schon am richtigen Weg...

    0
  • R

    Also ich finde den alten immediate Mode vor allem für Gui-Elemente noch ganz Praktisch. Und für 2D-Spiele ist er auch mit Sicherheit ausreichend. Für Bomberman braucht man aber sicher keine riesen Engine oder GLSL Shader. Da reicht IMHO eine kleine Sammlung an Funktionen zum Laden und Zeichnen von Texturen und vielleicht noch ein einfacher Partikel-Manager. Fertig ist deine "Engine". Viel mehr Arbeit ist das Spiel an sich.

    0
  • S

    dot schrieb:

    Aber ganz unabhängig davon, von allen Engines die du dir hättest aussuchen können hast du dir mit den beiden doch tatsächlich zwei lebende Fossile rausgepickt.

    "Lebende Fossile" ist ein gutes Stichwort. Die letzte Version von Irrlicht ist vom 15.11.2010, also ging ich dann doch davon aus, dass die "etwas aktuell" sein müssten. Und auch ohne zu googlen kann man "Crystal Space" finden.
    http://de.wikipedia.org/wiki/Grafik-Engine
    Ogre steht auch drinnen, da ich ja eher auf gut Glück gesucht habe, liest sich hier "Crystal Space" schon sehr gut. Und eine Aktualität geht in der Liste von Wiki leider ab.
    Manchmal hab ich aber auch ein Glück *g*.

    dot schrieb:

    Wenn du dir eine OpenSource Engine anschauen willst könntest du dir Ogre vornehmen. Die ist afaik zwar langsam auch schon in die Jahre gekommen aber zumindest etwas zeitgemäßer...

    Aber auch hier schreibst du schon wieder von "langsam" und "in die Jahre gekommen". Ist es denn so, dass alle guten Engines einfach Geld kosten und die Gemeinde der guten kostenlosen Engines den Umstieg auf modernes OpenGL scheut (zwecke arbeit, entwerfen von Shadern, etc)?

    dot schrieb:

    Allerdings würd ich mich nicht damit aufhalten eine Engine zu schreiben wenn du Spiele entickeln willst. Die Vorstellung dass man eine Engine braucht um ein Spiel zu schreiben ist ein weit verbreiteter Mythos. Aber ich spars mir mal jetzt einen langen Aufsatz drüber zu schreiben und verweise einfach auf das hier.

    Ja das stimmt, das ist der Aspekt den man (und ich auch) oft vergisst. Im Endeffekt hab ich es mit meiner Arbeits-SDK genauso gemacht. Immer wieder aus der Praxis raus neue Funktionen und Klassen geschrieben und irgendwann war meine SDK da und sie wird mit jedem Projekt besser. Ich stelle jetzt meine Denke etwas um. Ab jetzt wird meine "Engine" immer nur Anhand meiner Praxisarbeit erweitert. Dann hab ich irgendwann automatisch eine Engine, die MEINE Bedürfnisse erfüllt. Und genau darum geht es ja. Danke für den augenöffnenden Link.

    dot schrieb:

    Inwiefern meinst du "übers Ziel hinaus schießen"!? Ob du nun OpenGl 2, 3 oder 4 verwendest macht nichtmehr ganz so viel aus. Wichtig ist einfach nur auf den ganzen alten Kram zu verzichten. Wenn du mit Shadern, VBOs, generischen Vertexattributen und FBOs arbeitest bist du schon am richtigen Weg...

    Naja, das berühmte "mit Kanonen auf Spatzen schießen". Dass man bei einem einfachen Dreieck lieber doch noch auf glBegin() zurück greift, bevor man Shader schreibt, weil man ja "nur" ein Dreick zeichnen will. Aber wenn ich dich recht verstanden habe kann man das eigentlich nicht, solange man sich bei seinen Shadern (etc) seine Gedanken macht, weil es gibt kein "zu neu" sondern nur einen "alten Kram".

    RedPuma schrieb:

    Also ich finde den alten immediate Mode vor allem für Gui-Elemente noch ganz Praktisch. Und für 2D-Spiele ist er auch mit Sicherheit ausreichend. Für Bomberman braucht man aber sicher keine riesen Engine oder GLSL Shader. Da reicht IMHO eine kleine Sammlung an Funktionen zum Laden und Zeichnen von Texturen und vielleicht noch ein einfacher Partikel-Manager. Fertig ist deine "Engine".

    Klingt recht einfach, aber ich bin ja noch neu bei OpenGL und schon ein Partikel-Manager stellt mich derzeit noch vor eine große Herausforderung. Aber ich lerne ja noch. Mir fehlt halt immer noch die Praktische Erfahrung, die ich mir eben aus den freien Engines etwas abschauen wollte. Denn alle Tutorials und Anleitungen im Internet hin und her, wie man praktisch arbeitet steht meistens nicht dabei.

    RedPuma schrieb:

    Viel mehr Arbeit ist das Spiel an sich.

    Aber das habe ich in Flash schon einmal geschrieben. (in 2D aus Blick von oben, damit ich nur Vektorbilder variieren musste...)

    0
  • C

    He, meine Engine benutzt sogar nur OpenGL 1.1 ohne eine einzige Extension 🕶

    0
  • S

    Cpp_Junky schrieb:

    He, meine Engine benutzt sogar nur OpenGL 1.1 ohne eine einzige Extension 🕶

    Das ist ja genau das, was ich hier in Frage stelle. Um zukunftsfähig zu sein, reich da OpenGL 1.x noch aus oder ist das "alter Kram".

    Wenn ich es richtig verstanden habe, dann ist das "alter Kram" und sollte für moderne Programmierungen nicht emhr verwendet werden. Man sollte sich auf OpenGL 3 und höher konzentrieren.

    0
  • R

    Du solltest dir außerdem im klaren darüber sein dass OpenGL 3.x im nur von DirectX 10 Hardware voll unterstützt wird. Und ich sehe eigentlich keinen Grund warum ich mit der Radeon 9800 Pro aus meinem alten PC keine 2D Spiele spielen sollte 😉

    0
  • C

    stefanjann schrieb:

    Cpp_Junky schrieb:

    He, meine Engine benutzt sogar nur OpenGL 1.1 ohne eine einzige Extension 🕶

    Das ist ja genau das, was ich hier in Frage stelle. Um zukunftsfähig zu sein, reich da OpenGL 1.x noch aus oder ist das "alter Kram"...

    Sollte eher ein Scherz sein, weil ich es bewusst auf eine altmodische Grafik anlege.
    Um zukunftsfähig zu sein, oder mit dem Ziel das professionell zu machen solltest du dich unbedingt mit dem "neumodischen Kram" befassen - Aber besser erst wenn du das "alte Zeug" verstanden hast 😉

    0
  • S

    Cpp_Junky schrieb:

    Um zukunftsfähig zu sein, oder mit dem Ziel das professionell zu machen solltest du dich unbedingt mit dem "neumodischen Kram" befassen - Aber besser erst wenn du das "alte Zeug" verstanden hast 😉

    Und schon haben wir mein Problem. Ich hab mir ein schlaues Buch gekauft. Stand Juli 2010 und es wird fast nur OpenGL 1.x vermittelt. Und wie dot in einem anderen Thread dann schon bemerkt hatte: Im Juli 2010 war OpenGL schon jahrelang "out".

    Also hab ich jetzt den "alten Kram" verstanden und kann damit auch schon ein paar Lustige Dinge anstellen, aber ich will ja modernes OpenGL programmieren und plötzlich stelle ich fest, dass ich das überhaupt nicht kann, denn alles was ich kann ist mit glBegin()/glEnd() Formen zeichnen und durchs Bild schicken.

    Das einzige was sehr ausführlich (gut will ich nicht sagen) in dem Buch beschrieben steht ist die ganze Hintergrund-Mathe-Arbeit. Also auch so singe warum man eine Matrix immer von Link multipiziert und was passiert wenn nicht, etc. Aber ich will ja auch mal zur Praxis kommen und selbst eine Landschaft für mein Spiel zeichnen lassen. Und da hört dann das Buch schon wieder auf; dafür reicht es dann leider nicht wirklich.

    Also ran an das OpenGL 4.x und damit arbeiten.

    RedPuma schrieb:

    Du solltest dir außerdem im klaren darüber sein dass OpenGL 3.x im nur von DirectX 10 Hardware voll unterstützt wird. Und ich sehe eigentlich keinen Grund warum ich mit der Radeon 9800 Pro aus meinem alten PC keine 2D Spiele spielen sollte

    Jetzt kommen wir schon zur Zielgruppenfrage. Ich glaube wenn ich meinen Noteneditor schreibe, dann sollte ich darauf achten, dass ich auch die Möglichkeit zu OpenGL 1.x biete um alte Karten lauffähig zu lassen. Wenn ich aber gezielt ein Spiel (auch mal über dem Niveau Bomberman) schreibe, darf es ruhig "nur" neu sein, denn mal ganz provokativ: "Zocker sind hohe Grafikkartenansprüche gewohnt". Was einem aber nicht von der Pflicht entbindet an "nicht-das-neueste-vom-neuen" zu denken.
    Also eher eine Fallentscheidung, oder? Euere Meinungen dazu erwünscht.

    0
  • T

    Und unter anderem deshalb benutzte ich nur noch DirectX11. Da KANN ich garnicht uralte, ineffiziente Methoden benutzten, weil die API radikal redesigned wurde.

    Jetzt ist es eine Lowlevel 3D API, wie sie im Jahr 2011 aussehen sollte. 😋 👍

    0
  • I

    stefanjann schrieb:

    Und schon haben wir mein Problem. Ich hab mir ein schlaues Buch gekauft. Stand Juli 2010 und es wird fast nur OpenGL 1.x vermittelt.

    Dann isses ein schlechtes Buch 🙂

    stefanjann schrieb:

    Und wie dot in einem anderen Thread dann schon bemerkt hatte: Im Juli 2010 war OpenGL schon jahrelang "out".

    OpenGL soll jahrelang out sein? Halt ich für Unsinn. Vermutlich hat dot das aber auch nicht so pauschal behauptet.

    this->that schrieb:

    Und unter anderem deshalb benutzte ich nur noch DirectX11. Da KANN ich garnicht uralte, ineffiziente Methoden benutzten, weil die API radikal redesigned wurde.

    Kannste bei OpenGL im core-profile auch nicht.

    Die neue SuperBibe (5th edition) lehrt modernes OpenGL. Damit machst du schonmal nichts falsch.
    Wenn du dich näher mit GLSL beschäftigen möchtest, gibt es dafür natürlich auch Literatur.
    OGL 1.x zu lernen ist nonsense - das wird dich nur verwirren, wenn du dann wirklich auf OGL 3.x aufwärts umsteigen möchtest.

    0
  • N

    dot schrieb:

    Wenn du dir eine OpenSource Engine anschauen willst könntest du dir Ogre vornehmen. Die ist afaik zwar langsam auch schon in die Jahre gekommen aber zumindest etwas zeitgemäßer...

    Ogre hat bei mir einen sehr schlechten ersten Eindruck hinterlassen. Das ganze Framework ist ein einziges Biest, ich fand es schwer den Überblick zu behalten. Jede Klasse ist gigantisch gross. Die Kompilierzeiten sind elend lang, bereits Hello World braucht fast eine Minute. Die einzelnen Dinge scheinen zu fest gekoppelt, dieses Konfigurationsmenü am Anfang nervt. Meine Güte, ich will doch nur ein Modell rendern 🙂

    Wie gesagt, erster Eindruck, ich glaube gern, dass Ogre dahinter sehr mächtig ist. Aber für den Anfang würde ich es nicht empfehlen. Da stand Irrlicht im krassen Gegensatz dazu. Eine relativ intuitive und anfängerfreundliche API, gute Tutorials, nicht dieser Code-Bloat. Man kann nachvollziehen, wie etwas zustande kommt. Ich habe auch schon geplant, für ein 3D-Spiel Irrlicht zu verwenden, und sehe keinen Grund, der für mich wirklich dagegen spricht (und schon gar keinen, der für Ogre spricht).

    Für mich, denn ich brauche nicht massenhaft viel Funktionalität, die man kaum findet, sondern will mit vernünftigem Code- und Einarbeitungsaufwand zu Resultaten kommen. So veraltet scheint mir Irrlicht nicht, es wird zumindest noch aktiv entwickelt. Ob viel Legacy-Code oder alte Techniken verwendet werden, kann ich bisher schlecht beurteilen, aber ehrlich gesagt besteht für mich nicht die erste Priorität darin, alle Features von High-End-Grafikkarten auszunutzen.

    0

  • stefanjann schrieb:

    Und wie dot in einem anderen Thread dann schon bemerkt hatte: Im Juli 2010 war OpenGL schon jahrelang "out".

    Ich hab gesagt OpenGL 1.x ist schon seit einem Jahrzehnt hoffnungslos veraltet, nicht dass OpenGL im allgemeinen veraltet ist. Auch wenn die API was das Design angeht imo bei weitem nicht mit Direct3D 11 mithalten kann ist OpenGL sicherlich gleich mächtig.

    stefanjann schrieb:

    Jetzt kommen wir schon zur Zielgruppenfrage. Ich glaube wenn ich meinen Noteneditor schreibe, dann sollte ich darauf achten, dass ich auch die Möglichkeit zu OpenGL 1.x biete um alte Karten lauffähig zu lassen. Wenn ich aber gezielt ein Spiel (auch mal über dem Niveau Bomberman) schreibe, darf es ruhig "nur" neu sein, denn mal ganz provokativ: "Zocker sind hohe Grafikkartenansprüche gewohnt". Was einem aber nicht von der Pflicht entbindet an "nicht-das-neueste-vom-neuen" zu denken.
    Also eher eine Fallentscheidung, oder? Euere Meinungen dazu erwünscht.

    Was genau soll dieser Noteneditor können und warum meinst du dass du dafür OpenGL verwenden willst? Was die Hardwareunterstützung angeht: Jeder Laptop unterstützt heute OpenGL 2.0. Wie gut steht auf einem anderen Blatt aber wenn du mich fragst gibt es keinen Grund heute noch OpenGl 1.x zu verwenden da jede Chipsatzgrafik die jünger als 5 Jahre ist schon allermindestens Direct3D9/OpenGL 2.0 unterstützt...

    Nexus schrieb:

    Ogre hat bei mir einen sehr schlechten ersten Eindruck hinterlassen. Das ganze Framework ist ein einziges Biest, ich fand es schwer den Überblick zu behalten. Jede Klasse ist gigantisch gross. Die Kompilierzeiten sind elend lang, bereits Hello World braucht fast eine Minute. Die einzelnen Dinge scheinen zu fest gekoppelt, dieses Konfigurationsmenü am Anfang nervt. Meine Güte, ich will doch nur ein Modell rendern 🙂

    Wie gesagt, ich hab weder Ogre noch Irrlicht noch sonst eine dieser Engines je selbst verwendet. Ich weiß nur was man so hört und das ist dass man was das Design von Irrlicht angeht von "Zeitgemäß" nicht reden kann und dass Ogre besser sein soll was das angeht. Ich würd mir vermutlich keine der beiden Engines zum Vorbild nehmen.

    0
  • S

    dot schrieb:

    stefanjann schrieb:

    Und wie dot in einem anderen Thread dann schon bemerkt hatte: Im Juli 2010 war OpenGL schon jahrelang "out".

    Ich hab gesagt OpenGL 1.x ist schon seit einem Jahrzehnt hoffnungslos veraltet, nicht dass OpenGL im allgemeinen veraltet ist. Auch wenn die API was das Design angeht imo bei weitem nicht mit Direct3D 11 mithalten kann ist OpenGL sicherlich gleich mächtig.

    Entschuldigung, ICH hab mich da verschrieben. Ich wollte natürlich "OpenGL 1.x" schreiben (also das "1.x" vergessen zu schreiben). Dein genauer Wortlaut zu meinem "tollen Buch" war:

    dot schrieb:

    Naja wenn das Buch glBegin()/glEnd() für die ersten kurzen Beispiele verwendet oder einfach der Vollständigkeit halber erwähnt ist das OK, immerhin bekommt man damit schnell was auf den Bildschirm. Wenn das allerdings alles ist kannst du das Buch in die Tonne treten. Das ist nämlich nicht erst neulich veraltet sondern schon seit 10 Jahren oder so

    Aus dem Thread http://www.c-plusplus.net/forum/284326-10

    dot schrieb:

    Was genau soll dieser Noteneditor können und warum meinst du dass du dafür OpenGL verwenden willst?

    Naja, ich bin Musiker und mein Noteneditor soll auf der einen Seite die Noten und Gitarren-Akkorder entgegen nehmen und dann am Bildschirm (mit OpenGL) die Grifftabelle für den Gitarristen direkt auf einer 3D-Gitarre zeichnen (so mit halbtransparente Finger). Ist für meine Gitarrenschüler sehr hilfreich zum üben. Unter Flash hab ich sowas schon gemacht, aber mit OpenGL wäre es noch leichter anzusehen, weil man die Gitarre dann drehen könnte und unter C++ kann ich besser programmieren als unter Flash.

    Nexus schrieb:

    Ogre hat bei mir einen sehr schlechten ersten Eindruck hinterlassen. Das ganze Framework ist ein einziges Biest, ich fand es schwer den Überblick zu behalten. Jede Klasse ist gigantisch gross. Die Kompilierzeiten sind elend lang, bereits Hello World braucht fast eine Minute. Die einzelnen Dinge scheinen zu fest gekoppelt, dieses Konfigurationsmenü am Anfang nervt. Meine Güte, ich will doch nur ein Modell rendern 🙂

    Wie gesagt, erster Eindruck, ich glaube gern, dass Ogre dahinter sehr mächtig ist. Aber für den Anfang würde ich es nicht empfehlen. Da stand Irrlicht im krassen Gegensatz dazu. Eine relativ intuitive und anfängerfreundliche API, gute Tutorials, nicht dieser Code-Bloat. Man kann nachvollziehen, wie etwas zustande kommt. Ich habe auch schon geplant, für ein 3D-Spiel Irrlicht zu verwenden, und sehe keinen Grund, der für mich wirklich dagegen spricht (und schon gar keinen, der für Ogre spricht).

    Also ich hab mir Ogre herunter geladen und hatte schon Probleme die Exe-Datei auszupacken, denn die gab immer die Fehlermeldung aus "Die beinhalteten Daten sind kein Archiv". Und dann bei einer selbstenpackenden Zip-Exe. Ich hab dann eine die Version davor auf einer anderen Quelle gefunden und die ins Visual Studio geladen. Am Ende hatte ich ca. 5000 Warnings in Form von "Type xx zu Type yy: Datenverlust möglich", etc... So richtig als Vorbild würde ich das jetzt auch nicht sehen. Und innen drinnen sehe ich viele Dinge, die mir auch eher als "Altbacken" erscheinen und nicht gerade "wohldurchdacht". Aber das ist jetzt nur mein erster Eindruck.

    inter2k3 schrieb:

    OGL 1.x zu lernen ist nonsense - das wird dich nur verwirren, wenn du dann wirklich auf OGL 3.x aufwärts umsteigen möchtest.

    Wares Wort. Das ist eine ganz andere Welt. Ich tu mich richtig schwer die Denke von glBegin() in ein Vertex-Array umzustellen. Ich empfehle jeden gleich direkt mit "modernen" OpenGL einzusteigen.

    inter2k3 schrieb:

    Dann isses ein schlechtes Buch

    Japp, das isses. Ich hab mir jetzt das folgende Buch bestellt:
    Shader mit GLSL: Eine Einführung in die OpenGL Shading Language
    Und danach werde ich mir wohl die SuperBibel (5th edition) holen.
    Ich hoffe, danach kenn ich mich dann mit modernen OpenGL aus, dass ich auch mal optisch "schöne" Spiele schreiben kann.

    0

  • stefanjann schrieb:

    dot schrieb:

    Was genau soll dieser Noteneditor können und warum meinst du dass du dafür OpenGL verwenden willst?

    Naja, ich bin Musiker und mein Noteneditor soll auf der einen Seite die Noten und Gitarren-Akkorder entgegen nehmen und dann am Bildschirm (mit OpenGL) die Grifftabelle für den Gitarristen direkt auf einer 3D-Gitarre zeichnen (so mit halbtransparente Finger). Ist für meine Gitarrenschüler sehr hilfreich zum üben. Unter Flash hab ich sowas schon gemacht, aber mit OpenGL wäre es noch leichter anzusehen, weil man die Gitarre dann drehen könnte und unter C++ kann ich besser programmieren als unter Flash.

    Wenns dir nur drum geht diesen Noteneditor zu programmieren und nicht drum unbedingt die Technik dahinter in vollem Umfang bis ins letzte Detail zu erkunden dann würd ich dir auf jeden Fall dazu raten eine fertige Engine zu verwenden, damit kommst du viel schneller ans Ziel.

    0
  • S

    dot schrieb:

    Wenns dir nur drum geht diesen Noteneditor zu programmieren und nicht drum unbedingt die Technik dahinter in vollem Umfang bis ins letzte Detail zu erkunden dann würd ich dir auf jeden Fall dazu raten eine fertige Engine zu verwenden, damit kommst du viel schneller ans Ziel.

    Es geht mir ja nicht um Zeit, sondern dass ich Anfang ein echtes Programm zu schreiben um OpenGL zu lernen. Also lieber selbst geschrieben. Das ist jetzt mein erstes Programm. Und wie war der Tipp: "Schreib keine Engine, schreib Spiele!" (oder Anwendungen). *g*

    0
  • C

    Ich komm hier irgendwie nicht so recht dahinter, wo das Problem liegt. Wenn man schon ein bestimmtes Ziel hat (Noteneditor in 3D), schaut man halt was man dazu braucht und lernt es, oder man nimmt eben gleich ne fertige Engine. Und für diesen Zweck, mal ehrlich, ist es ziemlich egal ob du Irrlicht nimmst oder den nächsten strenggeheimen Prototypen von John Carmack. Ich würd dir sogar zu Irrlicht raten, weil diese Engine sehr einfach zu verstehen ist und du somit auch dein Ziel wesentlich schneller erreichen solltest.

    0

  • Ich versteh auch nicht so ganz wo jetzt dein Problem liegt. Wenn es dir darum geht ein gewisses Projekt umzusetzen dann such dir eine fertige Engine/Bibliothek mit der du deine Idee eben möglichst einfach umsetzen kannst.

    Wenn es dir darum geht OpenGL zu lernen dann lern OpenGL. Und OpenGL bedeutet heutzutage nunmal VBOs, Shader, FBOs, etc. Das heißt nicht dass du nicht am Anfang auch mal mit glBegin/glEnd experimentieren darfst. Du sollst dabei nur auf keinen Fall vergessen dass das eben bei weitem nicht der Weisheit letzter Schluss ist...

    0
  • S

    dot schrieb:

    Ich versteh auch nicht so ganz wo jetzt dein Problem liegt. Wenn es dir darum geht ein gewisses Projekt umzusetzen dann such dir eine fertige Engine/Bibliothek mit der du deine Idee eben möglichst einfach umsetzen kannst.

    Cpp_Junky schrieb:

    Ich komm hier irgendwie nicht so recht dahinter, wo das Problem liegt.

    Am Anfang des Thread hatte ich noch ein paar Probleme und Fragen. Die habt ihr aber in der Zwischenzeit schon ausgeräumt/beantwortet. Meine Frage war ja am Anfang (grob gesagt): "Warum nutzen die Engines die man im Web findet eigentlich noch glBegin()/glEnd()". Ich glaube die Frage ist sehr gut beantwortet worden. Auch die Frage nach Sinn und Unsinn von "Immer das neueste OpenGL!" und "Wie fange ich an OpenGL zu lernen" habt ihr mir beantwortet. Dabei habe ich auch festgestellt, dass man evtl. auch (je nach Anwendungsbereich) die Zielgruppe und die vorhandene Grafikunterstützung berücksichtigen sollte.

    Also hab ich jetzt eigentlich kein Problem mehr, außer dass ich noch 2-3 Bücher, viele Tutorials, ein paar "best practice" und ganz viel "Try-And-Error"-Versuche vor mir habe.

    Aber das wichtigste was ich nun von euch gelernt habe ist: Schreib keine Engine, schreibe Anwendungen! Die "Enigne" ergibt sich dann aus deiner Arbeit (und deinen Befehlen) von ganz alleine (und zwar aus der praktischen Arbeit).

    Nur eine Frage stellt sich mir nach wie vor: Welche freie Engine ist denn nun wirklich gut um "hartes" OpenGL 4.x zu sehen/lernen (man muss auch man über seine Ziele hinausschauen um besser zu werden...) *g*

    Daher vielen Dank für euere Gedanken.

    0

  • stefanjann schrieb:

    Nur eine Frage stellt sich mir nach wie vor: Welche freie Engine ist denn nun wirklich gut um "hartes" OpenGL 4.x zu sehen/lernen (man muss auch man über seine Ziele hinausschauen um besser zu werden...) *g*

    Wie gesagt: Die Open Source Engines die mir so bekannt sind würd ich mir alle nicht zum Vorbild nehmen. OpenGL 4.0 wird wohl noch in keiner der bekannten Open Source Engines wirklich verwendet...

    0
Anmelden zum Antworten