Earlier, I asked, and Brian answered:
> > Does anyone have any idea how modify mesa to get quake3 to use its
> > multi-texturing features?
> Are you sure you've enabled multitexture in the Quake3
Yes. From my autoexec.cfg (and q3config.cfg) in quake's baseq3 directory:
seta r_allowExtensions "1"
seta r_ext_multitexture "1"
seta r_allowSoftwareGL "1"
to allow quake to use s/w-only mesa. Hacking the pixel descriptions in
report accelerated opengl and not having this setting does not help
With the same settings and the opengl for my tnt-card, it does use
What I find weird is that the following is logged by quake on startup when
it comes to initialising the extension (this is for mesa v3.2):
Initializing OpenGL extensions
...GL_S3_s3tc not found
...GL_EXT_texture_env_add not found
...WGL_EXT_swap_control not found
...WGL_3DFX_gamma_control not found
Since the extension string that quake3 reports does include
I would at least have expected either "GL_ARB_multitexture not found" or
"ignoring GL_ARB_multitexture", but it reports neither (for comparison:
when using the tnt opengl, quake3 nicely reports "using
From what I can see in the opengl calls that quake3 issues to the h/w
I get the calls in which quake determines the pixelformat, then it creates
context and queries the vendor, renderer and version strings. Then it
GL_MAX_TEXTURE_UNITS_ARB and after that
GL_MAX_TEXTURE_SIZE. When I run thge s/w mesa, I get all of those calls,
except for the GL_MAX_TEXTURE_UNITS_ARB query, which means
quake3 decides to not use multitexturing based on its settings, the pixel
format, and the extensions string.
I was just hoping someone would have experienced similar problems and
would have found a way out already.
I think I've found the culprit for the problem I described earlier.
It was the wglGetProcAddress, which didn't handle all API functions,
and in my case returned NULL for the handles to the multitexturing
functions. This was fixed in Mesa 4.0.4, so all is well.