LÖVE

I'm using HardonCollider and my own tile system to make a platformer.
My player character is 2 tiles wide, so when it's standing on the ground, it touches between 2 and 3 tiles.
This produces 2-3 HardonCollider onCollision calls.
Within the onCollision call, I move my Player entity by the mtvX and mtvY amount.
The problem is that it's being moved 2-3 times, so it bobbles up and down on the ground.

I've temporarily fixed the problem by setting a "player.moved" variable to true the first time it's moved by onCollision.
But when the player is touching one wall tile and one ground tile, this will fail.

Is there a standard way to resolve this?
I feel I'm missing something really obvious...

I've fought problems like that one for months in bump.

Right now this is what I do:

1. Calculate all collisions for the player, and store them in a table
2. Find the collission with the object M with the biggest "heuristic". Bump's heuristic is "the object covering the biggest surface of player". It's good, but not 100% perfect.
3. Resolve the collision with M. This means "calling the onCollision callback", probably moving the player around a bit. Mark M as "visited"
4. Go back to 1, skipping visited neighbors, or end if all colliding neighbors are visited

So far it seems to handle things pretty well. You can not do it exactly the same way in HC, as it calculates all collisions for all pairs and then it starts calling onCollision. But I hope this helps.

Thanks for the reply!

I had one thought. Currently I use one collision shape to detect all types of collision — top, bottom, left, right.
I thought I could solve the corner issue by creating 4 collision shapes and offsetting their corners slightly (as shown below).
The character could in theory get caught on the edges this way though... Hmm I'm not sure what to do.

You don't need to stick to collision boxes methods concerning detection. I also have a platformer in the works and followed instead the old multiple point detection used in 8/16 bit classics. Could be more flexible for you than using inaccurate multiple boxes.
Check this great article/tutorial here:
http://games.greggman.com/game/programming_m_c__kids/

coffee wrote:You don't need to stick to collision boxes methods concerning detection. I also have a platformer in the works and followed instead the old multiple point detection used in 8/16 bit classics. Could be more flexible for you than using inaccurate multiple boxes.
Check this great article/tutorial here:
http://games.greggman.com/game/programming_m_c__kids/

I've read the Sonic physics tutorial that seems to use a similar method.
It sounds useful and minimal but my terrain already uses HardonCollider collision stuff so I'd rather not change it if I can avoid it.