What about doubles instead of floats?

That may help, but it probably only kicks the can down the road a little further.

The fundamental problem you are facing is the way that floating point formats -- essentially a base-two form of scientific notation -- encode their magnitude. They're designed to represent very small measures with very high precision, and very large numbers with very low precision. If you're measuring the width of a human hair, you obviously need to be very precise, but if you're measuring the distance between planets, what's a few hundred kilometers error here and there? In fact, there's as many divisable units in a floating-point format between 0 and 1 as there are between 1 and the largest re presentable number. Unlike integral or fixed-point arithmetic, the divisible units are not equally-sized -- the space between them increases the further you get from 0.

In a space game I was involved with some time ago, there were similar problems -- planets in this game were actually held in their orbits by the gravity of their local sun, all based on physics. use of a single floating-point coordinate system would cause enough precision error in further-away solar systems that the physics would fall apart and planets would fall out of orbits that they should have maintained. The problem was solved by having multiple coordinate systems -- One that was used to describe the location solar systems themselves, and one local space for every solar system -- basically the suns/stars were in the 'universal' coordinate system, and each sun/star was also the center of its own local coordinate system.

Fixed-point could serve as the basis for a single universal coordinate system with uniform precision, but the trouble is that you need an awful lot of bits to represent the number of centimeters between here and Proxima Centauri.

Finally, bare in mind that when you work with floating-point, the scale you choose to work at has a great effect on precision over the range of values you encounter. Simply changing 1.0 to mean 1 kilometer instead of 1 meter would have a noticable impact on how the precision errors are manifested (though, I'm not proposing that this simple change would fix your problems).

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.

This is exactly the approach used in all previous versions of SIMTrek / SIMSpace. as you say it works just fine.

now the _int64 makes it possible to use world coordinate systems of light years and decimeters and cover the size of about 3 galaxies. this allows huge game worlds with high precision, and little muss and fuss about multiple coordinate systems, sector/quadrant stuff etc. just a simple "draw whats around the camera, relative to the camera" approach to things, with a little LOD thrown in. SIMSpace 8 will be the 6th title i've done with a game world so large it required world coordinates. and at last, i almost have data types big enough to store the positions etc without a lot of hassle.

The problem was solved by having multiple coordinate systems -- One that was used to describe the location solar systems themselves, and one local space for every solar system -- basically the suns/stars were in the 'universal' coordinate system, and each sun/star was also the center of its own local coordinate system.

this is the precise method used by previous versions of SIMTrek / SIMSpace.