Fixed Point support

[ValorZard]

RENDERED

in response to this

[ValorZard]

Added future plans for better idea where this is going

[bjorn3]

How would compatibility between plugins that don't opt into fixed-point bevy and games that do opt in worl? Currently floating points are directly exposed, so switching to fixed-point violates the additive nature of cargo feature flags by causing compilation errors when trying to set tranaformations to floating-poimt numbers.

[ValorZard]

Honestly, it should be completely fine for plugins to not opt into fixed point bevy. As some people on the discord said, its a rare enough feature that its okay to not support every usecase for it. I'm perfectly fine with fixed point being a second class citizen in the bevy ecosystem as long as its supported.

[Frizi]

I think that on the argument of portability, we have a strong alternative here. Namely, make sure our floating point code is portable across all supported platforms. The biggest problem with that are usually trigonometric functions and some sort of fast math optimization. I think we don't do the latter already.

This could be tested by unit tests that compare operation results with exact bit patterns, and ensure that it's the same bit pattern across all tested platforms.

[maniwani]

(Edit: I've reversed my opinion.)

Namely, make sure our floating point code is portable across all supported platforms.

I agree with this now. Bevy could take cues from Dimforge and provide a config option to force libm usage for deterministic impl of the transcendental functions. The main question is how much performance do those lose compared to hardware intrinsics.

Q48.16 fixed-point can be competitive with floating-point perf, but the range and precision limits will make re-implementing physics, animations, etc. very challenging.

Other sources of non-determinism (mainly command queue processing order) also need to be addressed.

[ValorZard]

I'm closing this because

1. I don't think this is a very good RFC. The quality of it is EXTREMELY poor compared to the other rfcs currently in queue.
2. I've lost interest in getting this feature implemented. The work required for this to exist, plus the amount of people who would actually want to use it, is incredibly small.

If someone disagrees, and does want Fixed Point support implemented, I suggest they make a much better RFC than this.