Keith Whitwell wrote:
> Just committed a few small patches, including a couple which suffice to
> get Quake3 working with multitexture under cva. Although I had buy a
> voodoo2 to figure these bugs out, they turned out to be annoyingly
> trivial...
>
> David B, if you're reading - can you look at the change I made to
> fxIsInHardware().
BTW, the following lines in the fxIsInHardware() could be "dangerous":
if (!ctx->Hint.AllowDrawMem)
return GL_TRUE; /* you'll take it and like it */
There is a lot of code that was written assuming that it could be
execute only in a context supported by the hardware. I'm afraid that it
could easy lead to a core dump. Are you already aware of this problem ?
The PGI extension allows nearly any kind of behavior in this case
however a core dump is still out of the specs. The best (more pragmatic)
solution is probably to left the two lines of code where they are, but
to be aware of the possible side effects.
> I think the multitexture tests there were too
> restrictive - it seemed to allow only (GL_MODULATE/GL_MODULATE)
> combinations, although the code elsewhere seems to support a larger set
> of modes.
The code in the driver for the multitexture support is really wired and
I'm afraid that it is hard to understand what I tried to do.
My first idea was very (too much) ambitious and I wasn't fully aware of
the severe limitations imposed by the Voodoo architecture to the OpenGL
multitexture support. I choose to not always move the texture maps for
the texture set 0 in the texture memory of the TMU 0 and the texture
maps for the texture set 1 in the TMU 1, but instead, to check where the
texture maps are (done in the fxSetupDoubleTMU()) and to reconfigure the
TMUs in order to not move the texture maps when the tex. map for the
tex. set 1 is in the TMU 0 and vice versa.
It should be a lot faster to reconfigure the texture combination
functions than downloading a texture maps to the texture memory of a
texture unit.
There is also another advantage: many applications use a GL_RGB (2
bytes) texture format for the texture set 0 and a
GL_LUMINANCE/GL_INTENSITY (light map=1 byte) texture format for the
texture set 1 (the size of the texture set 1 is also smaller). So a
driver that requires a fixed association between TMUs and texture sets
will be able to use the 4MB of the TMU0 but only ~1MB of the TMU1. My
soultion is better because you can download the light maps also in the
TMU0 and the texture maps also in the TMU1.
This was the original idea however there is a problem: the number of
possible cases. The matrix of possible cases has the following size:
<Number of texture functions for the texture set 0 (GL_REPLACE, etc.)> *
<Number of texture internal formats> *
<Number of texture functions for the texture set 1> *
<Number of texture internal formats> *
<The optimization of not storing the set 0 in the TMU0, etc. => 2>
The result is a nightmare ! More than 1500 possible configurations !!!
Note 1: It is a nightmare because the Voodoo architecture doesn't follow
the OpenGL specs (it was developed several years ago and nothing is
changed until today) and requires to handle each texture internal
formats;
Note 2: Some configuration can be grouped and handled like a single
case;
Note 3: Several configurations are not supported by the Voodoo
architecture;
Note 4: The number of possible configurations is still too high.
I hope that my written explanation of the multitexture code is less
wired than the code...
OK, this an explanation of my original idea and why I didn't finished to
write the code. Now, some information of what I have written for real:
- I wrote the code for the support of the optimization of not storing
the set 0 in the TMU0, etc. in the fxvsetup.c file. The new KeithW's
code in the fxvsetup.c file should work with my original idea;
- I wrote the code for handling texture memory/multitexture related
problems in the fxtexmem.c and fxsetup.c file. It should be complete
(but really untested);
- I wrote the code fore the GL_MODULATE/GL_MODULATE combination (with
any texture internal format map support). It was tested only with the
Brian's multitexture demo but it should be OK;
- I wrote the code for GL_REPLACE/GL_BLEND in order to make some test
with GLQuake (but only for the texture internal formats used by Quake
I). This code could be outdated;
- I wrote the code for GL_REPLACE/GL_MODULATE in order to make some test
with QuakeII (but only for the texture internal formats used by Quake
II). This code could be outdated;
The GL_REPLACE/GL_BLEND and GL_REPLACE/GL_MODULATE combinations are
outdated and written only in order to run with QuakeI/II. This is why I
choose to use the hardware only in the GL_MODULATE/GL_MODULATE
combination (and even in this case there are probably some bug) and to
fallbacks to hardware in all other cases.
Keith, we could add the support for Quake3 multitexture code if you know
the kind of texture functions used by Quake3 (I used few printf() for
QuakeI/II in order to know the kind of combinations it was using).
> Also I've prepended the word 'Mesa' to the fx GL_RENDER string as (god
> knows why) the quakeworld client checks to figure out what maximum
> texture size to use.
>
> And finally, am I right in saying that we need a more explicit approach
> to managment of the grHints() calls, and that the call in fxvsetup.c was
> clobbering the state setup by the call in fxSetupDoubleTMU?
Yes, right. The new code for the projective texture support has broken
the previous code for multitexture support.
David Bucciarelli
([EMAIL PROTECTED])
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
