Definieren eigener GL Core Klasse?



  • Hallo,

    ich habe mir überlegt, ob es eventuell sinnvoll wäre, für eine anwendung eine Wrapper Klasse um OGL herum zu bauen. Der Header umfasst ja bereits alles was OGL bietet, jedoch sind mir offen gestanden die ganzen speziealtypen glint etc. zu wieder.

    ich würde also gerne aus einer Funktion void glVertex3f(GLfloat x, GLfloat y, GLfloat z); etwas machen, dass mehr Zeitgemäß ist und in etwa so ausehen würde
    void GL::Vertex3f(float x,float y,float z);

    Ich weiss, dass Konstrukte wie

    void GL::Vertex3f(float x,float y,float z)
    {
       glVertex3f((GLfloat)x, (GLfloat)y, (GLfloat)z);
    }
    

    zusätzlichen Overhead kosten.

    In C# geht das ja gerade wegen des DLL-Imports relativ einfach und unkompliziert, gibts da in c++ eine andere Möglichkeit, etwa in Form eines Templates, so etwas zu realisieren, sodass der overhead nicht wesentliche rhöht wird?



  • Pria schrieb:

    ich würde also gerne aus einer Funktion void glVertex3f(GLfloat x, GLfloat y, GLfloat z); etwas machen, dass mehr Zeitgemäß ist und in etwa so ausehen würde
    void GL::Vertex3f(float x,float y,float z);

    Was genau ist denn das Problem mit GLfloat, ist doch nur ein typedef!? Abgesehen davon: "Zeitgemäß" und "glVertex3f()" ist dann doch irgendwie ein Widerspruch, findest du nicht? 😉

    Pria schrieb:

    Ich weiss, dass Konstrukte wie

    void GL::Vertex3f(float x,float y,float z)
    {
       glVertex3f((GLfloat)x, (GLfloat)y, (GLfloat)z);
    }
    

    zusätzlichen Overhead kosten.

    Ist das so?

    Pria schrieb:

    In C# geht das ja gerade wegen des DLL-Imports relativ einfach und unkompliziert, gibts da in c++ eine andere Möglichkeit, etwa in Form eines Templates, so etwas zu realisieren, sodass der overhead nicht wesentliche rhöht wird?

    namespace GL
    {
      inline void Vertex(float x, float y)
      {
        glVertex2f(x, y);
      }
    
      inline void Vertex(float x, float y, float z)
      {
        glVertex3f(x, y, z);
      }
    
      inline void Vertex(float x, float y, float z, float w)
      {
        glVertex4f(x, y, z, w);
      }
    
      inline void Vertex(double x, double y, double z)
      {
        glVertex3d(x, y, z);
      }
    
      // ...
    }
    

    Overhead: 0, zumindest mit einem ordentlichen Compiler...



  • dot schrieb:

    Was genau ist denn das Problem mit GLfloat, ist doch nur ein typedef!? Abgesehen davon: "Zeitgemäß" und "glVertex3f()" ist dann doch irgendwie ein Widerspruch, findest du nicht? 😉

    Ohne jetzt hier eine Diskussion vom Zaun brechen zu wollen, natürlich ist das Ganze mit v3 überholt worden, jedoch für Einstiegstutorials und um schnell vernünftige Resultate auf den Schirm zu kriegen sicherlich noch von Relevanz.

    dot schrieb:

    Ist das so?

    Naja gut, wenn ich die nicht mit inline verwende sicherlich

    dot schrieb:

    namespace GL
    {
      inline void Vertex(float x, float y)
      {
        glVertex2f(x, y);
      }
    
      inline void Vertex(float x, float y, float z)
      {
        glVertex3f(x, y, z);
      }
    
      inline void Vertex(float x, float y, float z, float w)
      {
        glVertex4f(x, y, z, w);
      }
    
      inline void Vertex(double x, double y, double z)
      {
        glVertex3d(x, y, z);
      }
    
      // ...
    }
    

    Overhead: 0, zumindest mit einem ordentlichen Compiler...

    Was heißt ordentlicher Compiler?

    Inwiefern ist denn VS ordentlicher oder weniger ordentlich als Borland oder IBM?

    Wenn das Funktioniert, bin ich zumindest mal zufreiden.



  • Pria schrieb:

    Naja gut, wenn ich die nicht mit inline verwende sicherlich

    Das hat mit inline nichts zu tun, das steht da nur um die one-definition-rule zu umgehen. Was der Compiler wann inlined und was nicht, kann er meistens doch ganz gut alleine entscheiden. 😉

    Abgesehen davon halte ich eine solche Lösung nicht für sinnvoll. Ich würde eher eine pimpl device_context Klasse nehmen, die dann je nach #defines compilet was man will. Dann hat der Rest des Programms schon mal nichts mit irgendwelchen Grafikheadern am Hut. Und im Hintergrund arbeitet man dann doch eh mit Klassen für uniforms, attributes etc. das noch mal zu kapseln bringt irgendwie wenig.



  • Pria schrieb:

    dot schrieb:

    Was genau ist denn das Problem mit GLfloat, ist doch nur ein typedef!? Abgesehen davon: "Zeitgemäß" und "glVertex3f()" ist dann doch irgendwie ein Widerspruch, findest du nicht? 😉

    Ohne jetzt hier eine Diskussion vom Zaun brechen zu wollen, natürlich ist das Ganze mit v3 überholt worden, jedoch für Einstiegstutorials und um schnell vernünftige Resultate auf den Schirm zu kriegen sicherlich noch von Relevanz.

    Ich stimme dir prinzipiell zu, veraltet ist es trotzdem; aber egal, darum geht's hier ja nicht. 😉

    Pria schrieb:

    dot schrieb:

    Ist das so?

    Naja gut, wenn ich die nicht mit inline verwende sicherlich

    Nope, vermutlich selbst dann nicht, moderne Compiler sind sehr schlau...

    Pria schrieb:

    Was heißt ordentlicher Compiler?

    Damit meinte ich einen Compiler, der das eben inlined, was so ziemlich jeder halbwegs moderne Compiler tun sollte. MSVC 13+ (VS .NET 2003 aufwärts) z.B. würde das, dank LTCG, sogar noch inlinen, wenn die Funktionen gar nicht als inline deklariert und in einem separaten .cpp File definiert sind. Im Zweifelsfall einfach den generierten Assemblercode checken, aber man kann mit ziemlicher Sicherheit davon ausgehen, dass diese Funktionen im Release Build direkt die entsprechenden gl* Calls generieren und der Overhead damit nicht nur sehr klein, sondern tatsächlich nicht vorhanden ist. Willkommen in der wunderbaren Welt von C++... 😉



  • Aus glew.h:

    typedef float GLfloat;
    

    Daher ist es sowieso schon:

    glVertex3f(float x, float y, float z);
    


  • Natürlich ist es das, daher ja auch meine Frage, was genau das Problem mit GLfloat sei... 😉



  • War mir klar das du es wusstest. War nur nicht sicher ob es bei Pria auch angekommen ist, dass es genau der selbe Typ ist. 😉


Anmelden zum Antworten