1
\$\begingroup\$

Currently my collision method is glitchy, because it gets the last "good" position it was when it wasn't colliding and teleports it to that location when it collides with something. This method works, but it causes the sprite to constantly micro-jump while it's touching things.

Any recommendations for a better collision system?

\$\endgroup\$
  • \$\begingroup\$ Have you tried checking for collision before moving? \$\endgroup\$ – UnderscoreZero Nov 13 '13 at 19:19
  • 1
    \$\begingroup\$ The trick is to move on one axis, check collisions, then move on the other axis, and check collisions again. \$\endgroup\$ – jgallant Nov 13 '13 at 19:21
  • \$\begingroup\$ @Jon Why not just both axes at the same time and backtrack along the movement vector at the time of collision? No jitter should occur with that method unless there's an actual implementation bug. \$\endgroup\$ – kevintodisco Nov 13 '13 at 21:21
  • 1
    \$\begingroup\$ @ktodisco Because doing a single axis at a time provides a much better collision resolution, than doing both axis at the same time. \$\endgroup\$ – jgallant Nov 13 '13 at 21:35
  • \$\begingroup\$ @Jon My question was more rhetorical... Vector operations allow you achieve the same result in a more parallel fashion. Do you have a reference for better performance when testing axes independently? \$\endgroup\$ – kevintodisco Nov 13 '13 at 22:06
2
\$\begingroup\$

Resolve axis independently of each other, and rather than place your character back at its original location, place them at an appropriate location based on where the collision took place. Most ray casting implementations will return you a "t" value if not an actual vector. Identify this location, and then place your character at something such as: : (dirVector * t) - dirVector * charRadius;

dirVector = normalized direction from current pos to target pos, t = value returned by raycast indicating the intersection point of the ray (scalar), charRadius = radius of character capsule/box/whatever

This is just a rough idea, that will place your character at a location far enough from the point of collision so that you arent clipping into the wall.

General idea, you will have to adapt for yourself of course.

\$\endgroup\$
  • \$\begingroup\$ Ray-casting to find the collision point for something that is not a ray will not return the correct collision point. Consider the case of an OOBB. The point at which a ray originating at the box's center and traveling in the direction of its movement intersects the wall will be different than the point at which a corner of the box intersects the wall. \$\endgroup\$ – kevintodisco Nov 14 '13 at 1:26
  • \$\begingroup\$ Yeah this definitely isn't an all purpose solution, but it does work effectively if the object you are moving uses a capsule or sphere. The theory is still applicable, even if the specific implementation is different. \$\endgroup\$ – Evan Nov 14 '13 at 4:10
  • \$\begingroup\$ It will also return the incorrect point for a circle or sphere... You'd end up positioning the object in such a way that it is still intersecting the wall. \$\endgroup\$ – kevintodisco Nov 14 '13 at 5:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.