Thread: [Glsdk-devel] GLE interface discussion.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

OK, so I've finished with the parsing work. I can gather up a list of 
enums and extension entrypoints for GL, WGL, and GLX. I even have some 
preliminary code generation scripts.

But, as I started actually generating code, I came to realize that there 
are larger questions that we should probably discuss before I take an 
action.

Here is my plan for how GLE will work from a user perspective.

The API will provide this interface function:

gleLoadFunctions(GLint majorVersion, GLint minorVersion);

This will load all functions and extensions up to the given GL version. 
It will work similarly to the way ARB_create_context is specified to do. 
That is, if the version given is 2.1 or less, it will load whatever 
extensions and functions it can up to version 2.1. This includes the 
core extensions released with 3.0. If the version is 3.0 or greater, it 
will load exactly and only that version and whatever extensions apply to 
it. Giving it the wrong version for the current GL context (2.1 context 
but 3.0 loading) then this function will return an error.

We will provide headers that expose enums and entrypoints, but they will 
be versioned. There will be a 2.1 header that exposes 2.1 appropriate 
functions and enums, and there will be a 3.0 version. When 3.1 comes 
out, there will be a version for that too which is separate from the others.

If the ARB decides to release a new version that is backwards compatible 
with the old one, (if they decide not to remove the deprecated features 
in 3.0 for the 3.1 release) then we will still have separate headers, 
but one can simply #include the other.

This all does not mean that headers from one version cannot be used with 
another version. For example, if 3.1 does remove the deprecated 
features, you can still use the 3.0 headers; what matters is what 
context you create and what version you pass to gleLoadFunctions.

BTW, I call it "load functions" rather than "load extensions" for 
marketing reasons. Since you have to use this just to use any modern GL 
version, it sounds silly to a GL newbie to call these things "extensions."

Speaking of context creation, I don't know how it works in GLX, but WGL 
creates a certain stress on the creation of contexts. Often, when making 
a GL context, you want to create a fake context just so that you can get 
access to wglGetExtensionsStringARB and load the WGL extensions.

Because of that, it is useful to have the following function:

gleLoadWinFunctions();

This loads only the WGL/GLX extensions. It requires a valid GL context, 
but you can destroy that context afterwards and the WGL/GLX functions 
should still be available.

The API will also provide global variables, one per extension, which 
will be 0 if the extension is not available and 1 if it is. These 
variables will only be viable if one of the two load function calls has 
been made.

The structure of the headers will look like this:

gle_2_1.h
gle_3_0.h
gle_wgl.h
gle_glx.h
gle_main.h

The first two headers are for the core GL enums and functions. The next 
two are for WGL/GLX enums and functions. gle_main.h is where 
gleLoadFunctions and gleLoadWinFunctions is defined. Any header that 
contains enums and functions will also define the global variables that 
one uses to tell whether the extension is available, but only for those 
extensions that it has.

Thread: [Glsdk-devel] GLE interface discussion.

Utility libraries for working with OpenGL.

glsdk-devel