On Wednesday 09 February 2005 00:31, Timothy Miller wrote: > On Tue, 8 Feb 2005 23:48:08 +0100, Lourens Veen > > > > > Question. I seem to recall that you were going to use fixed-point for the > > coordinates. The current version of the model, with real float25s, gives > > some ERROR messages when rendering the antialiased line. As far as I can > > tell, the problem is that dX1dY and dX2dY just don't have enough > > precision. If these are converted to fixed-point then there probably > > won't be a problem, but if they stay float25 then there definitely is. Or > > maybe we should just use a different algorithm for antialiased lines > > altogether... > > Are you sure it's a lack of precision? I've gotten lots of those > messages when I just didn't program things right. How are you > generating rasterizer parameters?
I haven't changed anything. What I did was I built a float25 class, wrestled with C++ until the operator overloading worked correctly :-), then integrated it in the model so that everything that you specified as float25 is now actually float25. Then John fixed the make system that I'd bodged to get it to compile, and now everything is C++ and 25 bits float. Everything else is still the same. So to answer your question: in the same way you are, whatever that is :-). I guess I need to take a closer look at the model and really understand what's going on there. > > Incidentally, would a generic "fixed" class be useful to have for the > > model? I'm thinking of something that would allow > > To some extent. The model should evolve to more closely resemble the > hardware. Some discussion needs to happen with regard to what > precision is necessary for each fragment attribute AFTER perspective > divide. At that point, it's predictable, and we don't lose precision. > > > fixed a(11, 5); // 11.5 fixed point > > fixed b(0, 8); // 0.8 fixed point > > > > and so on. It could include cast operators for casting to int and float, > > and operators would automatically do any required shifting. > > Excellent! Okay, I'll probably give it a swing tonight. I have another project that needs finishing and although it's much less fun than this, it needs to be done. > > Actually, we should probably have an unsigned fixed as well then. > > > > If this is implemented then it should probably be followed by a > > walkthrough through the model to decide what is which type and to fix it > > all up and make it clear what is what. The current implementation is > > quite sloppy with types. > > Yeah, I thought about them somewhat, but I was trying to make it > conceptually correct first. Makes sense. 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)
