-
-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating Point Imprecision when resolving Collisions causes inexistent Collision #400
Comments
I think I'm experiencing a similar issue in my game. When I try to move my player at a diagonal against a wall, the player sometimes gets "stuck" inside. Here are some numbers for when I try to move diagonally to the right into a wall: So, the resolved x is 0.00000000000006 too far to the right and thus the player gets "stuck" inside the wall. By "stuck," I mean when I'm in this state, the player cannot move up and down (or to the right, but there's a wall there, so duh). I can move to the left, still, and get out of this state. But it seems weird and inconsistent to the player because it only happens sometimes and only on some of the walls. |
In case anyone runs into this issue, I've been using the following work-around:
It might not be the most efficient thing in the world. I wrote it a year ago. But it's just checking for the condition I described in my last comment and rounding the x/y location as-needed. I have this in my Player class overriding |
Describe the bug
During development we found an issue with floating point precision during calculating collisions and intersections when moving inside the Game's physics engine.
We wrote tests in
tests/de/gurkenlabs/litiengine/physics/CollisionResolvingTests.java
to ensure consistent movements. However, one of the tests will fail if I provide the distance constant as it is (i.e., a distance to trigger a diagonal movement of 10 units each on the X and Y axis), but it will pass if I subtract a marginal value (i.e.,1e-14
).The issue is that due to the floating point precision it miscalculates an intersection to exist where there should not be any...
There is a parameterized test which passes for the same functionality but in different directions. Most relevant would probably be the one in direction
right
which has a negated sign compared to the one with issues.Stack Trace
Failing Test Error Log
To Reproduce
Steps to reproduce the behavior:
tests/de/gurkenlabs/litiengine/physics/CollisionResolvingTests.java
testCollidingMoveSlideDown()
move()
in the act part with the constantMOVE_10X10Y_DISTANCE
without subtracting anything from itExpected behavior
The test passes with a target location at the expected position.
Your System:
Additional context
The issue was found and adressed in pull requests 397 and 398. Refer to the comments there for further details.
The text was updated successfully, but these errors were encountered: