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.
Wow, you mean a C API feels like... C? I'm shocked!I feels like I'm viewing some ancient C code while viewing opengl code in c++
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.Originally Posted by Alfonse Reinheart
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.
Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/
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?
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Absolutely. And using an OO OpenGL from C would also be stupid.
Your question is in the wrong direction. Instead it should be: is there a reason why it should be object-oriented.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++
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:
- extra (although minor) performance penalty for additional pointer dereferencing on every function call (virtual table).
- the object handles are pointers to user-accessible memory, which supposedly means their internal stuff resides there - a bad idea security-wise and stability-wise. If the internal stuff is not really there then the entire object-oriented thing is just a pointless wrapper to keep young programmers with object-oriented-washed minds happy.
- 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". 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. This means the entire object-oriented stuff is parasitic - it does not add anything useful to the api, it just adds unnecessary side logic and complications for it's own sake.
Posting Permissions
