Fixed point

spark,
I wouldnt bother about him, he''s probably just some l33t programmer who tries to hack people by giving out Visual Baasic scripts and therefore thinks he''s a programmer.

Plus, any programmer knows that using fixed point is faster, ever tried to find out how many clock ticks a multiple takes up ? try that with a binary shift oh yeah matey, it''s definitely faster, what a looser

kosh

Changing something that is inherently floating point into fixed-point, processing it, and changing it back, is not gonna be quicker in general than operating in native floating-point all the way. You should look into the way modern chips work, with numerous pipelines and so much parallelism (especially for floating point, I believe) that simple comparisons of clock-cycle counts become almost meaningless. (If a single operation takes 60 cycles and runs totally parallel to the rest of your code, it is quicker than a similar operation that interrupts your main code flow for 4 cycles.)

Of course, using floats where fixed point will do may incur a performance hit at times. And using bitshifts can be faster than multiplies, but you may lose more than you gain when you have to convert it back to a float...

I believe the original poster (why is this on a new thread anyway?) was trying to say "don''t go to lots of trouble converting floats to fixed-point just because a load of old tutorials suggested it was faster". The benefits today are not nearly as apparent, except in a few uncommon situations, and -certainly- moving to fixed point within the confines of a 3rd party 3D api such as OpenGL or Direct3D is likely to gain you nothing and lose you programming time.

yeah, also, you cannot have 0.x of a pixel, it''s either 0 or 1, so fixed point is really all you need, everything is shifted left up by a number that you require for precision, then do your maths, then shift right your precision to get an integer value for the number, easy

quote:

---

Original post by Kosh

yeah, also, you cannot have 0.x of a pixel, it''s either 0 or 1, so fixed point is really all you need

---

There''s still little point shifting your integer, performing the calculation, shifting back to the ''real'' value, then converting to float at the end. (Which you will likely have to do because the 3D APIs all use some floating-point type.) You also lose some of your precision - if you are forever shifting everything 5 bits (for example), your 32-bit or 16-bit type is suddenly only 27 or 11 bits in accuracy. Whereas a 16-bit float has a very wide range of possible values.

If you want to keep working in DOS, with only 486 instructions, and with no hardware support, I''m sure you will see a significant benefit to fixed-point arithmetic. However, with a 3D card, with associated hardware acceleration, with a CPU supporting multiple pipelines and advanced floating-point code... I doubt it''s worth the effort except in -very- specialized situations. Even if you find a speed increase by comparing SomeLoopWithFixedPoint compared to SomeLoopWithFloatingPoint, if you then come to adding more code into that loop, the initial speed benefit might be eroded and perhaps lost entirely due to the way processors can do often several things at once.

Someone with more knowledge on pipelines and parallelism and FPUs care to comment here?

I would only add that floating point math on pretty much every processor these days is as fast if not faster than integer math. Plus IEEE floating point is a nicely aligned, word sized (on most processors) data format. There''s simply no reason for fixed point any more unless you''re dealing with some kind of hardware specific application (D3D, Glide and OpenGL do _not_ count

On the x86 family of processors, at least, floating point is still slower that integer arithmetic. Most likely this will never change, especially if binary compatability is to be maintained.

However, the gap is decreasing. Including the shift ops necessary, fixed point addition/subtraction is still faster, but fixed point multiplication is about the same speed. Potentially a software only renderer in fixed point is still faster by a smidgen. Especially when considering that the software renderer has to change everything back down to integers eventually to get pixel coordinates.

Of course, the APIs I like to use require arguments in floating points. Once the conversion time to floating point is added in, its faster to do things in pure floating point. Not to mention less headaches.

quote:

---

Original post by SiCrane

Of course, the APIs I like to use require arguments in floating points. Once the conversion time to floating point is added in, its faster to do things in pure floating point. Not to mention less headaches.

---

Yeah, exactly. Whereas 45 * 5446 may always be marginally faster than 45.1 * 5446.1, the old idea of converting floats to ints, doing the heavy-duty arithmetic there, then converting back to floats, is now probably losing you processor time and is also likely costing you programmer time (far more important in my opinion! )

"Please leave fixed point math back in 1994 where it belongs."