Stephen J Baker wrote:
> > Now still one lingering issue. The document states that even a
> > libGL.so.1.1 has to have include files that export OpenGL 1.2, GLU 1.3
> > and GLX 1.3 entry points.
> > Is that really wise to do ?
Yes. Every Quake and Quake-engine based game requires GLX entry points
in the libGL.so loaded (which Q3A seemingly retrieves from system locations
first right now). This is part of the dlopen/dlsym/dlclose handling of
the "gldriver" in their refresh module (which in turn is dynamically
loaded by the main engine).
Given the current speed (and number of branches) of Mesa/GLX development,
we expect this to be necessary for Linux games for at least a few more
months (i.e. up until: XFree86 4 shipping, Utah GLX and XFree86 GLX
merging, GART kernel modules being part of distribution kernels, glx.conf
location nailed down etc.pp.).
Currently, GL's for e.g. Q3A don't work for Q1/Q2/UT/H2 (not even talking
about MythII, which at the moment is a Glide-only game...). Until we are
able to safely link against a system-wide libGL.so, we have to provide
our customers the ability to have per-game DLL's in game specific directories.
> I suppose leaving out the "entry points" (ie function prototypes)
> would be OK because -
>
> * Linux OpenGL Base programs will be using glGetString(GL_VERSION)
> and GetProcAddress at runtime...so they don't need the function
> prototypes anyway.
They do not do this at the moment. It will require maintenance releases
for all the current Mesa based games for Linux if the entry points are
left out. I have no objection against requiring this at a later stage,
but right now I strongly suggest requiring the entry points for legacy,
while making explicit that dlsym() use should be restricted to a single
dlsym("glxGetProcAddress") call.
b.
--
"Problem solving is hunting. It is savage pleasure,
and we are born to it." Thomas Harris, Silence of the Lambs
