From: Michel <mi...@da...> - 2004-01-12 16:44:13
|
Finally some progress on this front! :) I tracked down the lighting problems in the xscreensaver queens hack to attenuation being broken. I noticed that the R200 DDK reference driver does much more to handle it, in fact our driver doesn't seem to enable it at all! http://penguinppc.org/~daenzer/DRI/r200-attenuation.diff makes things look much better in general, but in particular in bzflag. :) I'd like to get a review from an OpenGL guru before committing it though. I'm curious if this helps with NWN. There are still minor problems, e.g. in the xscreensaver endgame hack, but those might be related to colour material (known to horribly break trackballs, e.g.). BTW, I still get flickering in lightlab when enabling the object specular colour, maybe it takes some more tweaking of the state atom emit order, Andreas? :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-01-12 20:57:07
|
Michel D=C3=A4nzer wrote: > Finally some progress on this front! :) >=20 > I tracked down the lighting problems in the xscreensaver queens hack > to attenuation being broken. I noticed that the R200 DDK reference > driver does much more to handle it, in fact our driver doesn't seem > to enable it at all! >=20 > http://penguinppc.org/~daenzer/DRI/r200-attenuation.diff >=20 > makes things look much better in general, but in particular in > bzflag. :) I'd like to get a review from an OpenGL guru before > committing it though. >=20 > I'm curious if this helps with NWN. There are still minor problems, > e.g. in the xscreensaver endgame hack, but those might be related to > colour material (known to horribly break trackballs, e.g.). Yes! This did it! NWN lighting is much, much better now, the previously seriously messed up areas now look almost completely correct. Great work! Some minor lighting problmes still remain (I spotted 3 which might be=20 related though): - selected doorways should be half-transparent, blue. Instead they are=20 anything from almost black to grey (depending on map) - If the main character is selected, it should "shine". There is some=20 light around the character, but the character itself doesn't shine. - If a path is selected, a green target indicator should appear=20 (indicating where the character goes). Instead, the indicator is almost=20 invisible (way too dark). I can provide screenshots if you (or someone else) want to look at it. Roland btw I couldn't apply the patch cleanly, hat to do one part of it=20 manually. Might be my fault, though. |
From: Michel <mi...@da...> - 2004-01-12 22:05:50
|
On Mon, 2004-01-12 at 22:00, Roland Scheidegger wrote: > Michel Dänzer wrote: > > > > I'm curious if this helps with NWN. There are still minor problems, > > e.g. in the xscreensaver endgame hack, but those might be related to > > colour material (known to horribly break trackballs, e.g.). > Yes! This did it! NWN lighting is much, much better now, the previously > seriously messed up areas now look almost completely correct. Great work! Cool. > Some minor lighting problmes still remain (I spotted 3 which might be > related though): > - selected doorways should be half-transparent, blue. Instead they are > anything from almost black to grey (depending on map) > - If the main character is selected, it should "shine". There is some > light around the character, but the character itself doesn't shine. > - If a path is selected, a green target indicator should appear > (indicating where the character goes). Instead, the indicator is almost > invisible (way too dark). These sound to me like they could all be related to colour material, but what do I know. :) > I can provide screenshots if you (or someone else) want to look at it. Why not, I can't try it myself. > btw I couldn't apply the patch cleanly, hat to do one part of it > manually. Might be my fault, though. I made it against the CVS module Mesa, apparently Mesa-newtree isn't up to date on freedesktop.org. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-01-12 23:03:55
|
Michel D=C3=A4nzer wrote: >>Some minor lighting problmes still remain (I spotted 3 which might be=20 >>related though): >>- selected doorways should be half-transparent, blue. Instead they are=20 >>anything from almost black to grey (depending on map) >>- If the main character is selected, it should "shine". There is some=20 >>light around the character, but the character itself doesn't shine. >>- If a path is selected, a green target indicator should appear=20 >>(indicating where the character goes). Instead, the indicator is almost= =20 >>invisible (way too dark). >=20 >=20 > These sound to me like they could all be related to colour material, bu= t > what do I know. :) >=20 >=20 >>I can provide screenshots if you (or someone else) want to look at it. >=20 >=20 > Why not, I can't try it myself. ok, how it should look like: http://homepage.hispeed.ch/rscheidegger/nwn_notcl_door_highlight.jpg http://homepage.hispeed.ch/rscheidegger/nwn_notcl_target_char_highlight.j= pg and how it looks with tcl: http://homepage.hispeed.ch/rscheidegger/nwn_tcl_door_highlight.jpg http://homepage.hispeed.ch/rscheidegger/nwn_tcl_target_char_highlight.jpg Strangely enough, IIRC the target indicator did work correctly some time=20 ago, not sure what broke it (I'm sure the door highlighting never=20 worked, not sure about the character shininess). Roland |
From: Michel <mi...@da...> - 2004-01-13 13:38:43
|
On Mon, 2004-01-12 at 17:44, Michel Dänzer wrote: > > There are still minor problems, e.g. in the xscreensaver endgame hack, > but those might be related to colour material (known to horribly break > trackballs, e.g.). The funny thing about the problem in endgame is that it's much less severe if run as R200_DEBUG=state /usr/lib/xscreensaver/endgame 2>/dev/null as opposed to just /usr/lib/xscreensaver/endgame ... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Felix <fx...@gm...> - 2004-01-13 13:52:28
|
On Tue, 13 Jan 2004 14:38:37 +0100 Michel D=E4nzer <mi...@da...> wrote: > On Mon, 2004-01-12 at 17:44, Michel D=E4nzer wrote: > >=20 > > There are still minor problems, e.g. in the xscreensaver endgame hack,= =20 > > but those might be related to colour material (known to horribly break= =20 > > trackballs, e.g.). >=20 > The funny thing about the problem in endgame is that it's much less > severe if run as >=20 > R200_DEBUG=3Dstate /usr/lib/xscreensaver/endgame 2>/dev/null >=20 > as opposed to just >=20 > /usr/lib/xscreensaver/endgame A timing problem? Then maybe the old lockup workaround for radeon would solve this. It put a "wait for 3D idle" on the command queue before emitting the state. It's a performance hit though. Even if it's not adopted as final solution it could prove that these problems are caused by emit_state oddities (or maybe not ;-). >=20 > ... >=20 >=20 > --=20 > Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer > Software libre enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Michel <mi...@da...> - 2004-01-13 18:25:16
|
On Tue, 2004-01-13 at 14:51, Felix Kühling wrote: > On Tue, 13 Jan 2004 14:38:37 +0100 > Michel Dänzer <mi...@da...> wrote: > > > On Mon, 2004-01-12 at 17:44, Michel Dänzer wrote: > > > > > > There are still minor problems, e.g. in the xscreensaver endgame hack, > > > but those might be related to colour material (known to horribly break > > > trackballs, e.g.). > > > > The funny thing about the problem in endgame is that it's much less > > severe if run as > > > > R200_DEBUG=state /usr/lib/xscreensaver/endgame 2>/dev/null > > > > as opposed to just > > > > /usr/lib/xscreensaver/endgame > > A timing problem? Apparently... > Then maybe the old lockup workaround for radeon would solve this. It put a > "wait for 3D idle" on the command queue before emitting the state. It's a > performance hit though. Even if it's not adopted as final solution it could > prove that these problems are caused by emit_state oddities (or maybe not ;-). I thought of this as well, but it doesn't make a difference. What makes the difference is calling _mesa_lookup_enum_by_nr() at the beginning of r200Enable(), probably due to the delay. Granted, it doesn't help with the reflections, and if those are disabled, it doesn't help at all, but I don't understand why delaying there would have any effect... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2004-01-13 19:57:04
|
Michel Dänzer wrote: > On Tue, 2004-01-13 at 14:51, Felix Kühling wrote: > >>On Tue, 13 Jan 2004 14:38:37 +0100 >>Michel Dänzer <mi...@da...> wrote: >> >> >>>On Mon, 2004-01-12 at 17:44, Michel Dänzer wrote: >>> >>>>There are still minor problems, e.g. in the xscreensaver endgame hack, >>>>but those might be related to colour material (known to horribly break >>>>trackballs, e.g.). >>> >>>The funny thing about the problem in endgame is that it's much less >>>severe if run as >>> >>>R200_DEBUG=state /usr/lib/xscreensaver/endgame 2>/dev/null >>> >>>as opposed to just >>> >>>/usr/lib/xscreensaver/endgame >> >>A timing problem? > > > Apparently... > > >>Then maybe the old lockup workaround for radeon would solve this. It put a >>"wait for 3D idle" on the command queue before emitting the state. It's a >>performance hit though. Even if it's not adopted as final solution it could >>prove that these problems are caused by emit_state oddities (or maybe not ;-). > > > I thought of this as well, but it doesn't make a difference. > > What makes the difference is calling _mesa_lookup_enum_by_nr() at the > beginning of r200Enable(), probably due to the delay. Granted, it > doesn't help with the reflections, and if those are disabled, it doesn't > help at all, but I don't understand why delaying there would have any > effect... Does a usleep(1) in the same place have the same effect? Does the hardware actually "see" the delay? It will only be exposed to delays *between* command buffers - delays aren't preserved within a buffer submitted to hardware as a whole... Keith |
From: Michel <mi...@da...> - 2004-01-13 20:46:21
|
On Tue, 2004-01-13 at 20:56, Keith Whitwell wrote: > Michel Dänzer wrote: > > > > What makes the difference is calling _mesa_lookup_enum_by_nr() at the > > beginning of r200Enable(), probably due to the delay. Granted, it > > doesn't help with the reflections, and if those are disabled, it doesn't > > help at all, but I don't understand why delaying there would have any > > effect... > > Does a usleep(1) in the same place have the same effect? No... unsurprisingly, it does kill performance though. (BTW, nanosleep() might be a better fallback than usleep() for throttling?) > Does the hardware actually "see" the delay? I doubt it, at least the framerate doesn't seem affected. > It will only be exposed to delays *between* command buffers - delays > aren't preserved within a buffer submitted to hardware as a whole... Hence my bafflement... what's special about _mesa_lookup_enum_by_nr()? Does the attenuation patch look good to you though? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2004-01-14 10:33:48
|
Michel Dänzer wrote: > On Tue, 2004-01-13 at 20:56, Keith Whitwell wrote: > >>Michel Dänzer wrote: >> >>>What makes the difference is calling _mesa_lookup_enum_by_nr() at the >>>beginning of r200Enable(), probably due to the delay. Granted, it >>>doesn't help with the reflections, and if those are disabled, it doesn't >>>help at all, but I don't understand why delaying there would have any >>>effect... >> >>Does a usleep(1) in the same place have the same effect? > > > No... unsurprisingly, it does kill performance though. (BTW, nanosleep() > might be a better fallback than usleep() for throttling?) > > >>Does the hardware actually "see" the delay? > > > I doubt it, at least the framerate doesn't seem affected. > > >>It will only be exposed to delays *between* command buffers - delays >>aren't preserved within a buffer submitted to hardware as a whole... > > > Hence my bafflement... what's special about _mesa_lookup_enum_by_nr()? > > > Does the attenuation patch look good to you though? > Couple of questions - What's going on here - is there something the hw can't handle? + if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) { + /* Can't do even constant attenuation, disable */ + icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift); Secondly - what's the ATTEN_XXX constant? I realize that it's mine, but I can't remember what it's all about... Keith |
From: Michel <mi...@da...> - 2004-01-14 14:44:35
|
On Wed, 2004-01-14 at 11:33, Keith Whitwell wrote: > > What's going on here - is there something the hw can't handle? > > + if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) { > + /* Can't do even constant attenuation, disable */ > + icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift); The refernce driver does this; excuse my ignorance, but maybe constant attenuation of 1.0 is the same as no attenuation? > Secondly - what's the ATTEN_XXX constant? I realize that it's mine, but I > can't remember what it's all about... I don't know what it's for, but again, the reference driver always sets it to zero. :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-01-13 20:09:36
|
Michel D=C3=A4nzer wrote: > On Tue, 2004-01-13 at 14:51, Felix K=C3=BChling wrote:=20 >=20 >>On Tue, 13 Jan 2004 14:38:37 +0100 >>Michel D=C3=A4nzer <mi...@da...> wrote: >> >> >>>On Mon, 2004-01-12 at 17:44, Michel D=C3=A4nzer wrote: >>> >>>>There are still minor problems, e.g. in the xscreensaver endgame hack= ,=20 >>>>but those might be related to colour material (known to horribly brea= k=20 >>>>trackballs, e.g.). >>> >>>The funny thing about the problem in endgame is that it's much less >>>severe if run as >>> >>>R200_DEBUG=3Dstate /usr/lib/xscreensaver/endgame 2>/dev/null >>> >>>as opposed to just >>> >>>/usr/lib/xscreensaver/endgame >> >>A timing problem?=20 >=20 >=20 > Apparently... Sure this is about timing? What I see in endgame is this: Every few seconds, the colors change from orange/brown to=20 orange-brown/grey. Compared to R200_NO_TCL (or software mesa) both of=20 these color sets are wrong (should be orange/grey if mesa is correct). Apart from that, I couldn't see other errors (with a 9000pro). Maybe not all necessary state is submitted? Roland |
From: Michel <mi...@da...> - 2004-01-13 20:51:07
|
On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote: > > Sure this is about timing? No, the only thing I'm sure of is that _mesa_lookup_enum_by_nr() reliably works around part of the problem here. > What I see in endgame is this: > Every few seconds, the colors change from orange/brown to > orange-brown/grey. Compared to R200_NO_TCL (or software mesa) both of > these color sets are wrong (should be orange/grey if mesa is correct). It has several colour schemes, but yes, the alternating lighting (which seems to correspond to some moving pieces here) is the problem. > Maybe not all necessary state is submitted? Maybe, but that doesn't really explain my observations, does it? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-01-13 22:24:45
|
Michel D=C3=A4nzer wrote: > On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote: >=20 >>Sure this is about timing? >=20 >=20 > No, the only thing I'm sure of is that _mesa_lookup_enum_by_nr() > reliably works around part of the problem here. >=20 >=20 >>What I see in endgame is this: >>Every few seconds, the colors change from orange/brown to=20 >>orange-brown/grey. Compared to R200_NO_TCL (or software mesa) both of=20 >>these color sets are wrong (should be orange/grey if mesa is correct). >=20 >=20 > It has several colour schemes, but yes, the alternating lighting (which > seems to correspond to some moving pieces here) is the problem. >=20 >=20 >>Maybe not all necessary state is submitted? >=20 >=20 > Maybe, but that doesn't really explain my observations, does it? Well for me there was no difference at all when running with=20 R200_DEBUG=3Dstate (except the huge speed difference of course), and sinc= e=20 the alternating lighting doesn't appear to be random (as you've also=20 observed) and I never get the correct colours I just thought it's=20 probably not timing related. But I'm certainly no expert ;-) Interesting you got multiple colour schemes, here it is strictly limited=20 to only 2. Roland |
From: Michel <mi...@da...> - 2004-01-14 02:05:15
|
On Tue, 2004-01-13 at 23:28, Roland Scheidegger wrote: > Michel Dänzer wrote: > > On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote: > > > >>Maybe not all necessary state is submitted? > > > > Maybe, but that doesn't really explain my observations, does it? > Well for me there was no difference at all when running with > R200_DEBUG=state (except the huge speed difference of course), Did you redirect stderr to /dev/null or to a normal file? > and since the alternating lighting doesn't appear to be random (as > you've also observed) and I never get the correct colours I just > thought it's probably not timing related. But I'm certainly no expert ;-) Neither am I... my guess has been that the lighting switch occurs on certain state transitions, but only under certain (timing or whatever) conditions. > Interesting you got multiple colour schemes, here it is strictly limited > to only 2. Maybe we're not using the same version? 4.14 here. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Roland S. <rsc...@hi...> - 2004-01-14 12:04:19
|
Michel D=C3=A4nzer wrote: > On Tue, 2004-01-13 at 23:28, Roland Scheidegger wrote: >=20 >> Michel D=C3=A4nzer wrote: >>=20 >>> On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote: >>>=20 >>>=20 >>>> Maybe not all necessary state is submitted? >>>=20 >>> Maybe, but that doesn't really explain my observations, does it? >>=20 >> Well for me there was no difference at all when running with=20 >> R200_DEBUG=3Dstate (except the huge speed difference of course), >=20 >=20 > Did you redirect stderr to /dev/null or to a normal file? Tried both, but even redirecting to /dev/null causes a large drop in performance and otherwise there was no difference. >> and since the alternating lighting doesn't appear to be random (as >> you've also observed) and I never get the correct colours I just=20 >> thought it's probably not timing related. But I'm certainly no >> expert ;-) >=20 >=20 > Neither am I... my guess has been that the lighting switch occurs on=20 > certain state transitions, but only under certain (timing or > whatever) conditions. >=20 >=20 >=20 >> Interesting you got multiple colour schemes, here it is strictly >> limited to only 2. >=20 >=20 > Maybe we're not using the same version? 4.14 here. That's probably the reason, I'm using 4.05 (from suse 8.1). A quick glance over the code shows the new version uses for instance more=20 complex lighting... Roland |
From: Roland S. <rsc...@hi...> - 2004-01-13 16:13:22
|
Michel D=C3=A4nzer wrote: > BTW, I still get flickering in lightlab when enabling the object > specular colour, maybe it takes some more tweaking of the state atom > emit order, Andreas? :) I don't think this one is related. Seems to be more like some overflow=20 problem, if the object shininess is slightly increased (from 0 to at=20 least 3) the problem is gone. It also happens with R200_NO_TCL=3D1 and=20 even LIBGL_ALWAYS_INDIRECT=3D1 (though the flickering seems to be slightl= y=20 different, if I'd have to guess I'd say the precision of the calculation=20 is different). Roland |
From: Felix <fx...@gm...> - 2004-01-14 00:48:28
|
On Tue, 13 Jan 2004 21:12:53 +0100 Roland Scheidegger <rsc...@hi...> wrote: > Michel D=E4nzer wrote: > > On Tue, 2004-01-13 at 14:51, Felix K=FChling wrote:=20 > >=20 > >>On Tue, 13 Jan 2004 14:38:37 +0100 > >>Michel D=E4nzer <mi...@da...> wrote: > >> > >> > >>>On Mon, 2004-01-12 at 17:44, Michel D=E4nzer wrote: > >>> > >>>>There are still minor problems, e.g. in the xscreensaver endgame hack= ,=20 > >>>>but those might be related to colour material (known to horribly brea= k=20 > >>>>trackballs, e.g.). > >>> > >>>The funny thing about the problem in endgame is that it's much less > >>>severe if run as > >>> > >>>R200_DEBUG=3Dstate /usr/lib/xscreensaver/endgame 2>/dev/null > >>> > >>>as opposed to just > >>> > >>>/usr/lib/xscreensaver/endgame > >> > >>A timing problem?=20 > >=20 > >=20 > > Apparently... >=20 > Sure this is about timing? > What I see in endgame is this: > Every few seconds, the colors change from orange/brown to=20 > orange-brown/grey. Compared to R200_NO_TCL (or software mesa) both of=20 > these color sets are wrong (should be orange/grey if mesa is correct). > Apart from that, I couldn't see other errors (with a 9000pro). > Maybe not all necessary state is submitted? The funny thing is, that I'm seeing the same on Radeon (r100). It took me a while to realize that this was the behaviour you were describing ;-). I always thought the changing colors were intentional. It makes sense since the color depends on whose move it is. But with TCL disabled and with indirect rendering the colors don't change. I also tried this on my ProSavage and it looks the same as with software TCL and indirect rendering. Maybe taking a look at the endgame source code would shed some light on this? >=20 > Roland >=20 ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Michel <mi...@da...> - 2004-01-14 02:12:40
|
On Wed, 2004-01-14 at 01:47, Felix Kühling wrote: > > The funny thing is, that I'm seeing the same on Radeon (r100). It took > me a while to realize that this was the behaviour you were describing > ;-). I always thought the changing colors were intentional. So I used to think. :) > It makes sense since the color depends on whose move it is. But with > TCL disabled and with indirect rendering the colors don't change. I > also tried this on my ProSavage and it looks the same as with software > TCL and indirect rendering. Maybe taking a look at the endgame source code would shed > some light on this? I've been looking around it and even changing some things to see the effect, but no trace so far. I may well have missed something though, I'd appreciate if you took a look as well. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2004-01-14 16:31:19
|
Michel Dänzer wrote: > On Wed, 2004-01-14 at 11:33, Keith Whitwell wrote: > >>What's going on here - is there something the hw can't handle? >> >>+ if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) { >>+ /* Can't do even constant attenuation, disable */ >>+ icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift); > > > The refernce driver does this; excuse my ignorance, but maybe constant > attenuation of 1.0 is the same as no attenuation? Yes, that makes sense. Reading the comment not the code. The patch looks good - I'm happy to see it committed. Keith |
From: Michel <mi...@da...> - 2004-01-19 01:06:23
|
On Wed, 2004-01-14 at 17:31, Keith Whitwell wrote: > > The patch looks good - I'm happy to see it committed. Thank you. I noticed that the R100 driver handles attenuation (or at least tries to? :) in Lightfv(), so http://penguinppc.org/~daenzer/DRI/r200-attenuation-2.diff might be better? BTW, what's the test l->EyePosition[3] == 0.0 for? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Felix <fx...@gm...> - 2004-01-14 22:39:01
|
On Wed, 14 Jan 2004 03:12:37 +0100 Michel D=E4nzer <mi...@da...> wrote: > On Wed, 2004-01-14 at 01:47, Felix K=FChling wrote: > >=20 > > The funny thing is, that I'm seeing the same on Radeon (r100). It took > > me a while to realize that this was the behaviour you were describing > > ;-). I always thought the changing colors were intentional.=20 >=20 > So I used to think. :) >=20 > > It makes sense since the color depends on whose move it is. But with=20 > > TCL disabled and with indirect rendering the colors don't change. I=20 > > also tried this on my ProSavage and it looks the same as with software= =20 > > TCL and indirect rendering. Maybe taking a look at the endgame source c= ode would shed > > some light on this? >=20 > I've been looking around it and even changing some things to see the > effect, but no trace so far. I may well have missed something though, > I'd appreciate if you took a look as well. The version I tested was 4.05. I can't find the old sources so I'm downloading the 4.14 sources now. I just tested a 4.14 endgame binary. With TCL it looks like there is only a little ambient light, diffuse (and specular?) lights aren't working. The reflections of figures in every second square look like they are lighted correctly, though. Colors don't change AFAICT. Without TCL it looks correct. Is this what you're seeing on r200 too? Does someone have older xscreensaver sources? >=20 >=20 > --=20 > Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer > Software libre enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Michel <mi...@da...> - 2004-01-15 00:02:53
|
On Wed, 2004-01-14 at 23:38, Felix Kühling wrote: > On Wed, 14 Jan 2004 03:12:37 +0100 > Michel Dänzer <mi...@da...> wrote: > > > On Wed, 2004-01-14 at 01:47, Felix Kühling wrote: > > > > > > It makes sense since the color depends on whose move it is. I used to think so, but I noticed that's not quite true. The lighting switches when a move starts or ends, but the colour doesn't always correspond to the moving piece. > The version I tested was 4.05. I can't find the old sources so I'm > downloading the 4.14 sources now. > > I just tested a 4.14 endgame binary. With TCL it looks like there is > only a little ambient light, diffuse (and specular?) lights aren't > working. The reflections of figures in every second square look like > they are lighted correctly, though. Colors don't change AFAICT. > > Without TCL it looks correct. > > Is this what you're seeing on r200 too? I think so, except that the lighting changes here (do you also see different colour schemes on different runs, BTW?). E.g. it starts like http://penguinppc.org/~daenzer/DRI/endgame1.jpeg and then switches to http://penguinppc.org/~daenzer/DRI/endgame1.jpeg and back and forth. > Does someone have older xscreensaver sources? If nothing else, snapshot.debian.net should be useful, e.g. http://snapshot.debian.net/archive/2002/08/01/debian/pool/main/x/xscreensaver/ -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Felix <fx...@gm...> - 2004-01-16 00:59:18
|
I took a look at the endgame source from xscreensaver 4.05. I believe the changing color is related to the color of the last chess piece drawn in the display function. I noticed that after the first two moves or so the board is lit correctly only if a grey piece is moving. The moving piece is drawn last (unless there is a taken piece too). So I conclude that the last drawn piece's color must be the key. I don't have time to look into the details now, and I'd like to get started with the savage cards sometime soon. If anyone else feels like looking into it, go ahead. Regards, Felix On Thu, 15 Jan 2004 01:02:48 +0100 Michel D=E4nzer <mi...@da...> wrote: > On Wed, 2004-01-14 at 23:38, Felix K=FChling wrote: > > On Wed, 14 Jan 2004 03:12:37 +0100 > > Michel D=E4nzer <mi...@da...> wrote: > >=20 > > > On Wed, 2004-01-14 at 01:47, Felix K=FChling wrote: > > > >=20 > > > > It makes sense since the color depends on whose move it is.=20 >=20 > I used to think so, but I noticed that's not quite true. The lighting > switches when a move starts or ends, but the colour doesn't always > correspond to the moving piece. >=20 > > The version I tested was 4.05. I can't find the old sources so I'm > > downloading the 4.14 sources now. > >=20 > > I just tested a 4.14 endgame binary. With TCL it looks like there is > > only a little ambient light, diffuse (and specular?) lights aren't > > working. The reflections of figures in every second square look like > > they are lighted correctly, though. Colors don't change AFAICT. > >=20 > > Without TCL it looks correct. > >=20 > > Is this what you're seeing on r200 too? >=20 > I think so, except that the lighting changes here (do you also see > different colour schemes on different runs, BTW?). E.g. it starts like >=20 > http://penguinppc.org/~daenzer/DRI/endgame1.jpeg >=20 > and then switches to >=20 > http://penguinppc.org/~daenzer/DRI/endgame1.jpeg >=20 > and back and forth. >=20 >=20 > > Does someone have older xscreensaver sources? >=20 > If nothing else, snapshot.debian.net should be useful, e.g. >=20 > http://snapshot.debian.net/archive/2002/08/01/debian/pool/main/x/xscreens= aver/ >=20 >=20 > --=20 > Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer > Software libre enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: Felix <fx...@gm...> - 2004-01-15 11:13:20
|
On Thu, 15 Jan 2004 01:02:48 +0100 Michel D=E4nzer <mi...@da...> wrote: > On Wed, 2004-01-14 at 23:38, Felix K=FChling wrote: > > On Wed, 14 Jan 2004 03:12:37 +0100 > > Michel D=E4nzer <mi...@da...> wrote: > >=20 > > > On Wed, 2004-01-14 at 01:47, Felix K=FChling wrote: > > > >=20 > > > > It makes sense since the color depends on whose move it is.=20 >=20 > I used to think so, but I noticed that's not quite true. The lighting > switches when a move starts or ends, but the colour doesn't always > correspond to the moving piece. >=20 > > The version I tested was 4.05. I can't find the old sources so I'm > > downloading the 4.14 sources now. > >=20 > > I just tested a 4.14 endgame binary. With TCL it looks like there is > > only a little ambient light, diffuse (and specular?) lights aren't > > working. The reflections of figures in every second square look like > > they are lighted correctly, though. Colors don't change AFAICT. > >=20 > > Without TCL it looks correct. > >=20 > > Is this what you're seeing on r200 too? >=20 > I think so, except that the lighting changes here (do you also see > different colour schemes on different runs, BTW?). E.g. it starts like >=20 > http://penguinppc.org/~daenzer/DRI/endgame1.jpeg >=20 > and then switches to >=20 > http://penguinppc.org/~daenzer/DRI/endgame1.jpeg >=20 > and back and forth. I've seen different color schemes without TCL. There is some kind of a fadeout and then it fades in with a new color scheme. But these schemes were more distinct than your screenshots. Also what I see is a lot darker. In your screenshots diffuse lighting looks ok. >=20 >=20 > > Does someone have older xscreensaver sources? >=20 > If nothing else, snapshot.debian.net should be useful, e.g. >=20 > http://snapshot.debian.net/archive/2002/08/01/debian/pool/main/x/xscreens= aver/ Cool. I have to remember that URL. I'll take a look at the source later tod= ay. >=20 >=20 > --=20 > Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer > Software libre enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |