Author Topic: GetGlobalBounds() arithmetic error (Read 2738 times)

N1ghtly · « **on:** January 25, 2012, 09:34:57 pm »

Hey all, I recently updated to the latest snapshot and converted my code to use the new GetGlobalBounds method. However: it broke my collision code. I narrowed the problem down to arithmetic precision. I set the sprite for example at pos (20, 252).
When I subsequently call GetGlobalBounds, it becomes (20, 252.000004).

So when I call rect1.intersects(rect2) it will claim they intersect (by a suuuuuper small margin) while they shouldn't.

Anyone else has this error?

Laurent · « **Reply #1 on:** January 25, 2012, 11:00:23 pm »

Quote

When I subsequently call GetGlobalBounds, it becomes (20, 252.000004).

Can you try to find exactly which operation adds this small error on the result?

N1ghtly · « **Reply #2 on:** January 25, 2012, 11:06:53 pm »

That would be sprite.Move

Laurent · « **Reply #3 on:** January 26, 2012, 08:00:31 am »

And before, with Sprite::GetSize(), the result was always correct?

N1ghtly · « **Reply #4 on:** January 26, 2012, 12:09:01 pm »

Laurent · « **Reply #5 on:** January 26, 2012, 01:51:46 pm »

This is the kind of problems that happen with floats. You should rather add a small epsilon to your collision tests rather than relying on SFML to provide exact values anyway.

N1ghtly · « **Reply #6 on:** January 26, 2012, 02:22:24 pm »

What do you mean by a small epsilon?
And I just don't understand why this suddenly stopped working ^^

Laurent · « **Reply #7 on:** January 26, 2012, 04:48:13 pm »

Quote

What do you mean by a small epsilon?

Instead of testing a < b (for example), test a < b +/- e, with "e" a very small value which represents the error margin.

Quote

And I just don't understand why this suddenly stopped working

The implementation has changed, things are computed differently.