Fixed-point game calculations are ugly and inflexible

[tmewett]

The fixed-point code is ugly, error-prone and difficult to modify; it uses hard-coded look-up tables.

It may be possible to revert to using floating-point and improve its portability. There are some fp compiler options in GCC like -fexcess-precision=standard, and some targets accept -mieee or -mieee-fp to improve portability of fp calculations. The problem is that C doesn't guarantee its fp representations conform to IEEE 754.

Alternatively the fixed-point could be cleaned up, possibly with code generation.

[tmewett]

Assuming we can convince the compiler to conform to IEEE, the only way I can currently see out-of-sync errors occuring is due to accumulated errors when modifying floats. For example, if non-recorded inputs somehow temporarily modify floating-point state variables, by say adding and then taking away a value, then the result may be slightly different to the original. But this would require careful inspection of the code.

[tmewett]

It may be possible to instead implement a reasonable fixed-point pow function. There is a technique where you expand the fractional part of the exponent as a sum of negative powers of 2, (i.e. 1/2 + 1/4 + 1/8 + ...) and use square roots to compute the result. However this would be slower than both lookup tables and floating point.

[tmewett]

A fixed-point pow was added in 2e7a8a0. Rewriting the lookup tables with this function will make things a lot tidier.

[tmewett]

Closing this as the tools are available to remedy it; things will be refactored as needed.