C++ wrappers for OpenGL?


R

Rune Allnor

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
 
Ad

Advertisements

H

Hamiral

Rune said:
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
 
V

Victor Bazarov

Hamiral said:
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
 
H

Hamiral

Victor said:
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
 
V

Victor Bazarov

Rune said:
I am indeed...


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

Advertisements

V

Victor Bazarov

Hamiral said:
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
 
R

Robert Hairgrove

Rune said:
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?
 
R

Rune Allnor

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
 
H

Hamiral

Victor said:
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
 
R

Rune Allnor

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
 
Ad

Advertisements

R

Rune Allnor

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
 
B

BGB / cr88192

Hamiral said:
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...
 
J

Jorgen Grahn

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

Advertisements

R

Richard Herring

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

Top