glsdk-devel

[Glsdk-devel] GLE progress update

[Jason M. <ko...@gm...>]

So, GLE is progressing.

I have added GLE to the CMake build, and it seems to build. I even ran 
the library through a test application; it seems to work. However, I can 
make no guarantees as to how well it actually works outside of Win32. I 
started off making GLE with the assumption that I'd be able to #include 
gl.h as part of it. Of course, the Windows version of gl.h includes 1.0, 
1.1, and even defines some things for a few extensions. It isn't exactly 
consistent about how this stuff gets defined, and I suspect that 
non-Windows versions of gl.h include different stuff defined in 
different ways.

In short, the only conclusion I can come to in the long term is to fully 
replace the gl.h include with one we create ourselves. This is how GLEW 
works. My main concern with this is how functions are defined in the 
different versions. Windows defines its function entrypoints for the 
stuff in gl.h, not as function pointers, but as live functions. I doubt 
that wglGetExtension will work for them. So I'm not entirely sure how to 
go about handling this part. Any suggestions?

In the short term though, GLE will load all of the 2.1 or 3.0 core 
features. I haven't tested it on GL 3.0, but I know the loading code 
works in 2.1. It doesn't load any WGL stuff yet; that's my next task, 
which shouldn't be too difficult.

Re: [Glsdk-devel] GLE progress update

[StApostol <sta...@gm...>]

> Windows defines its function entrypoints for the
> stuff in gl.h, not as function pointers, but as live functions. I doubt
> that wglGetExtension will work for them. So I'm not entirely sure how to
> go about handling this part. Any suggestions?

You are right regarding wglGetExtension not working with these functions (or
at least not consistently). To make matters worse, different platforms
expose different subsets dynamically, making things tricky.

Solution:

0. Define all signatures. Define static imports for all core functions (i.e.
versions 1.0-3.0). These are not exposed to the user.

1. Define all functions as function pointers. This is the public API.

2. Load each function dynamically (wgl/glx/aglGetAddress). If the function
pointer is *not* -1, 0, 1, 2 or 3 use it. If it is and the function is core,
use the relevant static export instead. Otherwise "arm" the pointer with
NULL.

I am using this method in Tao/OpenTK with success. It works on all platforms
and is reliable.

Notes:

a. Some nvidia drivers return invalid function pointers (-1, 1, 2, 3), so
you have to take this into account.

b. On windows, different contexts may return different function pointers.
This is normally not an issue, as it only happens between different
renderers (e.g. microsoft GDI and an accelerated context). Still, I prefer
to provide a "reload" function to the user in case it's needed.

Re: [Glsdk-devel] GLE progress update

[Jason M. <ko...@gm...>]

StApostol wrote:
> > Windows defines its function entrypoints for the
> > stuff in gl.h, not as function pointers, but as live functions. I doubt
> > that wglGetExtension will work for them. So I'm not entirely sure how to
> > go about handling this part. Any suggestions?
>
> You are right regarding wglGetExtension not working with these 
> functions (or at least not consistently). To make matters worse, 
> different platforms expose different subsets dynamically, making 
> things tricky.
>
> Solution:
>
> 0. Define all signatures. Define static imports for all core functions 
> (i.e. versions 1.0-3.0). These are not exposed to the user.
>
> 1. Define all functions as function pointers. This is the public API.
>
> 2. Load each function dynamically (wgl/glx/aglGetAddress). If the 
> function pointer is *not* -1, 0, 1, 2 or 3 use it. If it is and the 
> function is core, use the relevant static export instead. Otherwise 
> "arm" the pointer with NULL.
>
> I am using this method in Tao/OpenTK with success. It works on all 
> platforms and is reliable.
>
Sounds good. I'll do that once I get the platform-specific stuff working.

BTW, I didn't get this e-mail until today. Something strange with the 
mailing-list server, perhaps?
>
> Notes:
>
> a. Some nvidia drivers return invalid function pointers (-1, 1, 2, 3), 
> so you have to take this into account.
>
> b. On windows, different contexts may return different function 
> pointers. This is normally not an issue, as it only happens between 
> different renderers (e.g. microsoft GDI and an accelerated context). 
> Still, I prefer to provide a "reload" function to the user in case 
> it's needed.
>
The load function already starts by clearing all of the function pointers.