if(bottomA <= topB)
{
    return 0;
}

if(topA >= bottomB)
{
    return 0;
}

if(rightA <= leftB)
{
    return 0;
}

if(leftA >= rightB)
{
    return 0;
}

//If none of the sides from A are outside B
return 1;

Edit: Hmm, interesting way of doing it.

How about this?

if(check_collision_rect(player.pos, tile))

That should be tile, should it not?

Wow thanks, this fixed it. It was so obvious, I guess I got confused from my first 2D game attempt a year ago.

Hmm, well, I think that run time errors generally aren't obvious, so don't feel bad when stuff like this happens.

 

Don't get this the wrong way, but why are you drawing at 2000 FPS?

 
How do you know that he's not just using the value as a way to see how much processing power he's got left? Like, in my own game I've defined both UPS and FPS, to get a good idea of how things are going.

 

Yeah, I thought of that, but I don't think he would be running out of processing power anytime soon - not with such a simple game. I've played some other such 2D games, and even read articles about implementing the game loop such as to maximize the FPS, but that's bullshit, especially for simple 2D games. Imagine if Minesweeper or Solitaire would max out your CPU this way. :)
And IMHO, using more CPU cycles is not the proper way to make the game more responsive either - I don't know if sampling keyboard/mouse input at intervals of 16.6 ms would cause very noticeable input lag, but I know that most keyboard and mouse events have a timestamp attached, for when the event actually occurred - that timestamp should be used in computing the game state instead of the current time (which is what causes the lag). But if he continues to use the highest FPS he can get, he will not notice this, and when he does start to optimize the FPS, he'll be wondering why there's jumpy or laggy input. And most developers will just give up at this point, and leave the final game running at max FPS/CPU cycles. Just sayin'. :)