On Tue, 1 Feb 2005 21:00:22 +0100, Lourens Veen <[EMAIL PROTECTED]> wrote: > On Tuesday 01 February 2005 19:55, Timothy Miller wrote: > > Another thing that I'm going to change is that the X values are going to > > be fixed-point. It won't hurt anything (on the contrary!), and it'll > > make the logic lots simpler. Additionally, it makes it easier to round > > 0.5 down. It's still more logic but not horribly bad. > > *bumps in, hello!* > > I'm not exactly an OpenGL expert, but I figure I'll just throw this in. If I > understand correctly, everything gets transformed from world space into > camera space, and then from camera space into screen space, right? > > What if you adjusted that final transformation (which would be in the driver, > correct?) to map the coordinates to (-0.00001, -0.0001)-(maxX-0.00001, > maxY-0.00001). (Obviously, you would use the smallest value you can represent > in your fixed point format for a bias instead of 0.00001). You have to do the > transformation anyway, and modifying the matrix slightly is a small constant > time operation, so that won't hurt. Then the hardware could simply round 0.5 > up, since it would actually be the value that is just above 0.5. And 0.5 > would become the value just below 0.5. > > No extra hardware, a few extra cycles per frame in the driver. Good tradeoff? > Did I miss something?
If you're talking about coordinate systems and the fact that OpenGL puts pixel centers at 0.5, then yes, what you suggest would work for screen coordinates. However, this breaks down for texture coordinates with MIP mapping. Therefore, in the spirit of consistency, I decided to just do it all the same everywhere. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
