Maybe I did wake at the wrong side today.

But this code doesn't work so well right now:

double fPI = 3.141592653589793;
fix fDeltaV = ftofix(fPI);

textprintf_ex(sBuffer, font, 10, 10, makecol(255, 100, 200),-1, "fDeltaV=%f", fixtof(fDeltaV));

The problem is that the output is 0.141586.

Is my computer condemned or not? Or is it my brain?

EDIT: never mind.
Odd. But why are you using fixed point math? Is it really necessary?

I always use int for storing fixes. Try int fDeltaV = ftofix(fPI);
0.141586 looks like just the bottom 16 bits to me.

Second possibility (pure guess time), try defining fPI as float rather than double. ftofix() is a macro on some platforms and may be doing funky bitshifting stuff with an IEEE float, so C's autocasting of doubles to floats will be bypassed.

I think your problem is that you're mixing up "fix" and "fixed". "fix" is a C++ class that handles conversion automatically. "fixed" is a typedef to long. Try either this:

double fPI = 3.141592653589793;
fixed fDeltaV = ftofix(fPI);

textprintf_ex(sBuffer, font, 10, 10, makecol(255, 100, 200),-1, "fDeltaV=%f", fixtof(fDeltaV));

or this

double fPI = 3.141592653589793;
fix fDeltaV = fPI;

textprintf_ex(sBuffer, font, 10, 10, makecol(255, 100, 200),-1, "fDeltaV=%f", (double)fDeltaV);

edit: I probably didn't explain that well. "fix" is C++ only, and attempts to be clever. "fixed" is plain C, requires the use of macros, and goes bonkers if you make a mistake. You convert a floating point number to a "fixed", and assign the result to a "fix".
The process goes like:
fPi: (double) = 3.141592653589793

ftofix(fPI): (fixed) = (long int)(3.141592653589793 * 65536) = 205887
(precision loss, but number semi-intact)

fDeltaV: (fix) = ((long int)(205887 * 65536)) / 65536 = 608108544 / 65536.0 = 9279.0
(now in weird format, overflow occurs, integer portion of number dropped)

fixtof(fDeltaV): (double) = ((long int)9279.0) / 65536.0 = 0.1415863037109375
(number is converted back to sane format, but the information lost can't be recovered)

This is from the allegro manual:

Unfortunately the only advantage of fixed point math routines is that you don't require a floating point coprocessor to use them. This was great in the time period of i386 and i486 machines, but stopped being so useful with the coming of the Pentium class of processors. From Pentium onwards, CPUs have increased their strength in floating point operations, equaling or even surpassing integer math performance.

by the way is "fixed" not "fix"

Thanks for the nice replies! I'm been working quite much this week, so I will feel sorry if I don't remember so good, but what of I remember it seems that the fixed type is now obsolete. Because I got some type off error message when declaring fixed. Anyway, I'll check it tonight when I come home and reports back.

Anyway, for the time now I'm using the float-type for some of my variables. Though I'm a little unsure of what is best to use right now. I've some calculations with the cos, sin functions etc.. What do you think is the best and safest way to calculate this? Should I use the fixed funcions (i.e. fixcos()), or should I use the old math.h -library, or something else?

/Johannes, with a dangerous and secret project going on

Keep everything in floating point and use the regular C library trig functions. Saves you trouble, is just as fast and makes for much cleaner code.

I agree with gnolam on that one. The only problem is that Allegro requires a few things in fixed point format (sprite rotations IIRC), but aside from that fixed point is rarely worth the hassle on modern CPUs.

This is assuming you intend to run your game on a modern cpu.

AllegroDS is almost working