An easy way to simplify "complicated" collision is to create a function that only returns true if the internal coordinates passed to it are inside a function.

An example:

We've already discovered that the player was indeed touching the tiles T1, T2 and T3 since the player unfortunately has an area.

So, to simplify things we take the players extremities and calculate which tiles they are inside, and from there we calculate the fractions of the players position inside those tiles.

Fractions are 0.0 to 1.0 only, and that makes math really easy.

If the players left foot is 0.8 fractions inside a tile, our tileHitbox() function can use simple math to determine if that specific point is solid, or not.

bool tileHitbox(int tileID, float fx, float fy)
{
// depending on the tile, the math functions are abit different
switch (tileID)
{
case T_AIR:
return false; // air is never solid
case T_SLOPE_UP_RIGHT:
// the solid area only exists where fx < fy, a slope that goes up to the right (assuming +y is up)
return (fx < fy);
case T_SLOPE_UP_LEFT:
// the solid area only exists where (1-fx) < fy, a slope that goes up to the left
return ((1.f - fx) < fy);
default:
// in the default case, we just assume the entire tile is solid, for no particular reason
return true;
}
}

So, doing it this way adds some complications to your physics department. But we can solve that, using divide and conquer:

You'll notice that if your player has a high speed downwards, you can hit tiles too early due to gravity, which makes him stop a little bit too far up -- preventing him from "landing" pixel-perfect against the tiles.

To fix that, we let there be a function gravity() which takes a parameter telling us just how much the player needs to go downwards at this particular time:

bool gravity(float x, float y, float rate_down);

Each time gravity fails to move (x, y) down by (rate_down), you should call gravity() again, but halve rate_down. You can stop trying after a given number of tries. 4 tries could be more than enough, since all that matters is that no one notices the difference.

Example:

float rate_total = rate_down;
int tries = 4;
while (tries-- && rate_total > 0)
{
if (gravity(px, py, rate_down)
{
// success, move point downwards
py -= rate_down;
// measuring how far we moved the point down prevents us from continuing
// after we had in fact moved down all the way
rate_total -= rate_down
}
// we always halve the speed here, just in case the loop continues
rate_down /= 2;
}

The example above is just written off the top of my head. I hope it's not entirely wrong.

Another thing you can do is to calculate the size of a pixel, and just move 1 pixel at a time continually until the gravity rate is travelled. That would probably me much simpler code.

If your rate_down is too big, you risk skipping tiles entirely. So make sure rate_down is not too big, and instead call gravity() more times with a lower number to make up.

Solving these problems with the force (not just gravity) movement rate will give you access to defining tile hitboxes with simple math. It is very cheap and simple programming to test against tiles this way, but not particularly efficient. What it does though, is make your life easy. And that counts more than anything to me.

EDIT: This is going to get slightly more complicated now, since you probably want to "automatically" walk up and down slopes, or on the top of a circle tile should you want to create one.

So, how do you automatically walk up a slope? Well, you can just define different rules for moving the player right/left, jumping and falling down.

For jumping you need to check if his head hit something hard.

For falling, you need to check his feet.

And for right/left you need to check his knees, or something even higher up, because that allows you to to move "into" a slope. Your unstuck mechanism should make sure your player stays on top of the terrain at all times, simply by always moving him up until he is no longer stuck.

The drawback here is that your movement upwards a slope will not be at the rate of the slope, but rather at the rate of moving directly right/left. It may be noticeable, and if you don't want it to be like that you could do some combination stations with moving right/left that penalizes the player if he is indeed moving upwards.

To do that, you need to check if the player can move right/left at his feet level first, and if he can't but he still can move if we measure at his knees, then penalize the movement rate a little to make up for the impending upwards movement.

So, how do you unstuck someone? Well the cheapest way is:

void unstuck(SomeGuy& guy)
{
while (terrain.test(guy.footLeft()) || terrain.test(guy.footRight())) guy.move(0.0, 0.1); // move slightly upwards until no longer stuck
}

Or something in that fashion.

**Edited by Kaptein, 26 February 2014 - 01:58 PM.**