|
Speed Performance using either float or fixed |
Kevin Epps
Member #5,856
May 2005
|
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 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? |
ReyBrujo
Moderator
January 2001
|
It depends on the calculations, but in older processors fixed may be a good alternative. -- |
Kevin Epps
Member #5,856
May 2005
|
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? |
ReyBrujo
Moderator
January 2001
|
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. -- |
Steve Terry
Member #1,989
March 2002
|
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. ___________________________________ |
Audric
Member #907
January 2001
|
Kevin Ebbs said: masked_blit(src, dest, 0, 0, fixtoi(ftofix(x)), fixtoi(ftofix(y)), src->w, src->h);Is the the best way to implement this?
Why not simply : |
Kevin Epps
Member #5,856
May 2005
|
Quote: 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. |
Jonny Cook
Member #4,055
November 2003
|
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. The face of a child can say it all, especially the mouth part of the face. |
Kevin Epps
Member #5,856
May 2005
|
[edit] Well, that's pretty much what I do for the angle calcs. 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? |
Carrus85
Member #2,633
August 2002
|
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: 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.
|
Kevin Epps
Member #5,856
May 2005
|
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. |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
Goalie Ca
Member #2,579
July 2002
|
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! ------------- |
Kevin Epps
Member #5,856
May 2005
|
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. |
Kitty Cat
Member #2,815
October 2002
|
Quote: Would someone remind me why people have been using fixed point anymore. 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;
-- |
Audric
Member #907
January 2001
|
I posted the performance I get in the other thread. Switching from ints to fix to floats could make this time (1% to 10%) double or halve, and nothing more. IMO, you should edit: Goalie Ca said: Would someone remind me why people have been using fixed point anymore Link by ReyBrujo in another thread: Problems with floating-points |
Kevin Epps
Member #5,856
May 2005
|
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. |
Steve++
Member #1,816
January 2002
|
Quote: 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. 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. |
Audric
Member #907
January 2001
|
one random article about profiling |
|