Re: [AD] float math function inconsistencies

[allefant <info@xxxxxxxxxx>]

It depends. In most cases the compiler knows how to deal with
constants. For example it produces the exact same code for sinf(1.0)
and sinf(1.0f).

On Wed, Jan 30, 2013 at 11:47 AM, Nick Trout <chinbillybilbo@xxxxxxxxxx> wrote:
> Strictly speaking all floating point literals need an "f" on the end as
> well. I haven't checked but I believe all of these will generate a double,
> which then needs converting to float before they are used (every time they
> are used).
>
>
> On 30 January 2013 09:10, Nick Trout <chinbillybilbo@xxxxxxxxxx> wrote:
>>
>> There is a patch attached to the original email. I haven't checked
>> Windows, but as far as I can remember I only used functions that are already
>> used elsewhere.
>>
>>
>> On 30 January 2013 02:22, SiegeLord <slabode@xxxxxxxxxx> wrote:
>>>
>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_jan
>>> --
>>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers