Fixed point questions

[Obg1]

How can fixed point math be used?
Does the engine is fully deterministic when using it?
How is the performance of the fixed point math?
Will it better to use look up tables for the trig functions like sin, cos, etc?

[ninnghazad]

You can compile using PLAYRHO_REAL_TYPE. I think the included fixed types are Fixed32 and Fixed64.
But you will probably not want to do that. It makes PlayRho more deterministic in a way, but comes at a high cost in CPU time.
The real question is why do you need that determinism?
There may be better ways to deal with the problem you want to solve by using fixed math.

[louis-langholtz]

Hello Obg1. Thank you for asking your questions!

As @ninnghazad said, you can use the CMake PLAYRHO_REAL_TYPE variable to choose to use alternatives like Fixed32 or Fixed64. One can also directly edit the PlayRho/Common/Real.hpp file to set the Real type alias to the type of your choosing.

I suspect that by deterministic, you mean consistent numerical calculations across different hardware platforms. Is that what you mean? If so, given that Fixed32 and Fixed64 are implemented more in software (than float or double), I believe Fixed32 and Fixed64 would - by design at least - provide results that were more consistent across platforms. An alternative use of the term relates to randomness and there should be no randomness introduced into calculations by any of this library.

Note that cross platform consistency of Fixed32 and Fixed64 has not been verified and they are currently meant more to be unit test like mock types than to be production ready types.

As for the performance of the current fixed point library implementation of Fixed32 and `Fixed64, anecdotal testing of them have shown them to be disappointing. I suspect there's lots of opportunity for improvements and for other implementations to be faster, more accurate, and more reliable.

Whether it would be better to use lookup tables for the trig functions for these fixed point types is unknown to me. I suspect that lookup tables are generally less of a performance win with newer hardware than they used to be.

Hope this helps!

[Obg1]

First, thanks for the quick response. By determinism I want to get the exact simulation results, no matter the platform.
This also requires no use of threads and no use of random, so no std::sort, but instead std::stable_sort for example.
The reason for this is for developing p2p games (Without a server), and sending only the game inputs in the network, while both peers are running the same simulation based on those inputs.
I've actually found a git repo for it on Box2d and it works well (with a little fix). I'm wondering if the same can be added to your engine in the same manner.

Here's the repo for reference:
https://github.com/91Act/box2d_fixed

They use a nice fixed point math with LUT for the trig functions.

[ninnghazad]

do remember that in a case like that indeterminable behavior may arise from sources outside the physics engine - such as :

• dropped input packages that fail to get resent or arrive too late (lockstep?)
• not using the exactly same set of bodies between simulations (in the same order, with exactly the same values (which might come from floating point ops outside of physics))
• any floating point operations outside of physics that are used to set physics values (like player input, ai, events and so on)
• frameskips
• cheating
  ...

even for p2p you most probably want to be able to detect a desync and be able resync worldstate, at least in parts - no matter how deterministic your stuff is.
a quick and dirty way could be to compare player positions and amount of bodies between peers and use that as an indicator of desync.

as for LUTs... i also think probably not worth it - in my experience most stuff like this is memory-bound long before it becomes cpu-bound.

that being said i think you can use PlayRho in that way - well i actually tried it - but in client/server setup. because in my case the simulations would not have the same bodies in the same order, so there was little benefit but nono high cpu costs.

as a tip: if you go that way quantize player inputs before using them in any way - for example by converting them to fixed right away.

[louis-langholtz]

Thanks for the confirmation about what you meant by determinism. Thanks also for providing the repo for reference.

I took a quick look at the fixed point implementation you referenced. Found it very interesting to review! It appears to also have chosen to use 64-bit integers and 128-bit arithmetic. I'd love to see some in-depth bench-marking of it and comparisons against known correct data. Same with the implementation I'd whipped up.

I'd guess that in a side by side comparison, the LUT approach would prove more accurate for direct entry hits but slower over bigger simulations than the non-LUT approach used in the fixed point implementation I did. At least by design that seems more likely to me.

Incidentally, I'd love to see a well tested/verified fixed point implementation get tested out with PlayRho. As long as it supports constexpr and floating point concepts like infinity, it should work.

Possibly the biggest speed impediment however to using fixed point math would be the need for using 64-bit integers and support for 128-bit arithmetic to provide enough fidelity and the memory throughput overhead that has over 32-bit floats. I've tried using 32-bit integers with 64-bit arithmetic and it has too limited fidelity to prove stable in general usage. Just switching from using float to double I've seen have a performance hit that seems to be around 25-30% for simulations like the pyramid.