Curious to who is sticking with OpenGL now...

[Brandon J. Van Every]

I think it was worth reviving. 7 months later, it's still sitting on Page 1 of the "Suggestions for the next release of OpenGL" subforum. I've been reading it trying to figure out what the state of OpenGL really is.

Why was I even trying to do that, instead of just programming? Because I'm on Windows and getting started on Windows is pretty bad. All that ancient cruft from 1997, "no future investments"... I was actually around writing OpenGL MCD drivers when they did that. 14 years later there still is no standard way to statically call most of the functions on Windows. There are several open source attempts; I'm not sure they can work to create a true standard. There are strange initialization dances. Truth is, context handling is an area where DirectX has evolved and OpenGL has not. OpenGL is lagging in that, and for newbie adoption, it's not a trivial issue.

From a "wasting my time" standpoint, I think it would be rational to write a game in DX11 on Windows, see if it makes money, then port it to OpenGL later on the Mac. Writing a portability layer at a higher level of abstraction may actually be an easier job than dealing with OpenGL on Windows.

From a "I hate MassiveSxxt" standpoint, I'm still investigating those open source options before I pull the trigger on my decision. I feel like I'm evaluating the lesser of two evils.

[V-man]

14 years later there still is no standard way to statically call most of the functions on Windows.

It is pretty simple.
We wrote a Wiki
http://www.opengl.org/wiki

and more specifically
http://www.opengl.org/wiki/Getting_started

and as for statically calling functions, use one of these
http://www.opengl.org/wiki/OpenGL_Loading_Library

[Brandon J. Van Every]

and as for statically calling functions, use one of these

I doubt you ignored what I wrote, so I figure you're saying you like OpenGL just fine. Doesn't need improvement / isn't suffering for its faults. We will agree to disagree.

[V-man]

I read what you wrote but there is no point in suggesting to have a new dll just so that you can statically link. Why? Because just like you, I have suggested the same thing a long time ago and multiple times. I think every one of us have come to this forum and suggested the same thing.

GLEW or GLEE or whatever else there is does the job. You just link it and get coding on your next ID game or whatever.

[Brandon J. Van Every]

Let's unpack "just so you can statically link." Hopefully you agree that having to use dynamically acquired pointers that are only valid in a specific rendering context is a real PITA, a drain on productivity, intelligibility, and maintainability.

Enter the open source extension wrapper libraries, attempting to solve this problem. But they don't agree on what to do, so that means I have to choose a library, understand exactly what it does under the hood, and be prepared to maintain it myself if its authors get hit by a bus. Or as seems more likely, when they just get tired of doing this gruntwork. People believe that has happened to GLee, although actually they're just tired of maintaining webpages to let anyone know what they're really up to. Which isn't that far off in commercial practice, as it undermines confidence.

So, instead of just getting started on OpenGL under Windows, I have to worry about cobbling together the most basic working API. It's as if you wanted to use C++ for your next project, but you were going to have to implement your own vtable, or debug and maintain someone else's. That's why people bolt. Put a lot of pointless gruntwork in the way of commercial developers, and they'll start making business decisions. If I'm writing brand new code and not maintaining some OpenGL legacy app, why do I want to subject myself to this stuff?

Furthermore, most of those wrappers GPL their code generators. Only the final .h .c files are MIT / BSD / zlib. If you believe you're going to have to maintain the library yourself at some point in the future, that's not good.

The answer is clear: create a standard way of binding the extensions, that's static and sane like every other API out there. It can do all the render context and function pointer stuff under the hood. Indeed, I'm still analyzing the various wrapper libraries to figure out if they did it correctly or not. Get rid of the variations, bless the One True Wrapper that actually works. Get rid of the GPL taint. Get Khronos behind it; unfortunately, it sounds like from reading this subforum that Khronos is an impoverished entity with very little muscle for causing things to happen. And that's why people start to see proprietary Microsoft as not so bad, because at least they actually do the work.

[Ilian Dinev]

No, it's more like if you wanted to use C++ on win32, but since you didn't plan on writing a hello-world, you had to create *gasp* a WinMain(), a window-class, a wnd callback function, and a message-pump. Ouch ... ?

file glfuncs.inl :
MACRO(glBindFramebuffer, PFNGLBINDFRAMEBUFFERPROC /* PFN + glBindFramebuffer + PROC , ctrl+shift+U */);

#define MACRO(name,type) extern type name
...
#define MACRO(name,type) name = (type)wglGetProcAddress(#name)

[V-man]

Let's unpack "just so you can statically link." Hopefully you agree that having to use dynamically acquired pointers that are only valid in a specific rendering context is a real PITA, a drain on productivity, intelligibility, and maintainability.

Yes it is. That's why GLEW came along.

Enter the open source extension wrapper libraries, attempting to solve this problem. But they don't agree on what to do, so that means I have to choose a library, ....

I'm not sure what you mean by "they don't agree on what to do". All they do is call wglGetProcAddress.

So what if GLEE or GLEW dies? A new project will come along and we'll add it to the Wiki.

If you don't like those projects because of licensing issues, then create a new project and we'll mention it in the Wiki.

If you don't like those projects because their documentation is not good (GLEW's documentation doesn't mention its problem, that's why we added explanations at http://www.opengl.org/wiki/OpenGL_Loading_Library), we will add explanations to the Wiki.

[Aleksandar]

I really can't understand such level of frustration.

The answer is clear: create a standard way of binding the extensions

OpenGL does have a standard way to bind extensions, and it works excellent for more than a decade. Furthermore, that's one of the OpenGL's features I like the best. There is no need for any SDK. I don't have to wait until someone show mercy to update it. As soon as the drivers are updated, we can use new functionality. That's the freedom not a limitation!

[Brandon J. Van Every]

So what if GLEE or GLEW dies? A new project will come along and we'll add it to the Wiki.

That's not industrial grade software engineering. That's why people opt for better supported libraries like DirectX. Sad to say, open source isn't getting certain jobs done. It's a pity, because theoretically it could.

If you don't like those projects because of licensing issues, then create a new project and we'll mention it in the Wiki.

And then my adoption rate won't be much better, because the vehicle for adoption and standardization isn't any different. I have my doubts that I can recruit people to "the cause," because talking to people such as yourself around here, you don't even understand why such things are of value. You think everything's fine the broken way it is.

[V-man]

I think that people opt for DirectX because DirectX has always had an advantage since 1995 :
-People have heard of it. Microsoft's marketing is strong.
-DirectX 3 exposes hardware features. GL exposes hardware features but a whole lot of things are soft emulated. This had been true until GL 2.1
-Microsoft says DirectX is for games and GL is for CAD in 1995-2000 period.
-DirectX 7/8 has easy to use render to texture while GL sucked
-DirectX 8 has a nice shader model. GL has nothing. There was the nvidia texture combiners and texture shaders. ATI has their own combiners. What a mess.

Personally, I want khronos to make a library so that these kinds of posts would stop. Go to their website and see if there is a contact.
Or visit http://www.opengl.org/registry/
there are emails of driver developers in each extension. Those guys play a role in the ARB.