On Tuesday 15 February 2005 23:47, Daniel Phillips wrote: > On Tuesday 15 February 2005 15:57, Lourens Veen wrote: > > On Tuesday 15 February 2005 18:48, Timothy Miller wrote: > > > Has anyone figured out exactly how much precision we actually NEED? > > > > Don't think so... I'll volunteer Daniel to modify a few lines in the > > software model and make a precision torture test :-). Then I'll patch > > the float25 class to include a random precision reciprocal, and we > > can render some pictures and compare. > > At this point I'm fretting more about DDA precision than the perspective > divide. I seriously doubt we'll get stable results stepping across the > whole screen with 16 bit precision. I'm mulling over a couple of > suggestions, short of adding more bits.
Hmm. What's the maximum resolution we're shooting for anyway? I think Timothy mentioned the maximum analog bandwidth the card would generate some time ago, and as I recall I didn't quite understand. My Iiyama VM 454 does 1920x1440 at 72 Hz with the Radeon VE that is currently in that machine, and I'd like it to do that again with this card. The monitor does 130 kHz horizontal, but I also remember a 300 MHz figure. At any rate, could we assume a maximum of 2048x1536 for the resolution? That means 11 bits for integer screen coordinates, so we'd have an 11.5 split if we did fixed point (and floating point just doesn't make sense to me here really, comments?). That means that if the span is larger than 32 pixels, we get in trouble. In fact, we'd need 11.11 probably to get it perfectly right. Which means 22 bits adders :-(. So we need other solutions. Something Bresenham-like, storing the dIdX value as a rational number, and what if we drew the span from both sides to cut the error in half (ie, we do two pixels at a time, but not next to one another, but one starting at the left side of the span and the other on the right side)? Just some thoughts. Incidentally, these differentials are calculated on the host, not the card, right? > The way to model the target precision is with some nasty masking on the > floats, as opposed to hooking in the full approximation, so the model > will still run pretty fast. We do need the option to simulate the > exact operations, but for sanity's sake it should be an option. I'll > make a patch if nobody beats me to it. Well, it's pretty much trivial to do it for the current float25 class. Just modify the currently hardcoded 0x40 and ~0x7F to the appropriate values. It would probably be nice to have a generic init() method that lets you specify the precision, and also calls initrecptables(). > Lourens, it's definitely cool what you're doing to save those two > multipliers. I'll continue developing my straightforward version > because it's, well, straightforward, and it's a good cross check. Thanks, and yes, please do. It's good to have something to compare against. Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
