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,
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
On Thu, 2004-01-15 at 12:10, Felix KÃhling wrote:
> >
> > 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.
>
> I've seen different color schemes withou
On Thu, 15 Jan 2004 01:02:48 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-01-14 at 23:38, Felix Kühling wrote:
> > On Wed, 14 Jan 2004 03:12:37 +0100
> > Michel Dänzer <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2004-01-14 at 01:47, Felix Kühling wrote:
> > > >
> > > > It makes
On Wed, 2004-01-14 at 23:38, Felix KÃhling wrote:
> On Wed, 14 Jan 2004 03:12:37 +0100
> Michel DÃnzer <[EMAIL PROTECTED]> 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 tha
On Wed, 14 Jan 2004 03:12:37 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> 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 alway
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] &=
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
Michel DÃnzer wrote:
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 differenc
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 doe
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 se
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 differen
On Tue, 13 Jan 2004 21:12:53 +0100
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>On Mon, 2004-01-12 at 17:44, Michel
Michel DÃnzer wrote:
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
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
> o
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
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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
On Tue, 2004-01-13 at 14:51, Felix KÃhling wrote:
> On Tue, 13 Jan 2004 14:38:37 +0100
> Michel DÃnzer <[EMAIL PROTECTED]> 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 r
Michel DÃnzer 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
problem, if the object shininess is slightly inc
On Tue, 13 Jan 2004 14:38:37 +0100
Michel Dänzer <[EMAIL PROTECTED]> 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
> > trackball
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 i
Michel DÃnzer wrote:
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
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!
Michel DÃnzer wrote:
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://pengu
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/
26 matches
Mail list logo
