spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Was im Verlauf des Threads klar geworden sein sollte: Darum gehts ja auch gar nicht.

Das Gebinde wird aber hauptsächlich rein ästhetischen Gründen bemängelt.
Und das ist kein sehr schlagkräftiges Argument.

Achja: Ich vermute das jetzt wieder das mit den Multithreading kommt.
Multithreadrendering findet in einen Otto-Normal-Projekt wohl kaum Anwendung.

Zitat von »Spiele Programmierer«

Das Gebinde wird aber hauptsächlich rein ästhetischen Gründen bemängelt.
Und das ist kein sehr schlagkräftiges Argument.

Richtig, es gibt auch keine schlagkräftigen Argumente gegen die Verwendung von globalen Variablen. Alles ästhetisch! Allerdings wirst du, mit zunehmender Erfahrung feststellen, dass einige Programmieransätze dazu tendieren Fehleranfällig und instabil zu sein. Ich halte das generell für ein äußerst schlagkräftiges Argument, da jeder Programmierer die Motivation haben sollte stabilen, fehlerfreien Code zu erzeugen und daher um jedes Mittel froh ist, das diesem dabei entgegen kommt.

Zitat von »Spiele Programmierer«

Achja: Ich vermute das jetzt wieder das mit den Multithreading kommt.
Multithreadrendering findet in einen Otto-Normal-Projekt wohl kaum Anwendung.

Nein, "das mit Multithreading" kommt jetzt nicht. Allerdings ist Multithreading tatsächlich nicht zu unterschätzen, vielleicht nicht für das kleine 08/15 Pong-Programm das zuweilen entwickelt wird. Viele aktuelle Spiele nutzen aber z.B. Multithreading-Ansätze um Resourcen paralell zu erzeugen, oder Commandlisten parallel aufzubauen (etcpp...).

Zitat

Allerdings wirst du, mit zunehmender Erfahrung feststellen, dass einige Programmieransätze dazu tendieren Fehleranfällig und instabil zu sein.

Ich habe Erfahrung.
Auch wenn du es mir nicht glaubst.

Und in Teilen ist es in Dx ganz änlich.

Ich will jetzt nicht sagen das OpenGL perfekt ist.
Allerdings finde ich das Argument nicht wirklich bis zum Ende nachvollziehbar.

Zitat

... da jeder Programmierer die Motivation haben sollte stabilen, fehlerfreien Code zu erzeugen ...

Ich kann nur eins sagen:
Ein Fall in dem der Bindmechanismus für einen Fehler in meinen Code gesorgt hätte, kann ich mich nicht erinnern.

Zitat von »Spiele Programmierer«

Ein Fall in dem der Bindmechanismus für einen Fehler in meinen Code gesorgt hätte, kann ich mich nicht erinnern.

Also sowas passiert schon recht häufig. Viel häufiger hat man aber tatsächlich natürlich noch mit dem Statemanagement Probleme...

Zitat von »Spiele Programmierer«

Und in Teilen ist es in Dx ganz änlich.

Aber eben in den richtigen Teilen.

Zitat von »Spiele Programmierer«

Allerdings finde ich das Argument nicht wirklich bis zum Ende nachvollziehbar.

Was verstehst du denn nicht?

Zitat von »Spiele Programmierer«

Zitat

fehlender Objektorientierung

OpenGL ist objektorientiert.

Sorry, aber das Inferface ist Imperativ, nicht Objekt-Orientiert. Wie er das intern abhandelt, das ist mir an der Stelle total egal, denn die API ist es nicht, sondern eine grauenvolle Ansammlung von Funktionen. Nicht Methoden und Klassen, sondern Funktionen.

Zitat von »Spiele Programmierer«

Zitat

Das ganze Gebinde ist einfach gruselig.

Beim Rendern machst du in Dx auch nicht sehr viel anderes.

Anders genug als dass man nicht ständig Probleme damit bekommt, wenn irgendwer irgendwo parallel ein Bind auf eine Textur ausführt. Das hat auch nichts mit Ästhetik zu tun, sondern damit, dass es unpraktisch ist, fehleranfällig und Parallelität von vornherein ausschließt. Wenn Parallelität bei Otto-Normal keine Anwendung findet, dann bin weder ich Otto-Normal, noch jede vernünftige moderne API, die auf DX basiert. Sorry, das kann's echt nicht sein im Zeitalter von immer mehr notwendiger Parallelität und auch entsprechend entworfener Hardware. Du kannst Dein Pong sicher ohne machen, aber bei allem, was viel zu zeichnen hat, da hört der Spaß dann auf, weil es gar nicht geht.

Die OpenGL API ist schon objektorientiert, aber durch diesen Bind Kram eben auf eine sehr kaputte Art und Weise

Es ist nichts Objekt-Orientiert an "glTexCoord", wenn ich nicht weiß auf welches Objekt sich dieser Call bezieht. Sorry. Wenn ich die Textur-ID mit übergeben könnte, dann durchaus. Aber selbst dann wird mir wohl jeder zustimmen, dass eine Textur-Klasse mit entsprechenden Member-Methoden wohl irgendwie zeitgemäßer wäre als dieser Haufen von glXYZMassenFunktionen.

Gut, der "Immediate Mode" Kram ist in der Tat nicht unbedingt objektorientiert, da hast du recht. Dafür müsste zumindest der GL Context explizit als Objekt in der API vorhanden sein. Vieles ist aber sehr wohl objektorientiert: Texturen, VBOs, Shader, VAOs, Sampler Objects, FBOs etc.

Ja, wobei mir da für ein "vernünftiges" OOP auch eine entsprechende Kapselung in Klassen fehlt. Wenn man die Spec von OpenGL nicht mal von vorn bis hinten gelesen hat, dann findet man nicht gerade leicht raus, wie ein Shader erzeugt werden muss. Bei einer Kapselung in einer Klasse wäre es sehr offensichtlich: Konstruktor mit Vertex- und Pixel-Shader Objekten als Parametern und fertig. Die Vertex- und Pixel-Shader natürlich ebenfalls wieder gekapselt, so dass nur Konstruktoren oder halt noch Aufrufe der Compile-Methoden notwendig wären. DAS wäre auch eine API, die sich sinnvoll und stilvoll einsetzen ließe.
Stattdessen baut jeder OpenGL-Anwender quasi so eine Kapselung für sich selbst von Grund auf neu (oder falls vorhanden nutzt eine Lib, wo das schon so ist, wobei die leider nicht für alle Sprachen existieren). Sowas sollte echt nicht notwendig sein.