next »

[Ben_Hurr]

Hey guys, while I was coding up some collision resolution for one of my platform projects I started getting curious: how do some of you dudes do it?

Because I do it by moving along each axis a little bit until I bump into something, which uh, seems a bit inaccurate. 

[Sos]

how do some of you dudes do it?

Badly, as for me.

[oahda]

Like I wrote in another topic:

The system I have developed for my 2D platformer doesn't deal with square collision objects, but polygon collision objects, which are split up into triangles to check for perfect collision within these triangular shapes.

I obviously have quite simple collision polygons, but they still give more precision and look nicer than just square collision blocks, and as the collision polygons are obviously invisible, and all that's visible are the tiles and the sprites, this gives you a pretty good illusion of an almost pixel perfect collision system.

This also allows for slopes of all angles very easily.

To make sure that I don't blow out the RAM just to check for collisions, I make sure to have as few block objects as possible, and I make sure that as few blocks as possible are checked at the same time. For this system to work, it is important that I add the blocks in the right order, from the beginning of the level to the end of it.

To make sure that I have as few blocks as possible, I simply allow every block object to have a repetition parameter, so that the same block can actually be as many blocks as I want to. The reason I do this is because the collision algorithm works much better when using several small blocks than huge ones.

To check for collisions, there is a for loop that goes through all the blocks of the course, but it breaks itself if the next block it checks is out of range, so that it doesn't have to check more blocks than necessary, and there is a variable to keep track of how far you are into the level, so that you do not loop through any blocks behind you either. So, mostly, thanks to the repetition parameter, mostly just one block or two is in the loop at the moment. Then there is, of course, another for loop within this one to loop through the repetitions, but like I said, this only happens for one block and then the loop will break, so it isn't slow either.

My next goal is to also deallocate any blocks not used anymore (as you can't go back) and not to allocate any blocks long before I need them.

[Ben_Hurr]

And here I was just talking about getting collision blocks to mash up against walls nicely, dohohoho

[oahda]

And here I was just talking about getting collision blocks to mash up against walls nicely, dohohoho

Well, rectangular collision is obviously far more easy, and doesn't require this load of trigonometry which took me a week to figure out since I'm not exactly an expert on mathematics.

What I'd to is to simply check whether your collision block has bumped into a wall, and if so, check whether this wall is in front of you or behind of you, and then just move your collision block so that it isn't inside the other block but right next to it.

[st33d]

That's the squeezy way of resolving collision - which works well until you're moving faster than the width of a block.

One way to counteract that is to move in samples of less than a block wide.

Another way is preventative collision. You walk in block wide steps ahead of your character as far as your speed describes. If you've walked into a block, then subtract the closest edge of the block from your speed.

The first method is quick and dirty, nothing wrong with it. I still make games using it. But the second method allows you to have stackable crates in your game, which squeezy collision won't allow without lots of jitter.

[Ben_Hurr]

Quite right.

I don't really use pixel-sized lightening fast objects really, even if it works properly it still doesn't look good.

[oahda]

You are very right, st33d.
To check before moving and to see if one _will_ have an impact on the next frame is also a good solution.

[st33d]

The preventative method should offer a call to the object you've walked into (if it's a crate) to move that object. Each call to an object's move returns how much it moved.

Consider pushing three crates next to each other, and the last crate in the line meets a wall. The push sinks down through each crate to the last crate, then that crate bubbles back up how much it moved back to the character. All of them come to a stop because the last crate sent the right distance to move back through each object.

Crates are quite the research project, but it's worth creating a framework so you can tackle it in a later engine.

[Kadoba]

This is the way I do it:

Each frame, move the collision box at set denominations toward the new position (usually the shorter of either the width or the height of the box.) If you find a collision, do a binary search from the previous position to the current position until you pinpoint down to the pixel where there are no collisions but you are next to the colliding object. It's not perfect but it works for me.