On Saturday 29 January 2005 18:05, Timothy Miller wrote: > On Sat, 29 Jan 2005 13:28:51 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > > We can't get away without a full software fallback anyway. e.g. because the > > hardware won't support projective textures, and probably for the more > > exotic OpenGL modes like feedback. This is not that big a deal because we > > can just use Mesa for that. So how are 3D and 2D any different, again? > > This is problematic. For instance, the chip does W-buffering, while > Mesa probably does Z-buffering. We'd have to rewrite parts of Mesa in > order to be able to fall back on it and still have it WORK.
Well, don't say you haven't been warned because this is not the first time this has come up. The fact is, *all* 3D APIs expose their depth buffer. OpenGL (and Direct3D) specify a Z-buffer. Applications can read this Z-buffer - for example using glReadBuffer, but there are probably less straightforward ways to do it. So we *MUST* be able to produce compliant Z values. There's simply no way around it. And once we're able to produce compliant Z values, we can just use Mesa for software rendering. I'm curious what the rationale for the current design was, because I honestly don't remember. There is one interpolant less than with a Z buffer. Was there anything else? cu, Nicolai
pgplyM5DiPldr.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
