HomeWildfire Games

Add fixed-point sin/cos, to fix OOS errors


Add fixed-point sin/cos, to fix OOS errors


philipJul 4 2010, 7:15 PM
rP7689: Use more precision in debug serialization, to help debugging of OOS errors

Event Timeline

wraitii raised a concern with this commit.May 1 2019, 3:27 PM
wraitii added a subscriber: wraitii.

The precision is insufficient. Because of this, the obstruction squares have (u,v) vectors which aren't correct (not properly normalised and just plain incorrect), which down the line results in incoherences between PathGoal::RectContainsGoal and PathGoal::NavcellRectContainsGoal (among others I guess).
I've noticed this while trying to understand why D1835 sometimes returns different results from svn in cases where it ought not to.

We need a precise-enough™ version of this code to make sure these incoherences are removed. I'll update the tests later.

This commit now has outstanding concerns.May 1 2019, 3:27 PM
echotangoecho added a subscriber: echotangoecho.EditedMay 1 2019, 4:45 PM

An idea: why don't we rewrite the fixed types to wrap a floating-point number and code all functions modifying this number (like addition, multiplication, sin, cos, etc...) in assembly using the SSE(2) instruction set? All our target platforms should (currently) support SSE2 and we could probably provide software fallbacks for non x86 architectures if we where to ever support them. SSE should be fully specified and thus deterministic across processors, as far as I'm aware (and NEON on ARM may even be (mostly) consistent with it). Using assembly functions would ensure that the exact order of execution will be the same across compilers.

Stan added a subscriber: Stan.EditedMay 1 2019, 4:47 PM

IIRC Raspbian has a 0ad package, so even unwillingly we support ARM. I believe I remember someone talking about making it run on a RISC-V architecture. There is also a patch for ppc

Yeah. Well. It seems that we could probably get it to be consistent across all these platforms, but it wouldn't solve this problem. And I doubt it would be worth the effort after reading a bit. Some links:

wraitii accepted this commit.EditedMay 2 2019, 9:59 PM

Er, while the sinus approximation could be improved, it would probably require a lookup table and won't be perfect as our fixed points have limited precision.

Anyways, my problem isn't actually with this code in this instance, but rather with PathGoal's geometry functions, I'll just update D1829.

All concerns with this commit have now been addressed.May 2 2019, 9:59 PM