Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Handling floating point precision  (Read 1023 times)

0 Members and 1 Guest are viewing this topic.

Tobberoth

  • Guest
Handling floating point precision
« on: September 30, 2013, 10:44:11 pm »
This is something I'm sure a lot of people have run into: the floats in a vector2f get rounding issues making bugs appear. My personal issue was that collision detection broke in certain situations where a shapes Position fields got rounding point errors (something standing on the ground was 3.051758E-05 pixels into the ground).

While the obvious fix is to add something like math.round() to every situation you use the fields, is there some more standard way of doing it which doesn't fill your code with boilerplate? I don't generally work with floats in programming, so I'm not really used to dealing with the issue.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Handling floating point precision
« Reply #1 on: September 30, 2013, 11:03:37 pm »
How does 3.051758E-05 instead of 0 break your collision detection?
Laurent Gomila - SFML developer

Tobberoth

  • Guest
Re: Handling floating point precision
« Reply #2 on: September 30, 2013, 11:10:30 pm »
How does 3.051758E-05 instead of 0 break your collision detection?
I first move objects in the X axis and check for collision (and fix their position if there's overlap), then do it in the Y axis. Which means that if the position is moved, there should be no overlap. Because of the rounding errors, there's still an overlap, so for example, there could be a collision on the X axis, the position is fixed but because of a rounding error there's still a minuscule overlap, which then potentially breaks the Y axis fix.

EDIT: I've fixed it now by rounding the Position down to two decimals after every collision, which seems to work well enough. Still wondering if anyone knows of any best practice or similar to minimize the risk of such issues.. These problems are of course quite hard to debug so it would be nice to know if there's some standard way of dealing with it.
« Last Edit: September 30, 2013, 11:32:04 pm by Tobberoth »

 

anything