> 2.1: GLlong and GLulong as 64-bit datatypes
Second this.
> 3.2. The libraries should be located
It's safe to assume that a lot of apps will ship with
there own copies (Q1/Q2/Q3A style) and load.
> 3.4. Entry points supported by these libraries must include either of:
> * All OpenGL 1.1, GLU 1.2, and GLX 1.2 entry points
> * All OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture entry points
(Dumb) question: does GLX physically belong into libGL?
Another dumb question: requiring *one* extension as
standard entry point? I don't think EXTensions should
be required at all.
> 3.5. void (*glGetProcAddressEXT(GLubyte *))(...);
In the port I am currently working on, I keep the Win32
mechanism of LoadLibrary/GetProcAddress (dlopen/dlsym)
which is used for the entire API. I can switch between
TNT and Voodoo on the same box easily.
As we will load instead of link, we do this anyway. Is
it a good idea to provide this inside GL? If the drivers
are indeed separate DLL's, I can see the need. But this
is not GL?
Does this (ab)use of prefix match ARB for non-Linux?
> extensions can always be added to hardware drivers after
> the base link libraries are released. These drivers are
> dynamically loaded by libGL,
How does libGL map a (number of) unknown (at libGL compile
time) extension function names to an equally unknown driver
DLL name, and load that - on query? On glGetProcAddress?
I doubt that people will just link against libGL as present
on the system already. I also see issues with running 2 or
more different OpenGL's, e.g. one in software, one on a
Voodoo2, and one on a TNT main display.
> Should the call also take a GLXContext argument?
That would break the API's unawareness of the context.
If it's a gl* function, it should operate on the
current context (hmmm, bootstrapping issues - context
created before capabilities are added to context?).
If it needs a context argument, then it would be GLX.
> At present it returns the appropriate function for
> the current context, just like its WGL counterpart.
WGL sets precedence this belongs into GLX? For portable
wrappers abstracting WGL/GLX, this should not be placed
in different locations.
> 4.4. glextGetProcAddress()
See above.
This is a simple wrapper around dlsym(). Is loading of
drivers is implicit here? If people use this as a
shortcut to circumvent query for extensions on glGetString
level, it will be trouble.
b.
