You can store whatever other useful information about the two touching shapes you need (like the normal of the surface they are touching that represents the axis of minimum penetration, by how far they are penetrating, etc).

Quoted for emphasis. This may sound like a subtle step, but the order of resolving collisions by the axis of minimum penetration makes a difference for better collision responses.

Here's a relevant article: http://www.geoffblair.com/blog/order-matters-tile-map-collision-response/

Now, this article presents other approaches to resolving axis of least separation, but for platform games they're not always necessary. I tend to just loop through the boxes/tiles that are colliding with the moving entity, no matter how they are ordered, and start resolving with the first one found in the loop. If penetration for X is shallower than Y, push away on the X axis.

@CC Ricers

Hmm I think I tried something like that and a few things didn't work out, thats why I switched to calculating the "time of impact" instead of penetration amount checking.

One of the things was the same thing that's being adressed in the article: Wrong resolutions. But I'm not sure If I tried it with the correct ordering.

Maybe I could try swapping the techniques around and do it with the least penetration amount technique again.

I'm kind of sick of fiddling around with it. For two years I am stuck with this problem now and I'm making next to no progress... soooooo frustrating argh...

But of course I didn't work 2 years non-stop on it. Otherwise I would already have gone insane

Have been procrastinating a lot because I have absolutely no idea what to do anymore and I'm kind of lazy and demotivated.

I know that feeling... it was the same for me for a other game prototypes i made.

But regarding platformer physics, i got pretty good results using technique called speculative contacts with sonics sensors for the entities.

The core idea behind that technique is use sensor points on the left/right edges and top/bottom edges for every entity to determine which tiles needs to be checked.

This is your broadphase if you will, then grow every tile with the entity half-size (minkowski difference) and determine the closest point against that fatten tile aabb. This closest point is extremly simple to determine of your sensors include the separating normal as well - so its just a simple vector projection. Lastly you get the difference between entity position and the closest point. Then you project this difference against the separating normal from the sensor and create a contact for it including its distance even when positive. At final stage, you just need to solve this contact using the speculative contacts approach descriped here:

http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/

This technique works for non-tile shapes as well, you just need a way to calculate the closest point and the distance between the centers using minkowski difference.

Of course for non-aabb cases, the sensor approach may not work, but i never tried it.

The only downside to this technique you cannot control how a wall bounces you off. Bouncing will be solved by automatically when you include its in the solver as well. But you cannot control how the object bounces - like in box2d for example, where you can specifiy the coeffecient of restitution. Therefore this technique is mostly suited for platformer - just to give you an example: Little big planet use this technique and is therefore extremely stable.

But the main benefit of this technique is to not worry about TOI at all and get continous collisions out-of-the-box - the system finds a global state very fast and can be used for rigidbody physics as well.

If you need further explanations, check out the link i posted in the block above.

Greetings,

Final

An important problem I noticed is that you hope to deal with enormous time steps in which arbitrarily complex event sequences take place. Specifically, you have forces and impulses applied in the middle of movement (gravity when not standing, returning to a desired velocity, etc.), which should instead be respectively constant and applied between movement steps.

Instead, decompose the simulation into elementary collision and control steps in which complexity is manageable. You can always advance simulation time several times in small steps that add up to the desired frame duration.

For example, the falling into a gap example includes multiple events and states: walking on the first platform, crossing the first platform edge, flying over the gap, and then either crossing the far platform edge and walking on the far platform or hitting the vertical wall and sliding down.

Correct handling requires separating walking on a platform from walking into the pit: in the latter case the character would fall down slightly and reach the far platform edge with his feet below the platform level; at this point you have a wall-hitting event, with a certain wall height and velocity (which, assuming a standard walking speed, depend only on platform heights and pit width).

When the characters hits the far vertical wall you can proceed with the physically orthodox outcome of sliding down or perform specific platformer-appropriate animations according to the situation (for example, sorted by increasing height loss: just raise legs and feet a little; land with the knees on the platform and stand up; tumble rather badly; grab the ledge with hands and stop; brace for impact against the wall and fall down).