C++ wrappers for OpenGL?

Discussion in 'C++' started by Rune Allnor, Dec 10, 2009.

  1. Rune Allnor

    Rune Allnor Guest

    Hi all.

    I am messing around with some OpenGL code, and am
    starting to get fed up with the hungarian notation.

    Are there any decent C++ wrappers out there?

    Rune Allnor, Dec 10, 2009
    1. Advertisements

  2. Rune Allnor

    Hamiral Guest

    Why do you need a C++ wrapper for OpenGL ? There is no hungarian
    notation in OpenGL, so I'm quite curious where you found it...

    Hamiral, Dec 10, 2009
    1. Advertisements

  3. Perhaps Rune refers to the suffixes (4ub, 3f, etc.) on functions that
    could/would be simply overloaded in C++...

    Victor Bazarov, Dec 10, 2009
  4. Rune Allnor

    Rune Allnor Guest

    I am indeed...
    ....which is why I am pretty sure somebody already have
    made these kinds of wrappers.

    Rune Allnor, Dec 10, 2009
  5. Rune Allnor

    Hamiral Guest

    Oh ok.
    I'm so used to them that I just didn't notice they could pose problems
    to C++ programmers ;)

    Hamiral, Dec 10, 2009
  6. I honestly doubt that. OpenGL programmers are pretty hard-core and they
    just shrug those suffixes off, unlike those soft and mellow C++
    object-oriented folk, who shudder even from a thought of using a C API
    without a wrapper.

    What you are most likely going to see is a whole framework around OpenGL
    or DirectX (or both), abstracting not only color or matrix setting but
    also the entire scene graph, providing caching, and so forth. There is
    no sense doing only the first step by simply wrapping OpenGL in C++
    overloaded functions.

    Victor Bazarov, Dec 10, 2009
  7. They don't, really. No offense intended, but only the programmer who
    *has nothing better to do* would think about introducing a wrapper just
    to get rid of some suffixes in C API. So, if somebody at some point had
    nothing to do, and made such a wrapper library, Rune might be able to
    reuse that. I can see why - there is no sense in wasting time for that.
    But herein lies the conundrum (and Rune understands that, I hope)
    that if it's not worth Rune's time to create such code, then it is not
    worth anybody else's. That's why thin wrappers like that just don't exist.

    Bite the bullet, Rune. Either keep using OpenGL API as is (like we all
    do) with all the unpleasant and annoying suffixes (that you need to get
    right or it doesn't compile!), or write the wrapper yourself. Maybe if
    you write one, I would reuse it... Nah. We're beyond using OpenGL or
    DirectX, we have a whole abstracting framework for our stuff, which is
    what I recommend you use as well.

    Victor Bazarov, Dec 10, 2009
  8. Have you had a look at the Qt libraries yet?
    Robert Hairgrove, Dec 10, 2009
  9. Rune Allnor

    Rune Allnor Guest

    I'm using it. Qt provides everything down to the
    point where to actually draw the scene. Then you
    need to get down to OpenGL functions.

    Rune Allnor, Dec 10, 2009
  10. Rune Allnor

    Hamiral Guest

    I'd add that most of OpenGL functions are commands for which speed is
    particularly critical, so adding an OOP overlay on top of the
    specialized functions like glVertex3f or glTexCoord2f (1) and alike,
    would be a significant overhead, as these functions can get called
    millions of times each frame (so more than 70 million times per second).
    So, as they must execute the fastest possible, even a 0.001ms (2)
    overhead for each call would be a very noticeable performance hit.

    (1) If Rune is concerned with the suffixes, I consider he uses immediate
    mode, so no vertex arrays (which would by the way add a bit of
    performance and of abstraction, which would be interesting in his
    particular case).
    (2) I don't know how much time would it take, but usually OpenGL
    programmers are dealing with lots of lots of vertices and polygons, and
    thus function calls, so any tiny amount of time per call would rapidly
    get noticeable.

    Hamiral, Dec 10, 2009
  11. Rune Allnor

    Rune Allnor Guest

    Sure, I agree in the case of general programming languages.

    What C++ in particular is concerned, there is the template
    option. What I would naively try, if I were to attempt to
    write a wrapper, was something like

    template <typename T>
    void glVertex(const T&,const T&);

    inline void glVertex<GLfloat>(const GLfloat& x, const GLfloat& y)

    inline void glVertex<GLint>(const GLint& x, const GLint& y)

    and so on. This would simplify the code as well
    as give the compiler a chance to optimize away the
    wrapper call. This kind of template code can become
    very effiicient, if the business code is also template

    I don't know how well templates would work in this
    case, though. The function signatures would probably
    have to be mangled by the compiler to identify the
    individual variants of the function in the code
    generation / link step. Since the C++ compiler only
    refers to linked code, not template code, there might
    remain an extra function left at the machine code level.

    Rune Allnor, Dec 11, 2009
  12. Rune Allnor

    Rune Allnor Guest

    Any suggestions for such frameworks?

    Rune Allnor, Dec 11, 2009
  13. Ask in 'comp.graphics.api.opengl', they would definitely know. This is
    beyond the scope of c.l.c++.

    Victor Bazarov, Dec 11, 2009
  14. presumably, yes...

    however, this assumes that the graphics card is a little faster than it
    often is IME, and so, although potentially the GL implementation "could" get
    bogged down with function call overheads, more often, IME, it seems to get
    bogged down with the fill rate...

    it is much like how triangle strips could presumable add a notable amount of
    speed over simply using GL_TRIANGLES and sending out a bunch of triangles
    this way...

    at least in my experience, on newer HW, it doesn't seem to make as much of a

    I guess I will note that for some of my uses, I had essentially wrapped many
    of the GL calls with other calls which would accumulate geometry on their
    own (one goes through the motions, and the calls build up a collection of
    geometry). I had used this, mostly to good effect, for doing more advanced
    texturing and shader effects (to allow my shader code to be fairly generic,
    only caring about generic geometry, rather than about the details of what
    was being drawn...).

    a more advanced strategy could potentially be used to add a whole real-time
    lighting and stencil-shadowing pass to the graphics pipeline (vs more
    manually managing the lighting and shadowing), but I have not personally
    done so (actually, it is probably both easier and more efficient to use a
    mesh/model based strategy at this point, even if this doesn't abstract
    things so well).


    the overhead was "not all that bad", FWIW...

    it is much like how even building a half-assed BSP tree in real-time can
    lead to better performance than trying to have a very low-overhead drawing
    pass (and doing everything linearly), thus leading to the amusing
    side-effect of the fully lit-and-shadowed world getting a better framerate
    than the fullbright version (even though the lights and shadows involve a
    lot of lighting passes and shadow geometry, and the fullbright pass simply
    draws textured polygons...)

    I guess it helps if one can build an approximate BSP on O(n log n) time,
    even if a better one would take O(n^2) or more...

    but, then again, performance is relative, for example, static BSP and
    lightmapping is still a whole lot better performance-wise than is real-time
    BSP and dynamic lighting...

    or such...
    BGB / cr88192, Dec 11, 2009
  15. Rune Allnor

    Hamiral Guest

    I'd say Ogre, but it's as complex as powerful.
    It all depends on what you want to do !

    Hamiral, Dec 11, 2009
  16. Rune Allnor

    Jorgen Grahn Guest

    C++ wrappers for C APIs normally inline, and have zero overhead. You
    write them to get better type safety and code that is easier to read.
    This has nothing to do with object-oriented programming.

    Jorgen Grahn, Dec 12, 2009
  17. Indeed. But there are other things that thin wrappers are useful for.
    For example, scope guards. The OpenGL model has a lot of global state,
    so it's helpful to be able to make localised state changes in a robust
    and cleanly reversible way. And I have, for example, a handy little C++
    class that knows whether an object has changed and needs to be
    re-rendered, or if it can just replay a display list. None of this adds
    up to a complete C++ wrapper, but it's useful enough to have been worth
    Richard Herring, Dec 14, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.