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
     
    Rune Allnor, Dec 10, 2009
    #1
    1. Advertising

  2. Rune Allnor

    Hamiral Guest

    Rune Allnor wrote:
    > 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?


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

    Ham
     
    Hamiral, Dec 10, 2009
    #2
    1. Advertising

  3. Hamiral wrote:
    > Rune Allnor wrote:
    >> 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?

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


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

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 10, 2009
    #3
  4. Rune Allnor

    Rune Allnor Guest

    On 10 Des, 17:47, Victor Bazarov <> wrote:
    > Hamiral wrote:
    > > Rune Allnor wrote:
    > >> 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?

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

    >
    > Perhaps Rune refers to the suffixes (4ub, 3f, etc.)


    I am indeed...

    > on functions that
    > could/would be simply overloaded in C++...


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

    Rune
     
    Rune Allnor, Dec 10, 2009
    #4
  5. Rune Allnor

    Hamiral Guest

    Victor Bazarov wrote:
    > Hamiral wrote:
    >> Rune Allnor wrote:
    >>> 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?

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

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


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

    Ham
     
    Hamiral, Dec 10, 2009
    #5
  6. Rune Allnor wrote:
    > On 10 Des, 17:47, Victor Bazarov <> wrote:
    >> Hamiral wrote:
    >>> Rune Allnor wrote:
    >>>> 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?
    >>> 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...

    >> Perhaps Rune refers to the suffixes (4ub, 3f, etc.)

    >
    > I am indeed...
    >
    >> on functions that
    >> could/would be simply overloaded in C++...

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


    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.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 10, 2009
    #6
  7. Hamiral wrote:
    > Victor Bazarov wrote:
    >> Hamiral wrote:
    >>> Rune Allnor wrote:
    >>>> 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?
    >>>
    >>> 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...

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

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


    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.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 10, 2009
    #7
  8. Rune Allnor wrote:
    > 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


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

    Rune Allnor Guest

    On 10 Des, 21:31, Robert Hairgrove <> wrote:
    > Rune Allnor wrote:
    > > 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

    >
    > Have you had a look at the Qt libraries yet?


    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
     
    Rune Allnor, Dec 10, 2009
    #9
  10. Rune Allnor

    Hamiral Guest

    Victor Bazarov wrote:
    > 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.


    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.

    Ham
     
    Hamiral, Dec 10, 2009
    #10
  11. Rune Allnor

    Rune Allnor Guest

    On 11 Des, 00:17, Hamiral <> wrote:
    > Victor Bazarov wrote:
    > > 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.

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


    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&);

    template<>
    inline void glVertex<GLfloat>(const GLfloat& x, const GLfloat& y)
    {
    glVertex2f(x,y);
    }

    template<>
    inline void glVertex<GLint>(const GLint& x, const GLint& y)
    {
    glVertex2i(x,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
    code.

    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
     
    Rune Allnor, Dec 11, 2009
    #11
  12. Rune Allnor

    Rune Allnor Guest

    On 10 Des, 21:24, Victor Bazarov <> wrote:
    > 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.


    Any suggestions for such frameworks?

    Rune
     
    Rune Allnor, Dec 11, 2009
    #12
  13. Rune Allnor wrote:
    > On 10 Des, 21:24, Victor Bazarov <> wrote:
    >> 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.

    >
    > Any suggestions for such frameworks?


    Ask in 'comp.graphics.api.opengl', they would definitely know. This is
    beyond the scope of c.l.c++.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 11, 2009
    #13
  14. "Hamiral" <> wrote in message
    news:4b218197$0$24608$...
    > Victor Bazarov wrote:
    >> 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.

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


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


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


    > Ham
     
    BGB / cr88192, Dec 11, 2009
    #14
  15. Rune Allnor

    Hamiral Guest

    Rune Allnor wrote:
    > On 10 Des, 21:24, Victor Bazarov <> wrote:
    >> 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.

    >
    > Any suggestions for such frameworks?
    >
    > Rune


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

    Ham
     
    Hamiral, Dec 11, 2009
    #15
  16. Rune Allnor

    Jorgen Grahn Guest

    On Thu, 2009-12-10, Hamiral wrote:
    ....

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


    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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Dec 12, 2009
    #16
  17. In message <hfrlf1$54k$>, Victor Bazarov
    <> writes
    >Hamiral wrote:
    >> Victor Bazarov wrote:
    >>> Hamiral wrote:
    >>>> Rune Allnor wrote:
    >>>>> 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?
    >>>>
    >>>> 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...
    >>>
    >>> Perhaps Rune refers to the suffixes (4ub, 3f, etc.) on functions
    >>>that could/would be simply overloaded in C++...

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

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


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

    --
    Richard Herring
     
    Richard Herring, Dec 14, 2009
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mirek
    Replies:
    5
    Views:
    426
    Natty Gur
    Oct 21, 2003
  2. =?Utf-8?B?UGF0cmljaw==?=

    ASP.Net 2.0 and the annoying <div> wrappers

    =?Utf-8?B?UGF0cmljaw==?=, Apr 25, 2005, in forum: ASP .Net
    Replies:
    8
    Views:
    549
    Patrice
    Apr 25, 2005
  3. Lucas White
    Replies:
    5
    Views:
    428
    Sudsy
    Oct 15, 2003
  4. Maciej Pilichowski
    Replies:
    3
    Views:
    3,567
    Duane Hebert
    Jan 9, 2005
  5. Julie
    Replies:
    4
    Views:
    391
    Jonathan Turkanis
    Jan 28, 2005
Loading...

Share This Page