Keith Whitwell wrote:
Index: r200_state.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v
retrieving revision 1.6
diff -p -u -r1.6 r200_state.c
--- r200_state.c 27 Dec 2003 22:06:39 -0000 1.6
+++ r200_state.c 22 Jan 2004 01:19:50 -0000
@@ -963,7 +970,7 @@ void r200UpdateMaterial( GLcontext *ctx fcmd[MTL_SHININESS] = mat[MAT_ATTRIB_FRONT_SHININESS][0];
}
- if (R200_DB_STATECHANGE( rmesa, &rmesa->hw.mtl[0] )) {
+ if (R200_DB_STATECHANGE( rmesa, &rmesa->hw.mtl[0] ) || 1) {
for (p = 0 ; p < MAX_LIGHTS; p++) update_light_colors( ctx, p );
It'd be interesting to know why update_light_colors was required here (ie what state changes it was picking up on if not the material ones). Otherwise, looks good.
After some gdb sessions and some look at the code, I believe I now understand what's going on:
Assume both Lighting and Color_Material are enabled. Now they both get disabled (that's what endgame does). Switching off lighting doesn't do anything interesting (as far as this bug goes), but switching off color materials will call r200ColorMaterial (which won't do anything because materials get disabled) and r200UpdateMaterial. R200UpdateMaterial will cause the mtl[0] register to get recalculated, and as long as long as not all FRONT_MATERIAL_BITS were set in the Light.ColorMaterialBitmask previously it will then call update_light_colors (the Light.Material.Attrib matrix is still exactly the same as it was before).
Now lighting and color materials get reenabled. Lighting still doesn't do anything interesting, r200ColorMaterial gets called this time but won't call update_light_colors (since the light_model_ctl1 calculation is exactly the same as last time color materials were enabled). But things go really wrong in r200UpdateMaterial this time. It will never call update_light_colors, since the mtl[0] register is guaranteed to be the same as last time (since only those parts get recalculated which have the corresponding Light.ColorMaterialBitmask bit set, the other just stay the same, and the Light.Material.Attrib matrix is still the same). Maybe the old values in the mtl register won't hurt (maybe they are not used anyway?), but the light color values are now still the same as when color materials were disabled.
Ah. Gack. Well, the sooner a patch goes in the better...
Keith
------------------------------------------------------- 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
