Jump to content
• Advertisement

Public Group

# About fixed points

This topic is 2008 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Hello,

I'm in an optimization step for my little procedural engine.
For now, I worked with floats for a full planet coordinates. So, there was some artifacts in very high LOD, caused by float precision.
After reading a lot of threads and articles on the net, I came to think about using fixed points (fractional integer) instead of float.
I never worked with fixed points, and so, there are some (lot of) concepts I didn't understand !

Where to start using them and.. when to stop ?

1- I want to choose freely the planet's radius, let say 5629 kilometers 194 meters 29 centimeters.
Using a 16 bits whole part and 16 bits fractional part, the fixed radius number will be 368914876 (5629.19429 * 65536), right ?
But in the first place, it will be a float => 5629.19429 in the code (much readable), so I must convert it before sending it to the shader ?

2- My planet is quadtree based LOD (cube with 6 grids). Does the grids have integer coordinates ? How to scale them on the radius ?
I imagine I must choose a power of 2 radius for quadtree divisions ?

3- If the coordinates of point.x is 368914876, it's a big number in the shader (with far/near frustum, Z buffer, etc.), so what to do ? Convert it to float again ?
I must scale somewhere... ? Buf if 1 equals 1 centimeter.. It will be very very big ?!

4- In the shaders, what happens when I use the world, view, projection matrices ? Is there a moment when fixed points are no more working ?

It must be something I didn't see/understand..
Hope I was readable because it's very coufuse to me and my poor english did not help ;)

Thank you,

Chris
Edited by chrisendymion

#### Share this post

##### Share on other sites
Advertisement

Mixing numbers like that is going to be a problem when you try to convert between the two.

A float has 24 bits, or about six decimal digits of precision. Your representation has 32 significant bits, with 16 of them below the decimal point. If your first half goes above eight bits you will be unable to accurately convert between a float and back.

I'm not aware of any space game that uses real life scales for planets, stars, and other objects. Space is mind-boggling huge.

#### Share this post

##### Share on other sites

Space games often use a 64 bit integer for positions. Or even more.

Have a look for a library called vmath, (I'm working from memory here so I may be wrong. I apologise in advance if I am)

I seem to remember it used doubles for positions within a solar system them had 3 more coordinates (int's I think) for the rest of the coordinate system.

One simulator that used a similar system is Celestia.

http://sourceforge.net/projects/celestia/files/Celestia-source/1.6.1/

Hope this helps

#### Share this post

##### Share on other sites

What about doubles instead of floats?

#### Share this post

##### Share on other sites

Thank you all for your answers !

Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.

If don't need to convert back, how will work the shaders, as the numbers will be to much big...

I read, a lot of engine are using fixed points, there must be a solution..

Stainless, thank you for the links, I will read them now.

Vortez, I read that it's a bad solution to use double, I tried to get my idea about. There was too much loss of performances.

#### Share this post

##### Share on other sites

By pure hazard, I've just read a very interesting article here, maybe this could help you.

#### Share this post

##### Share on other sites

Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.
If don't need to convert back, how will work the shaders, as the numbers will be to much big...
I read, a lot of engine are using fixed points, there must be a solution..

There are many problems with it, not just conversion back and forth.

Lets say you are dealing with numbers in a region that is, just for sake of argument, all taking place around 60,000 units from the origin. That's nice that you can be there, but it means you only can go to about 0.1 units for anything before you run out of bits. Translating your models to the scale means any detail beyond 10 cm is at risk. You are guaranteed to be out of bits by the centimeter resolution, so your models are going to render like trash. Your camera's smallest step is also going to be several centimeters as you are out of bits, so don't expect anything to render well.

Or lets say a planet is 3 million units away. Your finest measure of unit will be about ten meter increments, since you have floated up to a higher magnitude. Anything less than ten meters is going to round to zero.

Then there is also the conversion problem. One has 32 significant digits, the other has 24. Your 16:16 fixed format means you will always have at least 16 bits of significant numbers, so the highest integer you can reach is 255. If your units are meters, a limit of 255 meters is not going to work out for you.

There are techniques to constantly re-center the world around the player, giving you lots of precision to work with, but it comes with significant complexity. It is one of those "if you have to ask how to do it, you probably aren't skilled enough to do it" scenarios.

It is certainly possible to have simulations with very large worlds and massive data sets. It just doesn't work well in "For Beginners". What you describe is a massive undertaking, not for someone who is just learning.

Now, fixed point all by itself, that is something you can learn. On hardware like the Nintendo DS, there were three main fixed-point numbers. There were two 16-bit formats (1.3.12 and 1.11.4 layouts), and the 32-bit 1.19.12 format. The choice on which one you used was based on the system you were using and the number of bits you need. These can be learned if you want, but if you aren't developing for fixed point hardware it is a lot of effort for little reward. Ultimately you will end up wrapping the fixed point numbers in a class, overloading all the operators, and then doing all your operations on them like you would with any other number system.

#### Share this post

##### Share on other sites

I'm not aware of any space game that uses real life scales for planets, stars, and other objects. Space is mind-boggling huge.

SIMSpace 8.0 of course! <g>

Leave it to Rockland to do the insane!

Chris:

i just finished working out the world coordinate system for SIMSpace 8.0

you might want to try using an _int64 for decimeters.

when its time to draw, pretend the camera is a 0,0,0.  so you subtract camera x,y,z from the x,y,z of all other objects, put the result in a float, then send it off to directx.

for objects past say 1 million d3d units, you do a multi-pass method. first you set your planes far, and draw everything farther than 1 million, but you draw them 1000 times smaller and closer (for example). then you reset your planes and zbuf to normal, and draw everything that's closer.

this will get you accuracy of 0.1 meters, and a range of values from about -992 to 992 quadrillion meters. the diameter of the galaxy is about 100K light years ( 946,000 quadrillion meters).

SIMSpace 8 doesn't map the entire galaxy, only a cube which is 200 quadrillion meters across.

for truly intergalactic distances, you'll want to go with something like an _int64 decimeters, and an _int64 of Quadrilion meters. conversion to float for drawing remains similar to the single _int64 case.

as frob said, space is truly huge.   a light year is 9.46 quadrillion meters.     a parsec is  3.2616 light years.   and astronomers use units of kilo parsecs and mega parsecs for measuring the most distant heavenly bodies.

approximating the galaxy as a 100 light year diameter disc 200 light years thick, and using 200 billion for the number of stars, you get an average distance between stars of 18.8 quadrillion meters in all 3 dimensions.

figuring out an appropriate world coordinate system and how to draw very distant objects is the only really unusual part of building a space sim. from then on, its more or less like any other sim, just convert everything to camera relative coordinates before drawing.

you'll also want to code up some routines to add and subtract distances if you use two _int64s or something like that.

Note that _int64 decimeters is fixed point: IE  meters with 1 digit of fixed point accuracy.

fun fact: 1 warp number apparently equals 100 times the speed of light.

Edited by Norman Barrows

#### Share this post

##### Share on other sites
space is truly huge. a light year is 9.46 quadrillion meters. a parsec is 3.2616 light years. and astronomers use units of kilo parsecs and mega parsecs for measuring the most distant heavenly bodies.

Luckily, these huge distances don't matter much.

If you look at a nearby stellar object (let's say Proxima Centauri, which is a mere 4.2 lightyears), it doesn't matter whether you measure the distance with micrometer or kilometer precision because you can't tell the difference. If you travel at "normal" speeds, then travelling for the entire duration of your life will bring you none closer to Proxima Centauri than about 4.2 light years. It is exactly the same in every respect.

On the other hand, if you have some form of "hyperdrive" (or any other fictional faster-than-light travel. wormholes or whatever) then you can reach Proxima Centauri no problem, but you still cannot tell the difference between a micrometer or a hundred thousand kilometers. There's no way you could hit the "stop starship" button fast enough to travel less than a hundred thousand kilometers, and there is nothing interesting but ... empty space... anyway. There is also no way of telling, after travelling 4.2 lightyears, whether that was really 4.2 lightyears or 4.2 lightyears, 33.7 kilometers and 20.0052 meters. Our sun is the same tiny spot when looked at from over 4 lightyears away whether or not it's a few kilometers off or not.

In other words, you can conveniently use a coarse coordinate system with a resolution of thousands (ten thousands, if you will) of kilometers to model the huge empty space between interesting things, which is convenient for modelling entire galaxies. And then again, use a different coordinate system at planet or solar-system scale (say, 64bit integers, micrometer precision) to model the "interesting stuff". Switch between them whenever you swich hyperdrive on/off.

Edited by samoth

#### Share this post

##### Share on other sites

• Advertisement
• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• Advertisement

• ### Popular Now

• 9
• 11
• 15
• 21
• 26
• Advertisement
×

## Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!