Re: [AD] float math function inconsistencies

[SiegeLord <slabode@xxxxxxxxxx>]

On 01/29/2013 07:16 PM, Nick Trout wrote:
> Chipmunk: on iOS it uses CGPoint, which is 2D float. It is double by
> default on other platforms, but can be switched easily to float. And
> notice how all of the math functions pair with the number type.

I don't think there's any argument against using the f suffixed 
functions given that we use floats almost everywhere. Whenever I wrote 
code I always took pains to use the f suffixed functions, so it's not 
like their usage will be unprecedented. You should send along a patch to 
fix this, perhaps ;). Double check that the functions are available 
under MSVC, however. It was missing a few last time I checked.

The float->double change is an issue unrelated to this, however. The 
usage of doubles for the software triangle rasterizer is unfortunate, 
but doesn't really argue for using doubles everywhere. The proper 
solution would likely be to convert the entire thing to fixed point math 
(I didn't originally do so because I feared restricting the triangle 
size too much, and because I observed no speed difference between using 
floats and fixed point) because that's what is used by the hardware 
which is being mimicked anyway (and it certainly does _not_ use doubles).

The interpolated variables in the software rasterizer are only u,v and 
the color components, all of which coincidentally range between 0 and 1, 
which would allow using all 32 bits of an integer to encode fractions, 
which is ahead of the 24 bits available to float, but less than 53 bits 
available to double. I suspect that it will be enough though. Heck the 
scaline drawers use the Allegro fixed point which affords only 16 bits 
to the fraction, and nobody's complaining about precision there!

It's not a big deal though, as until there is a non-hardware accelerated 
display driver available there's relatively small pressure for this 
rasterizer to be fast.

-SL