On Wed, 3 May 2000, Jon Leech wrote:
> Perhaps we should create a utility library, maintained in a central
> location along with glext.h, which lets you do something like:
>
> glextCurrentContext(glext, ctx); // loads function pointers for extensions
> glext->TexImage3DEXT(params); // use function pointer
>
> Or maybe it would be in the GLU namespace. Just something to remove
> the burden of extension function pointer handling from ISVs. If it gets
> done soon along with the ABI, it might get wide use.
I like this idea - a lot of people are going to be mindlessly
typing in the same few thousand lines of code otherwise.
I guess putting it in the GLU namespace is a problem because it
implies a change to the GLU spec - and a change that isn't portable
to systems that don't implement some kind of gl*GetProcAddress.
Also, the library would have to be statically linked to programs
because the number of pointers-to-functions inside the glext structure
would change over time as more extensions are added to glext.h
I presume there would also be a means to detect that a particular
call is invalid (it could be a null pointer since this is a per-context
structure) without having to parse the glGetString return?
> > Have I persuaded anyone to switch from A to C or B? :-)
A to B...yes - I can live with that - but not if someone is
going to go back, recount the revised votes and let in C by
some devious combination of tactical voting.
If we are now down to choosing between A, B, and this new, revised
B' then I'm happy to go with any of them.
> There's also an issue regarding crossplatform use of glext.h (which
> is, recall, a design parameter).
...well, it's certainly a WIBNI.
> As I mentioned in response to Thomas
> Roell yesterday, it's necessary to put the 1.2 entry points into glext.h
> for use on e.g. Windows. Whatever solution we come up with needs to
> accomodate this (1.2 prototypes are defined for use on Linux -
> presumably in the core gl.h - and 1.2 typedefs are defined for use
> elsewhere).
Yep - but we can always have '#ifdef WIN32' around those things.
> Finally, nobody ever responded regarding glxext.h. I assume silence
> == consent, so unless there are complaints, glxext.h will go into the
> final ABI specification along with glext.h, and similar structural rules
> will apply to it as well.
Yep - it gets my vote. So should there be wglext.h and aglext.h ?
We talked about a gluext.h also - I recollect that someone said that
since there are no GLU extensions right now, we didn't need it.
I maintain that it should exist and be documented - even if it's an
empty file - just because it *should* exist and because it would be
nice to get this over and done with at some stage and not have to
revisit it every six months.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
