Hello. I've been working towards achieving an effect in which, should a player hit a solid object, they can slide passed it, despite them pressing more than one arrow key. For example, say you're going up to the right and you hit a solid object from the bottom; well, stop moving up and begin just sliding to the right instead. A lot of top-down video games have this functionality, but I am having difficulties achieving it.

I have two integers: dirX and dirY; each of which corresponds to the player's X and Y positions (dirX = 1 is right; dirX = -1 is left; dirX = 0 is no x movement; dirY = 1 is down; dirY = -1 is up; dirY = 0 is no Y movement). Here's my current code for what to do upon hitting a solid object:

The main issue with this is that it will not allow you to slide around objects as mentioned above. Instead, if you collide, it locks up until you release the key that is holding you back. I did find a partial solution however...

This would allow me to slide on the left and right sides of the collided object (the function is called after confirming a collision of a specific tile, mind you). I haven't yet had any luck getting it to allow the player to slide on the top and bottom sides of the object though. Do you have any input? Thank you.

PS: This is for a top-down game, so there is no velocity involved.

I see no difference between those examples; they are the same equations, simply reordered.

Just for clarification, is this what you're seeing, and trying to remedy?

So if I have this object:

    xxxxx
    xxxxx
    xxxxx

and my colliding object is calculated to be here:

    xxxxx
    xxxxx
    xxxxx

    0

then I first try to move up:

    xxxxx
    xxxxx
    xxxxx
    0      <-- success

Next, I try to move right:

    xxxxx
    xxxxx
    xxxxx
     0     <-- success

Now I'm on my next update loop. I am at this:

    xxxxx
    xxxxx
    xxxxx
     0

and try to move up. Since I can't, I stay there:

    xxxxx
    xxxxx
    xxxxx
     0     <-- failed, still in this position

Then I try to move right:

    xxxxx
    xxxxx
    xxxxx
      0    <-- success

If I repeat those last 2 moves, I am now here:

    xxxxx
    xxxxx
    xxxxx
        0  <-- here now

What you're probably seeing is that on the next round, where you would expect my character to be able to move from:

    xxxxx
    xxxxx
    xxxxx
        0  <-- here

to

    xxxxx
    xxxxx
    xxxxx0 <-- here

is that my character cannot move up, but it can move right:

    xxxxx
    xxxxx
    xxxxx
         0 <-- here

and it's not until the next update that I can start moving diagonally again:

    xxxxx
    xxxxx
    xxxxx 0 <-- probably one space further right than you anticipated

Is that what you're seeing and trying to fix, or something else?

I'm a little confused by the two code blocks you posted, since they're functionally the same (but apparently only the second one is supposed to work?). Originally I thought you were talking about rolling around corners (ie- holding left, player hits obstacle, automatically moves one tile up without having to press up, continues left past obstacle), but I'm thinking now you're talking about not "undoing" both horizontal and vertical movement when hitting an object, only undoing the one that caused the collision.

The reason you aren't sliding from the top or bottom is because you are always undoing your horizontal movement, no matter what, when you call hitSolid. Basically, instead of undoing all movements, you need to figure out whether you hit the obstacle horizontally or vertically and only undo the appropriate movement. Then you can hold up+left, hit something from the bottom, continue moving left but don't continue up until you're past the obstacle.

Ultimately your code should be something like:

void Player::hitSolid() {
   ///TODO figure out what side the hit was

   if (CollisionFromTop || CollisionFromBottom) {
      y += -dirY*speed; // undo vert movement
   }
   // if you want to block corner collisions rather than just going a direction,
   // these aren't mutually exclusive
   else {
      x += -dirX*speed; // undo horiz movement
   }
}

As for figuring out what side the collision was, it's trivial if you were only moving in one direction. Otherwise (if the speed is less than the player/obstacle's sizes), you can measure the differences of each object's corresponding edges (ie- player's left side to obstacles right side, player's top to obstacle's bottom), and the minimum magnitude difference is where the collision occurred. If a horizontal and vertical difference tie for minimum, then you hit a corner and you can either undo both movements, or just pick one direction to dominate the other.

I don't know how you're doing collision detection, but you may run into issues trying to slide across multiple adjacent tiles, getting false corner collisions...

OnlineCop, I'm trying to do this: once you hit a solid object, you won't be able to go any further in the direction that you hit the object from. So if you're going up to the right and hit the bottom of an object, prevent the player from going up any further, but allow them to move to the left or the right, because nothing is blocking their path there.

Jeff Bernard, your code works well for being able to slide around the top and bottom of object, but I'm still having difficulties with the left and right sides (it allows me to pass through them if I am holding a vertical arrow key as well as a horizontal one). I was having this issue before, where I could only achieve the effect on two of the four sides, but not all of them. Also, I am using bounding box collision.

I appreciate the responses guys.

The only other suggestion I would have it to, instead of merely undoing the last movement, actually move the player to next to the obstacle.

That's what I do in my game, using the method of determining the side of a collision I described earlier and it works fine. For the interested here's the code (like yours, this function is only called once a collision, ie- overlapping bounding boxes, is detected). In this code I ignore collisions between mobile sprites (ie- if two objects can both move, they can move through each other), and only care about collisions between sprites that can and can't move (ie- a moving sprite can't move through a stationary wall), so objI would correspond to your obstacle and objJ would correspond to your player:

(Some clarification, my code assumes objects have bounding boxes, but my physics engine has no notion of bounding boxes, per se, rather bounding shapes are a collection of vertices and the separating axis thereon is used to determine collisions, so that's why I don't get the object's bounding box directly (you can't), instead I calculate it on the fly based on the conventions of my current game.)

You have to do intercept times and find out which edge collided first.
d = r*t (distance = rate * time)
t = d/r

1. Find relative velocity of one rectangle to another (leader, and collider).
2. Find leading edges of leader, and colliding edges of collider.
3. Find x-intercept times
4. Find y ranges of edges in 2 at times in 3.
5. If range overlaps, x-collision at that time.
6-8. Repeats steps for y-intercept times, x ranges, and y collision.
9. Find earliest positive, and possibly simultaneous, collision time(s), disregarding negative collision times as they happened in the past.
10. Advance time to that point, ceasing velocity in the direction of the collision, and placing the objects right next to each other along that edge. It will temporarily slow down the object but it should slide after that, like down a wall.

I won't write the code out for you, but this basic premise works. Also, you should only perform 10) after you have checked against each possible colliding object. Because the collision should stop after the earliest one.

Assuming you're working with axis-aligned (non-rotated) rectangles, the solution is easy.

Pseudocode:

Disclaimer: I'm really tired, so I might have mixed the signs up or made some other typo. But the idea is there. It works because the rectangles can't possibly be colliding if one of those edges isn't past its opposite partner. So by ruling all those cases out, what's left is only rectangles that collide.

How you implement getLeftEdge, getRightEdge, getTopEdge, and getBottomEdge is up to you, but presumably it would be something like:

float Object::getLeftEdge() {
  return x - sprite_width / 2;
}

//similar functions for other edges

In the end, code like this should allow "sliding" along walls.