residualvm/residualvm — pull request #1111 by chkr-private (2014-10-20 19:17:09+00:00)
Title: RFC: Generic handling of floating point rounding issues

I have split the original PR #1108 into two PRs. The actual bug fixes for the lava puzzle and the generic handling of the floating point problems.

### Generic floating point issues
* in floating point, some operations are valid (like x / 0.0f) but have an unexpected outcome (+/- inf for x!= 0 or NaN for x = 0.0f)
* these special values are propagated undetected through all calculations and may lead to strange effects (like the invisible boats)
* due to the nature of the limited accuracy of floating point operations, some calculations are critical:
* arcus cosinus/sinus if variable is outside of -1.0 ... 1.0
* e.g. the operand of arcCosine is sometimes just a little bit above 1.0:

Angle::arcCosine(dotProduct(v1, v2) / (v1.getMagnitude() * v2.getMagnitude()));

* even the mathematically valid formula like the one above may produce results which are just a little bit off due to float's accuracy and so they would cause effectively acosf() to generate NaN
* division by zero: can cause +/-inf or NaN
* probably others like sqrt() of the operand is smaller than 0.0f
* in order to track down these issues I have enabled the reporting of floating point exceptions when project is not compiled with --enable-release
* for the revealed exceptions I did the following:
* added asserts in the low-level math classes when undefined values are calculated or when the objects are created with undefined or non-meaningful values (like a line with no direction or a segment where the start and end point are equal)
* fixed this kind of usage in the higher-level objects (e.g. in Grim::Actor)

### Open items
* Is that approach helpful at all?
* Enable the reporting of floating point exceptions in all 3 games and play some more scenes in order to detect other areas where the inaccuracies of floating point operations could cause some trouble.