2D Platformer AABB collision problems

Question

I have a problem with AABB collision resolution.

---

I resolve AABB intersection by resolving the X axis first, then the Y axis. This is done to prevent this bug: http://i.stack.imgur.com/NLg4j.png

---

The current method works fine when an object moves into the player and the player has to be pushed horizontally. As you can see in the.gif, the horizontal spikes push the player correctly.

---

When the vertical spikes move into the player, however, the X axis is still resolved first. This makes "using the spikes as a lift" impossible.

When the player moves into the vertical spikes (affected by gravity, falls into them), he's pushed on the Y axis, because there was no overlap on the X axis to begin with.

---

Something I tried was the method described in the first answer of this link . However the spikes and moving objects move by having their position changed, not velocity, and I don't calculate their next predicted position until their Update() method is called. Needless to say this solution didn't work either. :(

---

I need to solve AABB collision in a way that both of the cases described above work as intended.

This is my current collision source code: http://pastebin.com/MiCi3nA1

I'd be really grateful if someone could look into this, since this bug has been present in the engine all the way back from the beginning, and I've been struggling to find a good solution, without any success. This is seriously making me spend nights looking at the collision code and preventing me from getting to the "fun part" and coding the game logic:(

---

I tried implementing the same collision system as in the XNA AppHub platformer demo (by copy-pasting most of the stuff). However the "jumping" bug occurs in my game, while it doesn't occur in the AppHub demo. [ jumping bug: http://i.stack.imgur.com/NLg4j.png ]

To jump I check if the player is "onGround", then add -5 to Velocity.Y.

Since the player's Velocity.X is higher than Velocity.Y (refer to the fourth panel in the diagram), onGround is set to true when it shouldn't be, and thus lets the player jump in mid-air.

I believe this doesn't happen in the AppHub demo because the player's Velocity.X will never be higher than Velocity.Y, but I may be mistaken.

I solved this before by resolving on the X axis first, then on the Y axis. But that screws up the collision with the spikes as I stated above.

Answer 1

As Gareth Rees already said, the issue is after a collision is detected, you need more information (both current location and either direction came from or last position) to perform the collision response.

It gets quite complicated if both objects are moving. Instead, choose one object to be the frame of reference and subtract its velocity from everything else.

A straight forward solution might be to create line segments for the movement/delta of the non-frame-of-reference object. Then intersect those segments with the 4 AABB edges. This gives the time of intersection and the normal at the point of intersection. Then you can apply the same response you have now.

Answer 2

One possible solution I found is sorting the objects before resolving based on the velocity of the player.

Answer 3

Why not resolve on the Y-axis first for vertical spikes, and on the X-axis first for horizontal spikes?

Nice graphic, by the way.

---

As I understand it, you're handling movement and collision something like this:

1. Move all objects.
2. For each object O , test for intersection between the player and O , and if necessary, eject the player horizontally or vertically so that it is no longer intersecting with O .
3. If the player is still intersecting with some object, then (something) .

This means that when you come to step (2), you have forgotten which way the object O was moving, so you can't tell if it is trying to push the player upwards or sideways.

Solution: in step (1), store for each object the direction it is moving. When you find the player intersecting with an object, you can look to see whether the object is moving up, down, left or right, and that will tell you which way to perform the ejection.