Curious to who is sticking with OpenGL now...

[mhagain]

Despite my own bad feelings about the state of OpenGL, I'm sticking with it. I currently use both GL and D3D anyway, and will be more inclined to use D3D for newer/experimental/trying-out-stuff-for-the-first-time work, as at least I know that any errors I get have a better chance of being my own errors (rather than coming from broken drivers), and will have the tools to debug them properly to hand, but I'm still committing to OpenGL in at least one project.

I don't feel that I'm doing this as an act of charity, and I'm definitely not doing it due to cross-platform requirements. I think it's good to know and actively work with both APIs, and good to exercise code through both APIs. If the situation was reversed I would likely still be doing the same anyway.

[l_belev]

I cant understand why you guys care so much about those extension loading libraries. I mean how calling xxGetProcAddress 50-100 times can be such big deal for you when you are up writing some massive 3D engine. Getting the extension funcs should be probably less than 1-2% of the total code and even less of the total work (its mostly mechanical work without much thought). The real work is to actually use the extensions in your engine, which you can't avoid anyway.
Personally i never use such libraries. On the surface they seem like saving you some work, but for me thats an illusion - the work they appear to save for "loading the extensions" is negligible and then you are more than compensated for it by having to first find a "good enough for you" such library, then integrating it into your project, then fixing it's shortcomings and tuning it for your particular needs, etc. etc.

[glfreak]

OpenGL took the wrong direction in trying to catch with the recent changes of hardware. And instead of simplifying its implementation, it decided to maintain a backward compatibility
path to support some ancient code that did not want to evolve with technology. Another problem is that OpenGL prefers adding "hacks" to existing bad design decisions over re-writing that part of the relevant specification, which could simplify things on both ends, the developer and the implementer. Take for instance the separate shader object. The lack of unified driver architecture, or something like Driver Binary Interface, where a sample implementation sits on a thin driver layer...All this cannot be afforded and they don't have the resources...whatever reason it's, this is something killing OpenGL.

[l_belev]

OpenGL prefers adding "hacks" to existing bad design decisions over re-writing that part of the relevant specification, which could simplify things on both ends, the developer and the implementer. Take for instance the separate shader object.

I hate how they opted to add layers and patches over the old short-sighted shader api and ended up with that incredible mess of pipelines shaders and programs with mutual relations that are beyond comprehension.

[V-man]

Brandon J. Van Every was asking to have a extension loader sponsored by khronos. I would have to agree. Ever since GL 1.2 came out, it became necessary to load GL and the whole set of extensions. I never understood why the ARB didn't provide one.

Every demo released by nvidia and AMD had a series of calls to wglGetProcAddress but no one ever thought of creating a library.

What ATI did at some point was to create glATI.h, but this was just another glext.h file and also insane.

[Foobarbazqux]

V-man, are you saying that GLEW doesn't meet your needs, but if would if it had a Kronos Group "Seal of Approval"?

[thokra]

I don't think that's what he said or meant. He just stated, that he wasn't sure why Khronos never provided an official loader - which is an appropriate questions.

Although GLEW does the job in probably 99% of all cases, there are some things that still don't work. The most prominent for me is the fact that you still can't use GLEW without trouble on all machines when using a core context. But hey, in such a case one may use GL3W for instance.

[V-man]

It meets my needs.

I'm saying that if you have a bunch of people to whom it isn't a problem and a bunch of people who have such a need, then you can satisfy everyone if khronos just sponsors it (just moved the project over to opengl.org and still have the community work on it). What harm does it do?

[l_belev]

I think standardizing an extension loader is comparable to standardizing an replacement for opengl32.dll - the HW vendors seem to be scared to death of that. The reason is complete mystery to me.

[glfreak]

I hope we see the following changes to the specification in the next version:

1) Unless there's a compelling reason to keep it, get rid of the ugly separate shader object/program pipeline hacks.

2) LibGL.DLL

3) Enough for the next version