# Are games with large worlds compiled with fp:/fast?

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

## Recommended Posts

I actually have a couple of very specific questions.

1) In general, nowadays are games compiled with fp:/fast or with fp:/precise flags turned on?

2) And what about games with large worlds, that usually have to deal with floating accuracy issues due to long distances from the camera: in those cases, the usual tricks like floating-origin and using doubles for calculating changes in transforms before reconverting back to float are used together with fp:/fast or even with them fp:/is needed?

##### Share on other sites

Why 64bit integer / fixed point and not just double. What does this buy you?

Yeah fair enough on just using doubles when they solve your problems :)
As for the "why int?" thing though:
Floats/double's have the property of extreme precision near zero (your world's origin), which seems like a very silly thing to want in a world representation format.

If you need millimeter precision and work in metres as your units, then floats let you have objects up to about 4km from the origin in a particular axis.
On the other hand, 32-bit fixed point lets you have objects over 2000km from the origin in a particular axis. So for the same fixed precision target, fixed point gives you much better range.

Going to doubles will also solve the issue for any planet-sized game world -- doubles let you have objects over 1AU (over 100 million km) from the origin while maintaining millimeter precision, so, yeah that does seem easier than a hierarchical position format with a floating/local origin...
On the point of fixed-point vs floating-point though -- a 64-bit int will let objects be over approx 1 lightyear from the origin while maintaining millimeter precision, so it's still way better than double :D

For a space game world that's larger than a few light-years but requires extreme precision at any location in the world, a hierarchical format would be a requirement -- so sure, for anything smaller than that, "just use double" will work just fine.

##### Share on other sites

caveman 3.0

fp fast

2500x2500 mile game world, divided into map squares 5 miles across.

locations are given by integer map square coords (mx,mz), and floating point coords in that map sq (x,z).  x and z are limited to 0.0f to 26400.0f

##### Share on other sites

so sure, for anything smaller than that, "just use double" will work just fine

This is for precision. But what about quickness ? I highly suppose that CPUs can still compute 32-bits floating point calculations faster than with 64-bits floating points. Even on 64-bits architectures. Am I wrong ?

Also, as far as I remember, floats ruled on the GPU some years ago. Do you think that nowadays GPUs can operate on 64-bits float as fast as 32-bits floats ?

##### Share on other sites

so sure, for anything smaller than that, "just use double" will work just fine

This is for precision. But what about quickness ? I highly suppose that CPUs can still compute 32-bits floating point calculations faster than with 64-bits floating points. Even on 64-bits architectures. Am I wrong ?

Also, as far as I remember, floats ruled on the GPU some years ago. Do you think that nowadays GPUs can operate on 64-bits float as fast as 32-bits floats ?

On GPU, double is possible these days but is a big no-no for performance reasons. IIRC on some GPU's it's 4x slower than float.

On x86, double and float are the same speed with fp:/fast (as the FPU internally uses 80-bit floating point) and float is actually slower with fp:/strict (not accounting for memory bandwidth -- in bandwidth-bottlenecked situations, float is twice as fast as double)!

On x64, double and float are the same speed... unless your code is vectorizable (SIMD-able, SSE/AVX...), in which case float can be twice as fast.

##### Share on other sites

so sure, for anything smaller than that, "just use double" will work just fine

This is for precision. But what about quickness ? I highly suppose that CPUs can still compute 32-bits floating point calculations faster than with 64-bits floating points. Even on 64-bits architectures. Am I wrong ?

Also, as far as I remember, floats ruled on the GPU some years ago. Do you think that nowadays GPUs can operate on 64-bits float as fast as 32-bits floats ?

On GPU, double is possible these days but is a big no-no for performance reasons. IIRC on some GPU's it's 4x slower than float.

On x86, double and float are the same speed with fp:/fast (as the FPU internally uses 80-bit floating point) and float is actually slower with fp:/strict (not accounting for memory bandwidth -- in bandwidth-bottlenecked situations, float is twice as fast as double)!

On x64, double and float are the same speed... unless your code is vectorizable (SIMD-able, SSE/AVX...), in which case float can be twice as fast.

Thank you a lot. So these things did not improve that much on the GPU side since the years 2000...

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 11
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633722
• Total Posts
3013540
×