On Tue, 1 Feb 2005 01:18:17 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Monday 31 January 2005 09:48, Timothy Miller wrote: > > > In case (1) a nice optimization would be to do the perspective > > > divide only every second pixel and linearly interpolate for the > > > other. This adds more logic, but it could conceivably be a way to > > > get to a 4x pixel unit design within the limited supply of > > > multipliers. > > > > I've thought about things like that. I'm not sure what effect it > > would have on the image quality. > > It's barely noticeable but only suitable for GL_FASTEST mode anyway. > Quake and Quake II used 16 pixel interpolated spans. You can see > slight distortion artifacts if you know what to look for (granted, the > whole image is noisy and dark which tends to cover things up). > > With this interpolation, pixel pairs should be aligned modulo 2 to the > screen pixels, that is, not relative to the polygon edge, otherwise a > slight ripple effect appears on polygons clipped against the left edge.
The problem here is that I think it might take more hardware to interpolate between columns. I'm not sure. Maybe what we could do is compute even columns and then average the numbers (a relatively easy thing to do) to get the odd columns. The one exception to deal with is when the left-most or right-most is odd, so we'd have to compute extras around them. This might work out well. Once perspective divide has been done, I can justifiably switch to fixed-point for pretty much everything (and get as-good or better results than using float). This makes interpolation really easy. > > This is a nice technique in software, but maybe in hardware it doesn't > save anything unless you can dynamically reassign the saved multipliers > to other functions, yet more work. On the other hand, somebody > determined enough and with enough time on their hands might be able to > squeeze four pixels per clock out of the card this way, subject to > memory limitations you mentioned. Not that I can really see why you'd > need 800 Megapix/Sec except perhaps for full screen antialiasing, which > is likely out of reach anyway. Can't reassign multipliers. Everything gets hard-wired. The only exception is when you use something in a loop, but the logic is still hard-wired to that one circuit. > Thanks for the answers on the dual pixel pipeline, it sounds ideal. No problem. The questions you ask are important, because there's always something the rest of us may have overlooked. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
