On Thu, 27 Jan 2005 18:17:11 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Thursday 27 January 2005 07:50, Timothy Miller wrote: > > Quick note regarding aliased lines: It's not exactly bresenham, but > > the vertical rasterizer can be programmed to generate the same set of > > points with the same efficiency. That's why there's a "swap_xy" flag > > in there to support x-major lines. > > Hi Timothy > > There is no magic advantage for Bresenham vs a fixed point line > iterator, I only used the term because "aliased line" didn't occur to > me. With a fixed point line iterator you need a divide per line, but > the iterator logic is simpler, is that correct? Based on my > pathetically limited knowledge of hardware logic, I guess the fixed > point iterator is a slightly better approach.
They're about the same, although the fixed-point version requires more setup overhead. Again: Not really optimized for 2D but still fast. :) > What eventually happened to the DRAM row addressing question, was it > decided to address the RAM in rectangles? This looks like a big win > for small triangles as well as lines. It would be nice to have an addressing scheme that is "universal", meaning that the logic for the screen is the same as for a texture. The trouble is that they have different widths, making tiled addressing not really tiled addressing. We can probably do something similar just by rearranging address bits. > And where did the divide implementation end up? Based on a little web > research, it looks to me that Newton-Raphson is the way to go. A 512 > entry lookup plus one iteration gets 18 bits precision. Unfortunately, > it's completely beyond me to estimate the logic propagation delay. We decided on a reciprocal lookup table and multiplies. This, we can pipeline at full speed. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
