Keith Whitwell wrote:
The rendering errors are a harder problem though, I can see now why the material between begin/end fallback was needed in the first place. There doesn't seem to be an easy way currently to submit material changes between vertices, so it looks like the fallback needs to stay (even though it doesn't really seem to work correctly neither for some reason).


Certainly the bug with the current code should be resolved - I can't think it's too difficult - as the r100 will need it.

The r200 *can* do material changes inside begin/end - basically by using the R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material attributes and then wiring each of these up just like in the glColorMaterial case.
I don't doubt the *chip* can do - I just doubt *I* can do it ;-). Wouldn't it be necessary (and sufficient) just to update the two (front and back) materials, or are you suggesting that it's necessary to send the materials along with the other vertex parameters such as the normals, colors etc.
But updating the current materials would mean that the vertices up to now have to be flushed (?), since as far as I understand the driver it doesn't allow vertex data to be mixed arbitrarily with other state change commands. I'll admit though I don't understand it really...
I tried to implement something like that as a quick hack - it fixed the errors, but looking a bit closer not for the reasons I thought it might help. I just called _tnl_FlushVertices( ctx, ~0 ) at the end of _tnl_Materialfv (t_vtx_api.c), but the strange thing is as far as I can see this won't do anything if it's called inside a primitive. Nevertheless, it fixed the rendering errors in specivewperf proe-02. Wierd.


Roland


------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to