Every time I use pixel perfect collision in a game I try a slightly different approach, trying to perfect the algorithm.
First it seems very very simple. Let’s just check 1 pixel at the center bottom (at the players “feet”) for a non-transparent pixel. If there’s a collision, follow Y-axis upwards (say, max 5 pixels) until we hit a transparent pixel (non-terrain). Put player there. This will make him walk on the terrain.. and also climb 5 pixel high obstacles. Higher obstacles needs to be jumped.
Cool enough, just checking one pixel and we get all that.
But then you realise you can jump into the roof.. and player will only stop first when his feet head is way into it and his feet his touching the roof.
So you check another pixel for collision, one at the head of the player, now you can stop him when he jumps into the roof. It works well.
Then you start painting more levels, and soon enough you’ll make a pointy object. The player jumps into it, not hitting the head or feet, just the mid-section. Player falls down by gravity, head hits the floor of the pointy object, and the player gets stuck.
You could either not paint pointy objects.. or you could extend your collision detection algo. One of the reasons I went with pixel perfect collisions is that I wanted levelbuilding freedom, just being creative and painting whatever fun terrain in paintbrush or graphics gale. I WANT pointy objects. Makes for nice ladders the player could jump on :).
So, we add pixel checks on the left and the right side of the player so we don’t jump into pointy things. It works decent, but you realise just checking 1 pixel at each side doesn’t cut it in all situations, objects you jump into could be Very pointy. So you basically end up checking all pixels on all sides. A bounding box if you so will, and we check all the pixels along the borders of it.
This is totally ok if you got a fast get_pixel()-method for your disposal. Now, how I usually do small games is I have a “physics”-behavior which I plug in into my player-class. This adds some instance variables to the player-object, velocity_x, velocity_y, acceleration_y etc. Before each update() the plugin will read those and modify x and y accordingly. Then I land in the update() method of the player with my new x and y (the behavior even saves previous_x and previous_y for me if I need to revert to the most recent position).
So, I’m in player update() and I got a new set of x and y .. and I got my collision_left?, collision_right?, collision_bottom? and collision_top? methods (I do Ruby so “?” is totally OK in method-names).
Still sounds like this should be simple, but it turns out it’s not.
What side do I check collisions for first? Depending on what I start with I’ll get different player controls. If I start by checking collision_bottom? and reverting y to previous_y on collision, then checking left/right and reverting x to previous_x on collision I will be able to stick the player to a vertical wall just be jumping (say to the right) into it and keep holding right arrow-button. And if I check right/left first there’s other effects.
Though this might an effect of first doing all the physics and then doing all the collision detection. Maybe it’s a must to them at the same time, and with that I mean, if a right arrow key is detected, you “fake move” your player 1 pixel to the right and if right_collision? is true, you revert instantly. And so on.
I want to end up with something simple and readable, and I feel it should be possible.
Here’s a screenshot of the game I’m fiddling with, to give you a sense of what kind of terrain we’re talking about:
Who’s got the perfect pixel collision algo with simple physics? (only acceleration_y / gravity is OK)
I hope he is Ok
