# About floating point precision and why do we still use it

Floating point has always been troublesome for precision on large worlds.

This article explains behind-the-scenes and offers the obvious alternative - fixed point numbers. Some facts are really impressive, like:

"Well 64 bits of precision gets you to the furthest distance of Pluto from the Sun (7.4 billion km) with sub-micrometer precision. "

Well sub-micrometer precision is more than any fps needs (for positions and even velocities), and it would enable you to build really big worlds.

My question is, why do we still use floating point if fixed point has such advantages? Most rendering APIs and physics libraries use floating point (and suffer it's disadvantages, so developers need to get around them).

Are they so much slower?

Additionally, how do you think scalable planetary engines like outerra or infinity handle the large scale? Do they use fixed point for positions or do they have some space dividing algorithm?

• The last "additionally" bit should probably be a separate question so the main one doesn't get sidetracked. – Tetrad Aug 30 '10 at 8:24
• I want to figure how to force fixed point... My game has all sorts of strange errors because Lua uses the FPU, and DirectX fiddles with FPU too... I've saw things like 2*9000 = 17995 or 500*10 = 4897 it is really silly. But the worst error probably is one that is discussed in Ogre3D forums, where 1+5 = 4. – speeder Aug 30 '10 at 23:28
• Didn't justify a comment; but if you do decide to use fixed point Q-Floats ( en.wikipedia.org/wiki/Q_(number_format) ) are your friend; they are ridiculously fast and easy to implement. – Jonathan Dickinson Aug 31 '10 at 13:41
• So, to sum up ¿should I stick with floating points (if I'm working in Java or Python)? – Gastón 26 mins ago – Gastón Dec 8 '10 at 0:11

If you will allow me a shameless plug, I'll give you an example from a real game I'm working on (YouTube video link).

The game has an infinite, procedurally generated world on a physics engine. It uses single-precision floating point. After a few hundred meters of game space, precision issues start to arise (and get progressively worse the further from the origin you get).

My solution? Every 200m or so I move the entire world back by 200m towards the origin (if you care to find and try one of the prototypes on my site, and bring up the [w]orld debug overlay, you can see this happen).

Why not use fixed point? Or double precision? Instead of single-precision? Because everything else is using single precision floating point!

The physics engine I'm using uses it, XNA uses it, the data that gets loaded onto the graphics card is formatted as single-precision floating point. Even the language itself is designed to work with floating point numbers -- writing and (more importantly) reading 0.5f is far easier than 0x80000000L.

It's simply a matter of what is easier in practice. And the clear winner is being aware of floating point precision issues and writing fairly simple "move-the-world-back-to-zero" functions (or implementing space partitioning or whatever suits your game).

And finally another example - Orbiter is game (simulation, really) that really needs to care about precision. Not just in space but also in time (time acceleration plus orbiting bodies - don't want them to fall out of the sky, now). It also uses floating point numbers and employs a hack to maintain stability.

• I always wondered if it might be easier for some applications to move everything else and keep the "player" at the origin. Interesting to see I'm not the only one! – dash-tom-bang Aug 30 '10 at 16:23
• I like your reasoning. I would just like to point out that when it comes to games that involve networking fixed point seems to have less quirks/deviations (client prediction is more accurate). – Jonathan Dickinson Aug 31 '10 at 13:37
• I don't understand your argument very well. And by the way why haven't languages implemented fixed point yet ? Of course that seems to be a reason to be drawn to use floats, but that doesn't explain why fixed point has not been implemented everywhere. – jokoon Oct 2 '10 at 18:13
• @jokoon I thought my answer was quite clear. As to why fixed point isn't implemented everywhere? Just look to Wikipedia: "Very few computer languages include built-in support for fixed point values, because for most applications, binary or decimal floating-point representations are usually simpler to use and accurate enough." A good designer knows what to omit - and something that duplicates functionality in a way that makes it really easy for a programmer to shoot themselves in the foot is a good candidate. – Andrew Russell Oct 3 '10 at 3:47
• Agreed. Today's processors execute floating point instructions very easily, the instructions have excellent throughput and most are only a few cycles longer latency than integer instructions. – doug65536 Feb 6 '13 at 1:57

First - yes, they are significantly faster. Even if you can get fixed point working as fast as a "normal" FPU, real floating point has advantageous instructions like fsel to stop branching, or SIMD to work on many floats at once. GPUs also use floating point, at least in their user-facing interfaces.

Secondly, 64 bits gets you pretty far in floating point as well - most people still use 32, but the primary advantage is that it scales. That fixed point scale has a fixed accuracy. Whether you're measuring the sun to Pluto, or across the street, you get the same precision. Floating point will give you much more accurate results when all values involved are smaller. Since generic physics libraries are expected to work at least passably with lots of games at different scales - and some games themselves may have vastly different scales - they need to use a kind of number that works at many scales.

Another important point to make is that floats aren't so inaccurate as people here seems to think. A 32-bit float has 24-bits of full integer precision. This means that it is at least as accurate as a 24-bit fixed point value for any given range. While floats get less accurate the larger the value becomes, a fixed point value will simply overflow and wrap around at some point. Reducing accuracy is a better fallback. Floats may also overflow, but far, far later. I would like to see your faces when your world suddenly wraps around to -2^31 due to fixed point overflow.

64-bit floating point values have 53-bits of integer precision, so they are really accurate.

• Floating point values don't actually overflow; if the result of a computation is too large in magnitude to be represented then the result is positive or negative Infinity. – Pineapple Nov 16 '18 at 17:57

In an FPS context, fixed-point values might actually be a liability. Close to zero floating-point is more accurate. It is only over large distances fixed-point becomes more preferable. The answer is simply that its dependent on context.

In something like a galaxy you can use frames of reference. Use a huge scale for the solar systems and then use the center of the Sun (or similar point) as the point of origin for anything inside the system. Using this system you can have your cake and eat it, so to speak, and its not difficult to envision.

IIRC, the dev on Infinity stated that he was continuously iterating around scale issues in one of his interviews.

• It is unlikely that in any game you would need the "close to zero" precision of floating point. If you have a one meter unit, 10 bits of precision gives you sub-millimeter accuracy and still lets you model over 4000km in each direction if you're stuck with 32 bit values. If you need more precision than a millimeter then you can shift a few more bits, for sure. Moving to 64 bit values in a space game would give you a solar system (or more?) with constant precision throughout the entire volume. – dash-tom-bang Aug 30 '10 at 16:27
• Indeed. And that's why you'd use a solar system's Sun as a point of reference in a galaxy-sized world! The point is, your chosen method of handling precision doesn't bring anything to the table either way. It's moot, so you might as well use the one your library/hardware is attuned to. – Rushyo Aug 31 '10 at 12:32
• Incidentally, I worked on a game where we had to model over 4000km in each direction. For compatibility with code in other projects, it had to use 32 bits for positions. It's not a theoretical problem, given the commercial demands placed on code reuse and the size of game worlds today. – user744 Aug 31 '10 at 18:26

If you didn't yet, you should definitively check out the Planet Rendering tutorial on GameDev.net. As for space division, one solution is to keep two separate position variables -- one macro scale and one micro scale. This works quite well (tested).

The exact solution depends on how do you plan to handle extreme distances in the engine -- do you plan jump gates, or time compression?

One of the reasons is that floating point arithmetic is "good enough" (or at least it has been), it produces fairly accurate results quickly.

As long as you are aware of the limitations of floating point arithmetic and change your algorithms to cope with them (see Andrew Russell's answer) then you'll produce code that "works".

I am writing a game. In my game/program, I draw a spaceship at the origin using a fairly fixed camera and my planet I draw using a separate camera. And these two things take care of the issue for me, but my planet isn't very detailed yet. As for the solution Andrew Russell mentioned about moving the world ( and i'm assuming the camera and its inhabitants back toward the origin ) I really wouldn't try that if you ever plan on making the game a networked game. If you moved the world on the server application based on each clients movements then the world would end up struggling for a position. And would take its position all the time from everyone playing which would be a huge glitch.