The Industry's Foundation for High Performance Graphics

There's a draft <GL3/gl3.h> header in the Registry now, as described in appendix H.2 of the OpenGL 3.1 specification. This is not ready for general use yet, but we'd appreciate feedback from interested parties, particularly in terms of making it work with existing GL 3.1 implementations (getting feedback from Mesa/X.org folks is probably most critical in this regard).

Eventually it will be possible to just drop gl3.h in on top of a shipping GL3.1 implementation, but to get there we need to do some work on the calling conventions and other platform-specific stuff in the header before it's likely to work well on most platforms.

In terms of the interfaces provided, it should be pretty good, but I wouldn't be surprised if a couple of tokens and functions either should be there and are not (core 3.1 functionality), or shouldn't be there and are (removed functionality).

None of the preprocessor logic should be taken too seriously at this point other than GL_VERSION_3_1. Much of it is leftover from rewiring the glext.h generator scripts and there's no
reason to continue #defining GL_VERSION_3_0 (or previous), for example. There are also some extraneous typedefs, such as GLintptrARB, that are only meaningful with glext.h and will be removed soon.

It would be really helpful if feedback came by way of Khronos Bugzilla rather than in the forums, since TBH I am so swamped with internal Khronos stuff that I rarely have time to keep up with the forums. If you do provide feedback that way, please use product "OpenGL" component "Registry".

So does this mean extensions will automatically be bound correctly without user intervention? It seems some of them are listed in that header file.

No, it wont. But nobody stops writing you such functionality yourself. It is actually very simple.

It's just a clean-up of gl.h . You simply add "3" to your "#include <gl\gl.h>" lines, and if your project followed the specs, it compiles and runs without errors.

Jon,

while not directly related to the 3.1 parts, hitting the End key I just found the following (examples for discussion, glGetUniformIndices vs. PFNGLGETUNIFORMINDICESPROC).

Should it be related to a scripting/sed accident, let's leave it at that.

Are there any (valid, technical) reasons that:

- function prototypes are conditionally visible ("#ifdef GL3_PROTOTYPES"), but the function pointer typedefs are not (i.e. always)?

- function prototypes do NOT have the parameter names, but the function pointer typedefs have (isn't this opposite of what one would expect)?

Yes. You cannot expect that the static entry points for anything in glext.h will be defined in the GL link library, in which case there's no utility in defining a bunch of prototypes for functions you can't call except through a function pointer. If you do have a platform that defines some of the extensions in the GL link library, then you probably also have a gl.h provided by the platform that defines those extension interfaces.



I don't think there's a valid technical reason, it's more an ancient legacy of the way the generator scripts were originally written at SGI 20-odd years ago persisting through many rewrites of the scripts. It could be changed and I occasionally find it a bit annoying myself, but OTOH it bulks up what's already an enormous header file even more and is a largely gratuitous change.

This isn't a great idea when considering multi-version libraries such as SDL as gl.h and gl3.h can't be compiled together. From this it's unlikely to find full adoption and may interfere with other APIs, is gl3.h really needed?

I would support the idea if it was more like GLEW and provided easy access to any core spec and extentions but otherwise I don't see a point.

It would be nice to see a more developer-oriented/user-friendly header. I can live with having to grab function pointers for what I want to use, but the main problem I and others have is in knowing _what_ to grab, especially now that the deprecation model is in place. A complete API listing for the different OGL versions would be a great step forward in solving this. I know a fair few people who've chosen DX over OGL for this very reason.


I also this comment! Even something like a #define to specify which version and profile of OGL your code wants support for would be fantastic. Then you could at least be 100% certain that you're not using any functionality that isn't included in the target version (e.g. deprecated/from newer OGL versions). There's far, far too much API-user-interpretation possible at the moment.

I think the very fact that libraries like GLEW exist to try and help with the confusion/uncertainty in using OGL these days is indicative of some fundamental problems. If I hadn't started with OGL back in the days when it was still extremely straightforward to use (circa '96), I'd probably have picked DX. Much, much more documentation, slightly better feature-set, and a lot simpler to set up correctly.

...Wow. I never thought I'd say that last phrase.