i want a C++(or even STL) compatible OpenGL API!

i want a C++(or even STL) compatible OpenGL API!

i’m of the opinion that if openGL is ported to C++ many Direct3D programmers will use OpenGL instead of Direct3D

What do you mean with C++ compatible? OpenGL can already be used in a C++ environment.

OpenGL is not bound to a specific language. You can use it in any language you like, BASIC, LISP, Fortran, Pascal, you name it, as long as there are bindings to OpenGL.

And by the way, Direct3D is not a C++ specific API, it can be used with plain C aswell. So why does some people uses Direct3D instead of OpenGL? It’s certainly not because of Direct3D being “C++ compatible”, because both APIs can be used in both plain C as easy as in C++.

Howdy,

I agree with Bob. Futhermore, what on earth do you mean by “compatiable with STL”? STL is just the Standard Template Library. Its not a language, but a library that comes with C++. You might as well be saying you want a stdlib compatible version of OpenGL for C.

cheers,
John

I think he means Object oriented by C++ compatible.

exemple :
std::vector<glDisplayList *> myDLvect;
glDisplayList myDL = new glDisplayList();
myDLvect.push_back(myDL);

or

std::list<glVertexArray *> myVA;
myVA.push_back(new glVertexArray());

I’m sure somebody can make a C++ wrapper …

OpenGL will almost certainly stay with C for a very long time (I mean opengl itself and not the bindings).

If you want a C++ wrapper, all you have to do is a search. There are tons of them around. Isn’t OpenInventor in C++ besides being a scene graph?

One more thing to the OP. You already posted in comp.graphics.api.opengl and got plenty of replies. Try to listen to peoples suggestions.

V-man

I think it’s still early days for
a C++ oriented OpenGL API. For one,
the level of abstraction is not clear -
are we talking about higher level
notions of object heirachies, or just
OpenGL level polygon rendering?

Anyway, this is an are that interests
me, and some results of this thought
are available in the form of a C++
toolkit for OpenGL & GLUT programming.
It’s not complete, but already useful.
There are also links to similar projects
from this page:
http://www.nigels.com/glt/

The worst thing could be an high-level implementation of OpenGL. OpenGL is a solid low-level API, written in C (ANSI), right?

So if I write ANSI code I can compile it on win32 ~ linux and magic it runs!

OpenGL is needed, cause its portability, to stay tuned on C (and it also can be used in C++).

Hi, Ema! :wink:

>>written in C (ANSI), right?

OpenGL is not written in on for any language. OpenGL is a standard, a set of functions. There are bindings for lots of languages, including C.

I have not read DREAMWALKERS prior topic, so I do not know what suggestions he recieved. (if you got a link, I’d read it through) However I would also join him in opting for STL compatible bindings. Please read:

http://www.khronos.org/message_boards/viewtopic.php?f=56&t=4786

The case of OpenCL is very similar to OpenGL in this case. It is a lot younger API, and although implementation is in C, there is a STANDARD cl.hpp wrap to it that is managed by Khronos whenever version is increased. It is no black magic, still very lightweight, but powerful and useful and STL-ready (moreover, it has a more compatible version of vector as cl::vector, but it also supports using homemade vector classes if the proper interface is implemented).

This is what Dreamwalker and I are requesting. OpenGL is just as object oriented as OpenCL, but the bindings seem… very old school. It is really interesting that no centrally maintained C++ wrap has been invented in the past 15 years.

Ideas, suggestions?

Why did you feel the need to unearth an eleven year old thread for a suggestion that:

1: Is not going to happen.

2: Wouldn’t be useful. I’m a C++ programmer, and I would avoid any sort of texture/program/VAO class. At least, not unless DSA is core OpenGL; you don’t want member functions to randomly have to bind stuff just to do their job. And doing the usual constructor/destructor stuff in C++ is dangerous; if someone creates a global texture object, OpenGL won’t be initialized yet. And I fail to see how STL is even involved with this.

3: There technically isn’t even a centralized gl.h. Virtually every OpenGL loading library provides its own headers that replace the platform-specific gl.h. If the ARB doesn’t have a centralized header, they certainly aren’t going to have a centralized C++ header.

To be honest, I did not look at the date, just took a glance at it and thought it was 2009, but actually this proves the point that the need is something new. First of all, thank you for your reply, however:

1: More likely it won’t. I was just curious why it hasn’t happened.

2: Would be useful, I believe. Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects. I do not know what DSA refers to, so an explanation would be welcome. API bindings can be failsafe, but nothing is stupid-safe. I don’t have to strain myself to wreck havoc in the C API either.

3: How come that the spec exists but no central C++ bindings exist? Or to be more precise, for all I care, I don’t give a jumping jellyfish if the header itself is standard or not. OpenCL 1.2 has a few hundred page spec document, and a roughly 40-60 page spec how the C++ bindings must wrap the C API. All I want is to avoid making homebrew libs (I’m a physicist, and I should be doing physics) and to avoid using thrid party junk that god-only-knows whether they will be kept up to date or not.

If OpenGL has a spec (which it does), why cannot a standard binding be specified and let yet again the vendors make their own .hpp files as they see fit.?

I do not know what DSA refers to, so an explanation would be welcome.

EXT_direct_state_access

Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects.

You realize that “Having a runtime keeping track of all the handles it has created” will not magically go away just because you’re programming in C++. It’s a wrapper, so it is implemented on top of the existing C interface.

How come that the spec exists but no central C++ bindings exist?

Because there aren’t “central C bindings” either. There are platform-specific “gl.h” headers, but most people bypass them with glew.h or another loading library.

All I want is to avoid making homebrew libs

Nobody’s forcing you to make a homebrew library to use OpenGL in a C++ application. If you do it, it is only because you want to write a wrapper around it.

The C++ police will not arrest you for using a C API. I promise.

Many applications that use OpenGL do wrap it in an abstraction. But the levels of abstraction are always different. And those wrappers are generally bound to other constructs, like resource managers and the like that ensure that resources are disposed of. Your suggestion would not help them in that task; they would still wrap it because your GL++ would be too low-level to work in.

Would be useful, I believe. Having a runtime keeping track of all the handles it has created is a lot more obscure than having clean objects. I do not know what DSA refers to, so an explanation would be welcome. API bindings can be failsafe, but nothing is stupid-safe.

And how do bindings improve this situation in your opinion? Your GL implementation will still handle every chunk of memory you want it to aquire and you will still have to call specific functions to release said memory. Furthermore, how would you time the initialization of GL objects? Do it when a constructor is called? How do you deal with multiple sets of state? How can you be sure that an object constructed on the app level is already set up and ready for rendering?

In my experience, wrapping OpenGL functionality is much more involved that simply providing a shallow wrapper for a bunch of functions. You can’t use any object wrapping GL calls unless a context is created and made current, as Alfonse already mentioned you can’t use the destructor most of the time, since GL object may very well surpass the lifetime of local app level objects. If you delete it too early, you will most likely get undefined results or even crash your app. But when is the right time to delete it? What it comes down to is that the app has to do a lot of work that has to be triggered explicitly depending on what is needed at the time. Even if you have every function wrapped, you will still have to make smart decisions about when to invoke what and not simply call an object’s convenience functions which do a lot of work for nothing.

The DSA that Alfonse mentioned is short for direct state access and refers to the possibility to change the state of GL objects without first binding them to a specific target, e.g. glBindTexture(GL_TEXTURE_2D, handle). http://www.opengl.org/registry/specs/EXT/direct_state_access.txt shows more precisely what is meant. There were also some vibrant discussions on the topic in this forum.

The API is already C++ compatible. You can call it from C++ code. A C++ style API is another matter entirely, and doesn’t seem to make sense. Why on earth would the ARB specify two APIs that do the same thing? Better to clean out the junk in OpenGL first before making any moves in that direction.

As primarily a D3D programmer, choice of C or C++ was WAY down at the bottom of any concievable list of factors influencing that particular decision. Tools, documention, driver quality, and general API cleanliness came much higher. They’re the issues that need addressing, not C++ifying OpenGL.

I see that people have joined forces against the idea. I admit I am no expert at OpenGL, I have been fiddling around with it for just half a year from a more practical view. All I was trying to say:

being an OpenCL programmer from the very start of it and the first beta releases (some 3 years ago) I have gained quite some experience in the GPGPU side of programming. Seeing the (I believe) rather big difference in the understandability of the C and the C++ bindings of OpenCL, the C++ is a lot more clean and if I were to teach someone, I’d advise them to start using the C++ bindings. I have nothing against the C bindings (apart from being slightly more verbose in code), I have used it long enough to get bored of coding it.

OpenGL by what I understand from the big picture is VERY much similar, Device Contexts, Render Contexts, Buffers, Programs, etc. I do not see how could the idea of C++ bindings practically start a riot, when there is really no big difference. Naively I would think, it would be easier to learn, and the different types of entities, and the respective places of functions relating to handles would be a lot more clean if there were C++ bindings (not wrapped).

I know I can call the code from C++, but that was never the question.

If someone can point out to significant differences in either function or philosophy of the two APIs, and explain why that abolishes the possibility (or the reason) to create C++ bindings, than I will give you the credit.

I’m not too familiar with OpenCL, but in OpenGL we have often to bind objects before they can be used. How would a C++ wrapper look like for e.g. textures? Would it bind the texture automatically for you if you want to change the mag-filter? Will it restore the previously bound texture? Will it require you to call a bind() method of that texture first? Sadly, not everything in OpenGL works the DSA way. There are design questions regarding a C++ interface to OpenGL, that can’t be answered with a perfect solution for everyone.
You can however roll your own C++ wrapper with your philosophy regarding those details. Most methods would be realy simple and can be inlined by the compiler, so you wouldn’t have an overhead. But you must keep the problem with object creation and destruction in mind (you need a context first).

Personally, I like the idea of a C++ wrapper (and I’m working on one despite some problems) but I don’t think a general one-size-fits-all wrapper (or official API) would be easily doable. I don’t even think that would be something the ARB should waste time on, there are bigger problems / thinks that would help more. DSA alternatives for more functions, reading fragment outputs ( :wink: ), more OpenGL 3.3 like OpenGL ES, conformance tests you have to pass before sticking an OpenGL sticker on your driver so Apple can’t get away with there crap… ok, that drifts into a personal wishlist.

The strongest argument against trying to come up with a general, official C++ API is IMHO that the time could be spend more useful by the ARB.

OpenGL by what I understand from the big picture is VERY much similar, Device Contexts, Render Contexts, Buffers, Programs, etc.

Similar in concept perhaps, but not similar in form.

Take the OpenCL function that creates a buffer object, for example:


cl_mem clCreateBuffer(cl_context context, cl_mem_flags flags, size_t size, void *host_ptr, cl_int *errcode_ret);

Notice how the function takes everything it needs as an explicit parameter. Specifically, it takes the context directly, which means that cl_context is defined as part of the OpenCL specification. Not merely the concept of a context, but the actual object itself.

This function returns a new object, which is of the cl_mem type. cl_mem is defined as an opaque pointer: a pointer to a struct of unknown definition.

This is basically an object constructor. It is self-contained, affects nothing other than the parameters it is given, and so forth. Simple and clean; this is what a good C API looks like. It’s pretty obvious what the C++ version would look like.

Now, let’s compare this with the equivalent OpenGL functionality:


GLuint buffer;
glGenBuffer(1, &buffer);
glBindBuffer(GL_ARRAY_BUFFER, buffer);

void glBufferData(GLenum target, GLsizeiptr size, const GLvoid * data, GLenum usage);

Notice the differences. It went from 1 function call to three. It went from a single “create an object” function to “create a name, bind that name to the context, allocate memory in that object”.

Also, note that the context has disappeared. It’s a global context, an implicit parameter to the function. It’s not something that’s directly part of the OpenGL API; it’s an external thing that’s part of the platform-specific API for initializing OpenGL.

Next, realize that this series of functions changes global state. In order to allocate memory for the buffer object, we must first bind it to a target in the OpenGL context. If some other buffer object was already bound to that target, then it becomes unbound. So by binding a buffer at all, you are potentially messing with state someone else owns.

This is not unique to buffer objects; almost every OpenGL function that modifies an object does so by modifying one directly bound to the context. That is the standard way OpenGL operates; only recently have functions appeared that take objects instead of bind target locations like GL_ARRAY_BUFFER.

So now, after having created the name and bound it, we can finally allocate memory for it with glBufferData.

This overall is a bad C API. It’s not encapsulated. It modifies global state needlessly. It has 3-stage object construction, and each of these stages can fire OpenGL errors (which are also global state, not a function parameter).

Imagine class BufferObject, which encapsulates a buffer object. If you want to upload some data to it, with say BufferObject::WriteBuffer or something, this will modify global state. It has to bind the buffer to do that write, thus evicting whatever was bound previously. Yes, it is possible to query what was bound, store it, and then bind it back again afterwards. But that turns a single wrapper function into a longer series of function calls. And then there are the performance implications of all this binding, which aren’t very good.

And buffer objects are the simplest case for OpenGL. Vertex Array Objects may be C’s first non-Euclidean API. I’d tell you of the Eldrich Abominations known as texture objects, but it’s better that you know of sleep untroubled by such things.

The simple fact is this: OpenGL is a terrible C API. Wrapping a crappy API in C++ is not going to make what you get any better. You’re either going to sacrifice performance, functionality, or quality. And likely more than one.

You can certainly do it. But you wouldn’t gain anything by doing so.

If someone can point out to significant differences in either function or philosophy of the two APIs, and explain why that abolishes the possibility (or the reason) to create C++ bindings, than I will give you the credit.

In general, if you’re going to ask for something, it’s a good idea to learn about the current state of that something, rather than make assumptions. It’s common courtesy to educate yourself about currently exists rather than just declaring “It should be like this!” It is not our responsibility to educate you on what OpenGL is; that’s something you should have done yourself before deciding to ask for something.

We get enough lame suggestions in this forum as it is. We don’t need suggestions based on ignorance on top of that.

conformance tests you have to pass before sticking an OpenGL sticker on your driver so Apple can’t get away with there crap…

What Apple gets away with? I’m more concerned about what AMD and NVIDIA (and Intel) get away with. AMD with its occasional missing or broken features (sampler_objects were unusable for 9 months after they were supposedly available), NVIDIA with their ridiculous looseness of spec compliance. These hurt more than anything Apple does.

I agree with Alfonse :smiley:

And btw, why would you suggest this problem, while it isn’t really a problem? I code with C++ and OpenGL a LOT and I never even thought about this.

[quote=Alfonse Reinheart]

What Apple gets away with? I’m more concerned about what AMD and NVIDIA (and Intel) get away with. AMD with its occasional missing or broken features (sampler_objects were unusable for 9 months after they were supposedly available), NVIDIA with their ridiculous looseness of spec compliance. These hurt more than anything Apple does.

I personally don’t have much bad experiances with NVidia or ATI lately (beside a matrix constructor bug in NVidias GLSL compiler) but found some bad bugs in Apples implementation. But if good conformance tests would show problems with other implementations as well (or at least, provide a good overview of what works on which plattform), thats a big step forwards. Riccio (http://www.g-truc.net/post-0445.html#menu) has a great test set. Something in this direction maybe.

Never having owned or seriously used Apple devices up until now excludes me from commenting on that, but I definitely have to agree that developing for NVIDIA and AMD hardware isn’t fun. Let’s leave out Intel - although I have to give them credit because they do a lot of good work for Mesa and push some interesting concepts that Linux will probably benefit from.

NVIDIA notoriously disregards explicit statements and limitations in the spec of the spec which may and most likely will render the algorithm that works on a GeForce useless on a Radeon. For instance, explicit LOD texel fetching works on a chipset I tested without having set the mandatory minification filter. Of course this won’t work when using a mostly compliant implementation like the one provided by AMD.

On the other hand, I had to face a bug in layered rendering using Catalysts 11.10 to current, which wasn’t present in 11.9 or any NVIDIA driver. I checked the code path over and over, verified the absence of errors and it still didn’t work. Essentially, the whole omni shadows approach I used was useless due to this flaw. This is a nice case where standardized conformance tests would have ensured proper functionality.