I know that there were some threads regarding this, but I just want clarification:

I have the following machines that I test on (all Windows so far):

P4 XP 2.8GHZ 256MB Nvidia Gfx card
Celeron 2000 1.1GHZ 4MB ATI GFX card
Celeron 2000 1.1GHZ 128MB ATI GFX card

All angle and position calculation uses floats.

On the P4, everything is fine. FPS 60 Runs smoothly.

On the other machines, runs slower, like 25 - 30 FPS. Was running at least 45 FPS until I changed all of the angle and position values to floats, which works well for me, a lot better than fixed. On slower machines under a P4, do I HAVE to use fixed to get a better performance?

It depends on the calculations, but in older processors fixed may be a good alternative.

ok.

So let's say I have the following code:

This is basically how I'm calculating the positioning. Is the the best way to impletment this?

Also, Let's say that I wanted something to move at speed = 5.5, how is declaring speed as a "fixed" type going to help me with that? Use (int)fixtof(speed)+0.5 or something?

I believe ftofix is a slow function, you should calculate everything using fixed points, or just determine your program needs a big processor to run. You would create a constant, like const fixed constant_speed = ftofix(5.5);, that way you would calculate it only once.

Your example code isn't efficient, you are using floats, casting to fixed, then casting to int, that's slow no matter how you look at it.

Why not simply :
masked_blit(src, dest, 0, 0, (int)x, (int)y, src->w, src->h);

Ooops! I put in code from my old code. Sorry about. Yeah that above masked_blit in the quote is actually what I use.

In the Allegro tests folder, there's a program called test.exe (at least for me). Check out "Time some stuff" in the Misc menu. As the name suggests, it times a bunch of stuff, including fixed point math and floating point math. Check it out on different computers. On my computer, (AthlonXP 2200), floating point arithmetic is faster than fixed pointer arithmetic, but the fixed point trig functions are much faster than the floating point ones. This probably is due to lookup tables.

What you could always do is store all the angles and position and everything else as floats, and when you need to do some speed critical trig stuff, just convert them to fixed point numbers.

[edit]
Oh yeah, thanks for the tip about the test exe's.
[/edit]

Well, that's pretty much what I do for the angle calcs.

y = length * fixtof(fixsin(ftofix(angle)));
x = length * fixtof(fixcos(ftofix(angle)));

But what about for movement calc's like using velocity to move a sprite?

if (x_vel < speed) 
  x_vel+=0.1;

x += x_vel;

Do i need to change any of these to fixed while doing this type of calc? Or is the pretty much the best I can do when it comes to this?

y = length * fixtof(fixsin(ftofix(angle)));
x = length * fixtof(fixcos(ftofix(angle)));

Hmm, call me naive or whathaveyou, but that seems, at best, to be a bad idea. You are converting float->fix, doing trig, then converting fix->float. float->fix and fix->float are slow operations (there is no native conversion operation for fixed point numbers, AFAIK).

I would be very surprised that, if on modern hardware, that is any faster than this:

y = length * sin(angle);
x = length * cos(angle);

Yes, I know fixed point trig utilizes lookup tables, but I doubt the speed gain from lookup tables is going to outweight the speed loss from fix-float or float-fix conversion.

Well,

I know that certain calls are don't really matter for modern machines, but a lot of people may not have modern machines and I know quite a few people that don't. So, I would like to make sure that my game can run on machines below P4 as well.

I have a 1.1GHz machine and use floating point just fine. The thing to keep in mind when using floats is to use floats. Don't go converting them to and from int or fixed or anything like that unless absolutely necessary. There may be a few things you can do to convert to int and be faster (eg. a sine lookup table for slower machines), but these will generally amount to a few FPS at most (and as a side effect, lose a few FPS for most newer machines).

If you need to convert to int/fixed alot (for say, Allegro functions) it may be better to use fixed. Fixed is also nice when doing bit-wise operations. Allegro's 3d math functions, though, have both fixed point and floating point variations.

Would someone remind me why people have been using fixed point anymore. i686 handles floats just fine. Newer CPU's handle them better than fine, they handle them damn fast!

Well,

I just posted a demo of my game in the depot forum to see how it runs on the majority's computers. If everyone is able to run it at 60 FPS, then I'll just assume that mostly everyone has modern computers that can handle float and continue. If not, then I'll have to rewrite some code as fixed. Hopefully, it's not the latter.

Accuracy, for one. You'll always have 16 bits reserved for sub-integer precision. No more, no less. Makes it easier for checking and comparing. Plus it's rather fast for converting to int, so it's very useful for tight speed sensitive loops. And, you can do this:

// Set range 0..256 (inclusive-exclusive)
fixedNum &= 0xFFFFFF;

I posted the performance I get in the other thread.
From what I saw, there's like 20 objects moving onscreen, not rotated, and moving in straight lines... The screen however seems to be in 800x600 or something, hi color, drawing rather big things (like earth).
Your logic step should take like 1% CPU on almost anybody's computer. even on a 386 sx25, there's no way it can reach 10% - except if you've coded in some super-inefficient way : but then, it will still be only 10%

Switching from ints to fix to floats could make this time (1% to 10%) double or halve, and nothing more.

IMO, you should
1) profile. My guess can be wrong
2) focus on optimizing what takes 90% time. not what takes 10% time.

edit:

Link by ReyBrujo in another thread: Problems with floating-points

Hey Audric

I had answered your question on the depot thread:

this is my game loop code:

Question about Profiling, though. In the results where should I be looking to determine speed of drawing and logic, if I can do that, that is.

There's also performance loss from having to cache those lookup tables.

All CPUs from about 486 DX2/66 have an integrated floating point processor (I think it may have become part of the core at some stage). Processing floats isn't (much) more expensive than processing ints.

I would agree that the advantage of fixed is that you get guaranteed accuracy with the number itself, but when you start dealing with increasingly smaller numbers, things start getting ugly. The only time floating point accuracy is threatened is when huge numbers meet tiny numbers.

If you're using Direct3D or OpenGL, you'll need to convert to float anyway, so have a think about that.

one random article about profiling
http://www.redhat.com/magazine/012oct05/features/gcc/