Am Donnerstag, 22. Januar 2004 19:12 schrieb Keith Whitwell:
> Roland Scheidegger wrote:
> > 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...
Can we have "one" for all (Michel, Roland, et. al) , please?
-Dieter
-------------------------------------------------------
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
