[AD] About the fixed type (continued)

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


After thinking a little more about the issues at stake, here are the
conclusions I came to:

    1. The float vs double problem
Using float means a loss of precision. We could say "never mind" if the
conversion was only used when passing from the floating point world to the
integer world. Unfortunately in include/allegro/inline/fmaths.inl we read:

    #ifdef ALLEGRO_NO_ASM

    AL_INLINE(fixed, fixmul, (fixed x, fixed y),
    {
       return ftofix(fixtof(x) * fixtof(y));
    })

    AL_INLINE(fixed, fixdiv, (fixed x, fixed y),
    {
       if (y == 0) {
          *allegro_errno = ERANGE;
          return (x < 0) ? -0x7FFFFFFF : 0x7FFFFFFF;
       }
       else
          return ftofix(fixtof(x) / fixtof(y));
    })

    #endif

Here is an example:
    x = 3fffffe0
    y = 10000
    asm: x*y = 3fffffe0
    C double: x*y = 3fffffe0
    C float: x*y = 40000000

As I think we can't afford to lose any bit of precision when staying within
the fixed type, using 'double' is unavoidable.


    2. The radian vs 256-ranged angles problem
I'm currently writing a new test program for the Windows port that uses
sprites and rotates them. Hence the need for the fixed type. I have to do
some calculations involving dividing lengths on an arc by the radius, thus
resulting in radians.

So I need radian<->256-ranged angles conversion within the fixed type (as
Laurence originally proposed). However I would like to combine the
conversion with other multiplicative operations. Therefore I think we should
only provide the multiplicator (and maybe its inverse) instead of any
functions.

Thoughts ?

- Eric




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/