Definieren eigener GL Core Klasse?

Pria

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?

dot

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...

Pria

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.

cooky451

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.

dot

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++...

Osbios

Aus glew.h:

typedef float GLfloat;

Daher ist es sowieso schon:

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

dot

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

Osbios

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.