Open Darthfett opened 12 years ago
One possible way to do a resting state would be using a 'locking' behavior, which activates when an object has small velocity (below some threshold), collides with object B, and is accelerating towards object B.
Collision should be normal when object A collides with large velocity normal to B's collided segment. When A's relative velocity to B in the direction of the normal to collided segment becomes very small (below some threshold), and collision occurs:
This locking behavior will have to negate acceleration (since position is calculated), without losing the information, so that when 'unlocking' from the object, the acceleration will be reacquired.
Places with special cases for dealing with locked/resting objects:
As of 3b6c33a4db, there is a very basic, frictionless resting state. When an object collides with another object such that its velocity normal to the line is very small, and its acceleration is also toward the line, it will enter into the resting state, which will negate the relative velocity and acceleration normal to the line, and ignore future collisions.
There's a bit of hardcoding for the fact that one entity is non-moving, and the other is moving.
As of 97d15da, the resting state detection now works with two moving entities (though this is untested). More work is needed to get the resting state resolution to also work for two moving entities.
As expected (by design), with the current collision resolution method, if an object is bouncing on the ground and velocity becomes very small (close to 0), the collisions will begin to stack up, and pygame will become very unresponsive.
In typical collision detection/resolution, this small velocity is referred to as coming to a resting state. After finding what causes #21, it is clear that a simple reflected-bounce resolution algorithm will cause issues, and a resting state is needed to resolve falling-through-the-ground issues, as well as laggy collision issues.