I assumed operators were done in some convulted way and worked like an inline function, but I''m wrong then I''m definitely on a bad track.

But say I make em inline methods?

The majority opinion here seems to be that it''s not worth the trouble, and I personally have a Spider Sense tingling that it might not be such a hot idea...

Your spidey sense is correct. If your target platform is Pentium or better, use floating point. Just make sure you aren''t converting back and forth from int to float and float to int a lot, this will kill you. I have a friend who is writing a 2D RPG (his first game, very ambitious) but he does a lot of float/int int/float conversions. It is killing his frame rate. It runs crappy. Really the only float to int conversion you should need to do is in the rendering code, when you blit your graphics.

Inline methods would work in theory, but the problem is that a number of compilers (MSVC for instance) take the ''inline'' keyword as merely a suggestion. So you may or may not end up with call stack and branch overhead. If you really want to use fixed point, throw together a few macros and put them inside a namespace.
Honestly though, I''m not trying to sound like a hardass, but I''ve been programming for well over a decade, been professionally involved in the game industry for about six years now, and the only reason I''d ever consider using fixed point math is if for some strange reason I ended up developing for GBA or PocketPC or something. Don''t get me wrong, it has its place, we use 1.15 fixed point in development in order to cut down on CD space footprint, and convert it to floating point while loading the games. However, there''s absolutely no reason why you should use it to actually do math calculations unless you want them to run about five to ten times slower depending on the processor and the compiler.

-goltrpoat


--
Float like a butterfly, bite like a crocodile.

quote:

---

Original post by Anonymous Poster
whole_part will contain -10. When you do a >> operation, this is compiled into an arithmetic shift right, which preserves signs (the MSB stays the same).

---

*feels dumb*
Didn''t know it automatically used ASR. I think I wrote an ASM version using shr to test the speed, and it was a tiny bit faster so I used it. Then later I did something that got its sign messed up, so I switched it to SAR instead, and assumed the compiler would''ve done what I did before^^


I did a speed test to see if fixed is really faster, and it outperformed float on everything but division when using small numbers, but with large ones, float stayed the same, and fixed lost a little speed, making them almost even, but float just a little ahead. Plus, int division is indeed incredibly slow. multiplication/addition/subtraction were all going about 50 fps (float and fixed), float division went about 33, and int division was 17.
Sorry for pushing something I hadn''t even confirmed to be better. Use floats, they''re faster and more accurate^^ And I''ll see if it''d be reasonable to convert mine to use them too, since I''m also going for maximum speed on current hardware (non-3D accelerated hardware, that is).

I''m developing for GBA too though, so fixed does still have its place. It''s just not with the x86 anymore.

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Ah, just remembered to test comparisons of numbers, and it turns out ints are faster. About 10 fps with floats, and 14 with ints. Since I don''t use many divisions, and do use tons of comparisons, I don''t know which one would be faster. I suppose I''ll stick with fixed for now, since it would be a lot of trouble to convert it, and might even be slower than it is now. I''ll do it if anyone has actually tried both and confirmed that float is faster though.

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Heya,

Since division is far more slow than multiplication (read in this tread), would the following be an remarkable optimization?

For example 2D Polygon interpolation:

dy = y2-y1;dxu= (u2-u1) / dy;dxv= (v2-v1) / dy;dxr= (r2-r1) / dy;dxg= (g2-g1) / dy;dxb= (b2-b1) / dy; 

Would changing this into the following help??

dy = 1/(y2-y1);dxu= (u2-u1) * dy;dxv= (v2-v1) * dy;dxr= (r2-r1) * dy;dxg= (g2-g1) * dy;dxb= (b2-b1) * dy; 

Gr,
BoRReL

I am not sure on how much that improves, but it was what I do. If I have several divisions by the same number I do the exact same thing.

Possibility

Multiplying by the reciprocal of a value rather than dividing by the value is a common technique I''ve seen in several books, and yields better results in many cases. As with any optimisation though, you should profile it to be sure.

quote:

---

Original post by goltrpoat
If you really want to use fixed point, throw together a few macros and put them inside a namespace.

---

Macros do not respect namespaces:

namespace Foo{#define DUMMY_VAR 10};int main (){ return DUMMY_VAR;}

Compiles & runs.

I did my own test of integer math vs float math.

Keep in mind, I have an older CPU (AMD K6 333).

I wrote a little program that pregenerated like 8000 random integers and floats. I then performed various ops on these numbers, 32 million of each op per type. I don''t have the hard results here (at work) but integer ops always worked about 10-20 faster than float ops. Naturally, additions faster than multiplies and multiplies faster than divides.

I also learned that a single bitshift is about 10-20 percent faster than a single multiply (duh), but a single multiply is about 10-20 faster than two shifts and and add (surprised me).

So, I already knew it is faster to do this:

y<<10 

than this:

y*1024 

Now I know it is faster to do this:

y * 640 

than this:

(y<<9) + (y<<7) 

Anyway, for the time being, I am going to stick with fixed point maths, at least for 2D work. For 3D work, I''m sure floating point will work out faster.