I’ve recently decided to understand how opengl works without the use of a higherlevel API and I’ve noticed how… Stoneage it feels.
Is there a reason to why it’s not objectoriented and/or namespaced? I feels like I’m viewing some ancient C code while viewing opengl code in c++
How do you guys feel about a modern, uptodate revision of OpenGL? The thought about it makes me wanna refurnish the logo as well.
Is it even possible? Is it a good idea? Is it doable? Pro/cons. Discuss
I agree. An object oriented approach is the way to go. This will solve a lot of design problems, driver implementation, and backward comparability issues.
And this is applicable to both the core API and the current platform-dependent context management.
There are wrappers I guess but this is not the point. It should be in the core design and specification of the API.
It’s not my cut of tea at all but I think it’s doable properly only with direct state access.
The main issue with C++ is that there isn’t one way to do things and ways to do think doesn’t scale well with a large number of programmers.
It’s not my cup of tea because the way to do it perfectly for me is to be application specific, hence a generic approach doesn’t sound right to me. Going generic only becomes a level of abstraction which would be obviously less documented then the C API so the programmer would only have to learn one new thing for the sack of being more pretty at first light.
I feels like I’m viewing some ancient C code while viewing opengl code in c++
Wow, you mean a C API feels like… C? I’m shocked!
Let’s get this out of the way right now. The OpenGL ARB has attempted, on two separate occasions, to rewrite the API. They have failed both times.
It’s not going to happen. Either make your peace with OpenGL as it is or use something else. The absolute most you’ll get is standardized direct_state_access. And even that’s rather iffy, since the ARB seems ambivalent on adding functions that do what functions already exist to do.
In any case, any rewrite will have to be C anyway, for two reasons. One, it has a stable ABI. And two, it’s the lowest-common denominator. So the best you would get is object-based C-style coding. No classes, just opaque pointers.
Object-oriented OpenGL is not a new initiative. There was a project called OpenGL++ leaded by SGI (along with IBM and Intel) died before it was born, in 1997.
Although I’m using OO paradigm, and made OO wrapper around GL for my applications, I still think it is better to avoid OO in GL design. The main problem is interoperability. Some platforms do not support OO. Marshaling of complex object can be difficult. It is much easier to have simple types.
Those pointers become even more opaque after NV_shader_buffer_load release. 
You don’t need an object oriented language to use the object oriented paradigm. To be honest, OpenGL with DSA is actually really based around the object oriented paradigm, even though it is still a C-style API. People usually confuse paradigms with programming languages, they are not the same.
IMHO, pure C API based specifications are much easier to read. Just compare the OpenGL and OpenCL specifications (using pure C) with the OpenSL ES specification (using “object oriented” C via function pointers). The later is much more difficult to understand, at least for me, and not because I don’t understand OO or their syntax.
I would like to see a “semi-standard” C++ wrapper for OpenGL with DSA, though I would never like to see C++ stuff in the standard as once you don’t use C++ you are doomed because of ABI incompatibility problems.
The main reason why is because it is ancient C code. 
As has been mentioned, it’s all about interoperability. Every language under the sun has bindings for C libraries, and as a result OpenGL code can be used by every language under the sun.
This includes the colossal number of existing codebases that would need to be completely re-engineered if OpenGL went OO. Some of these are major programs used by 10s or 100s of thousands of people in large corporations too.
Have you ever seen the mess that’s required to get D3D working in a C codebase? It’s not pretty, and large parts of the API (such as the D3DX library) can’t even be used from C at all.
So if you wanted to finally kill off OpenGL this would be a great idea. Otherwise - no.
Who is using Direct3D from C? That is stupid.
What is the advantage of having a OO GL? Faster API? Available on more platforms? Available on more IDE, languages? Easier to use?
Absolutely. And using an OO OpenGL from C would also be stupid.
Is there a reason to why it’s not objectoriented and/or namespaced? I feels like I’m viewing some ancient C code while viewing opengl code in c++
Your question is in the wrong direction. Instead it should be: is there a reason why it should be object-oriented.
If your reason is that “it looks ancient”, don’t expect anyone to get you seriously. (Would you like it to be based on microsoft’s com too?)
I don’t know of a single benefit for any API to be object-oriented. Instead there are various drawbacks. Here are a few:
There seem to be several definitions of “object-oriented” being thrown around here.
In general, I only consider something “object-oriented” with relation to user-controlled runtime polymorphism. Virtual functions, base and derived classes, etc. Just having an “object” with “member functions” alone is not object-oriented to me.
For example, Cario is an object-based C library. It has clearly defined constructors and destructors. It has “member function”, which take an “this” object as well as other parameters. There are a lot of C libraries that are object-based in this way.
DSA brings an object-based system to OpenGL. But it is not object-oriented, per my definition. Object orientation, actual user-defined derived classes with polymorphism, would be utterly useless for a low-level graphics API. What, are you going to derive from a “program object”? What methods would you override? And why would you want to?
If you just want to affect how the GPU compiles the shader, wouldn’t that be something you do as part of the creation of a program object? No need for actual inheritance; just write a simple factory function.
What does it mean to derive from a buffer object? What would you be able to affect by deriving from one? Or from a texture object? What are the user hooks for such objects?
There aren’t any. Information in OpenGL only needs to flow in one direction: from the user to the object. So while making the API object-based would be good, allowing OpenGL code to call user code (which is ultimately what polymorphism is) is not. There simply are no places in the API where this is worthwhile.
If your reason is that “it looks ancient”, don’t expect anyone to get you seriously.
What about, “it looks nonsensical and arbitrary, and is hard to explain to someone learning it?” Does that count? Oh right, you said earlier, “i am very much against api designs that try to prevent the programmer from making mistakes”. So obviously, an API shouldn’t be graded on whether it is simple and clean; an ugly API is just as good as a clean one.
I don’t know of a single benefit for any API to be object-oriented.
Spoken like a true C programmer.
“any API”, not just a low-level graphics API. So, I guess just about every GUI system ever made is wrong, even though the inheritance model works quite well for a GUI (though WPF has its own take on this model).
I certainly understand wanting to pushback against over-reliance on OOP. But that doesn’t mean that it shouldn’t be used where it is warranted. It’s no more of a religious argument to say you should never use something than to say that you should always use something.
At all times, you should strive for the appropriate use of something. You should know where it is a good idea and why it is a good idea there, and where it is a bad idea and why it is a bad idea there. Few are the programming techniques that are wholly without merit.
all the oo is about is what is parent of what. Take the microsoft’s d3d apis for example. With every next version they keep changing that. They themselves can’t decide which is “more right”.
… what? D3D doesn’t have any parent-child relationships among its objects. It has owner-creator relationships. But there is no actual object hierarchy in D3D.
d3d10 lacks the “DeviceContext” interface present in d3d11, instead everything there is just in the “device” interface. But does this lead to any performance or other problem? No.
Um, yes actually. That’s where deferred contexts come from. Microsoft didn’t add those just for their health, you know.
i don’t think the original poster (or anyone else except you) had in mind such kind of object-oriented-ness that you are talking about.
How would you apply “user-controlled runtime polymorphism” to an api that is interface to hardware?
I assure you if it was even possible, microsoft would already have it in their d3d (no matter what ugliness it be would).