On Fri, Oct 11, 2002 at 06:00:18PM +0100, Keith Whitwell wrote: > Felix Kühling wrote: > >On 11 Oct 2002 18:15:08 +0200 > >Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > > > >>I was looking into the lighting issues Felix reported with the > >>xscreensaver pulsar hack (when running it with the -light option). One > >>side of the planes looks good, the other one is black, so I thought it > >>might be related to two-sided primitives. > >> > >>Indeed, the hardware TCL code has a fallback for this if the material is > >>different on both sides. If I hardcode that to always trigger (in > >>check_twoside_fallback() in radeon_state.c), pulsar looks good with > >>lighting. > > > I think this is effectively the same as setting 'R200_NO_TCL=t'. > > >>So I thought I'd see if this was related to some lighting oddities in > >>bzflag, and I made another interesting discovery: with this fallback, it > >>locks up the chip when connecting to a server, like I reported before > >>for software TCL. > >> > >>In summary, there seem to be multiple problems related to two-sided > >>lighting in the radeon driver, both with hardware and software TCL. I'll > >>keep looking into them, but I hope this information will help someone > >>else find them more quickly. > >> > > > >One observation which confused me was that it looked good if I set the > >alpha channel of global ambient to something other than 1.0 (or was it > >0.0?) > > Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with > R200_NO_VTXFMT=t ? > Any chance this might be similar to the FlightGear lighting problems me and a few other people have been seeing for ages? RADEON_NO_TCL 'fixed' that, but RADON_NO_VTXFMT made no difference . . .
Simon (hoping for a solution to this, finally . . .) -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
msg06962/pgp00000.pgp
Description: PGP signature
