bonkmaykr
@bonkmaykr@canithesis.org
43 following 25 followers
On the other hand, the visible playfield in TF is no greater than 360x640, the signed 16-bit integer limit is 32k. Accuracy on the PC should not noticeably suffer, we have a resolution of 0.00153% and can increase it more if we tighten the world boundaries closer to the center.
So I'm considering converting world simulation to use 16.16 fixed point math. But with the option to compile as floating point and with different precision levels, for future games if the engine is reused. Done using a typedef within a header file that swaps the precision using the compiler definitions.
The problem is fixed point performance. All drop-in fixed-point replacements for floating-point numbers are slow, not by a significant margin on today's hardware, but absolutely significant on any CPU old enough to not have an FPU. Thus kind of defeating the point. It wouldn't be good enough to run on a 68020 or 030 and would hurt performance on the 68040+, unless those builds are compiled with FPU support which creates incompatible demo files. I don't know, I guess I'll have to experiment.
I have my eyes on https://github.com/MikeLankamp/fpm/ but will need some time to make a final decision.
If I do end up having to make both an FPU and fixed-point version of the engine, as a worst case scenario, then the demo record will need to contain some flags about the settings the engine was built with when recording the game session.