Simplify syntax and usage

Try to simplify syntax as much as possible.

Do we really need to get thrown in our faces inner details of OpenGL when writing user programs?

For example use glEnable/glDisable where ever possible. Why do I need to know that GL_VERTEX_ARRAY is client state and use glEnableClientState, instead of only glEnable(GL_VERTEX_ARRAY)? (just as a quick illustration).

There are other places as well where OpenGL syntax could be simpler. Those details those contribute to perceive OpenGL as more or less elegant.

Why do we have to use “gl_” prefix in GLSL shaders? Why not using “gl” prefix and be consistent? Once you are used to “gl” the “gl_” prefix is ugly and annoying.

Create only one header file (gl.h) instead of gl3.h gl4.h etc. Same goes for gl3ext.h and alike. That is just annoying to have to hunt headers and versions around.

Get rid of that ridiculous horrible demand that we first have to create older OpenGL context just to be able to create newer 3.xx context.

Get back fixed function & Co back; especially math functions. Deprecating those is idiotic since those are oldest parts of OpenGL and by now probably any vendor has those parts well-working. New vendors will have to work harder …

Fixed function is simple way to start with OpenGL and do some prototyping. It is also well standardized and understood.

Math routines are also a standard way of sending transformations to graphic card, why deprecating those? Vendors could make optimized routines that everybody uses instead of having everybody doing their own math routines. If this puts too much work on driver writers, than OpenGL board could have standard implementation that vendors could ship with their drivers or that people could use. Those old math routines are not only way to upload vectors to graphic cards, but they are also a conception around which applications are programmed (hierarchical modeling and transformations).

Well I hope I don’t sound too harsh; but those are changes I would like to see in OpenGL. I perceive later specifications of OpenGL like just wrong in spirit of OpenGL. Just because we get functionality on par with DirextX, does not mean that OpenGL specs have to look like directx. Why aping dx api, when it is possible to do better?

OpenGL was an elegant and easy to use API. I would really like to see that elegance come back. I think the board should think and create API from user programmers perspective rather than from driver programmers. It is really good to expose details of OpenGL, but it is unnecessary to remind us of those details in API calls.

Why do we have to use “gl_” prefix in GLSL shaders? Why not using “gl” prefix and be consistent? Once you are used to “gl” the “gl_” prefix is ugly and annoying.

Because the “gl” prefix is:

1: For the implementation language, not GLSL.

2: For functions. All “gl_” things are variables. Standard functions in GLSL have no prefix.

Create only one header file (gl.h) instead of gl3.h gl4.h etc. Same goes for gl3ext.h and alike. That is just annoying to have to hunt headers and versions around.

I haven’t used gl.h in years. Nor gl3.h or gl4.h (which doesn’t exist) nor gl3ext.h. Most extension loading systems (and you should be using one of them) have their own headers.

“gl.h” is not standard anymore. It’s just somewhat common.

Get rid of that ridiculous horrible demand that we first have to create older OpenGL context just to be able to create newer 3.xx context.

If you’re going to argue for something, you should argue for something that doesn’t already exist, as clearly stated by the ARB_create_context_profile specification. OpenGL implementations are allowed to give you 3.x or greater compatibility contexts without having to ask for them.

Furthermore, you only have to do that on Windows. And you need to do that anyway to get many useful pixel formats (like multisample and/or sRGB formats) for your default framebuffer. The ARB has no control over WGL, so it’s not going to be fixed by them. If desktop EGL comes into existence, that might be used.

Get back fixed function & Co back

Use the compatibility profile. Problem solved.

Fixed function is simple way to start with OpenGL and do some prototyping.

Yes, it is. It’s also a terrible way to start, since it… well, just read this. That explains the entire argument in great details.

Math routines are also a standard way of sending transformations to graphic card, why deprecating those?

Because it’s silly and limiting. Shader-based code is all about being able to structure things the way you want to. If I want to have, for example, a UBO for every object instance in my game, if I’m using the standard matrices, I can’t put the matrix in that UBO. If I want to have a shared UBO for the projection matrix and other shared data, again, I can’t do that because the gl_ProjectionMatrix is a standard uniform and its contents come directly from OpenGL.

I would really like to see that elegance come back.

There’s nothing “elegant” about the fixed function pipeline, unless all you’re doing is “drawing a texture” with a couple of vertex lights on it. If you’re doing anything even remotely serious per-fragment, it becomes a massive and confusing pile of hacks that only exposes a mere fraction of what hardware is truly capable of.

And switching from “drawing a texture” to rendering that actually matters is a massive step for any user weaned on the fixed-function pipeline. It is so much easier to be trained in shaders from the start than to “learn” things in FFP-land and then have to give up most of that knowledge to use shaders.

You might think that using fixed pipeline features is the way to go but as time goes on and you want to do more complex things you will need to replace all your slow deprecated code and this is a time consuming process. Rather bite the bullet and learn the core profile which is slimmer and faster and which will be around for longer so no need to rewrite all your rendering code. I remember when not writing a single line of code(Game Maker) was the way to go but now I enjoy doing graphics programming, so keep an open mind, your opinions can always change as you gain more experience.