2d collision detection for sidescroller

[Boone]

You need to learn some maths, my friend! :twisted:

The two important components you need for decent 2d collision detection are Parametric lines, and to find the intersection of two lines( one for the scenery, the other to represent the vector for your character ) you need to look at matrix math and especially the the "inverse matrix".

I recommend chapter 4 and 5 from the following book...

"Tricks of the 3D game programming Gurus: Advanced 3D graphics and rasterization" - by Andre Lamothe.

...definetly worth the time and effort. :thumbsup:

[arramor]

Thanks for your reply, boone. I'm happy to say i don't need to learn maths, i've already got maths I and II from university (linear algebra and calculus).

I'm looking for known and efficient collision detection algorithms for 2d sprites. I wanna learn the best algorithms that exist for just that, and then maybe changing it or whatever for the game. Its best to learn from those before me. Of course I could go and just write a plain function myself, but that would beat the idea of learning from other's experience.

I already found some good articles from the net on 2d collision detection, but I was hoping somebody could direct me to some interesting sites, or give me some insights if you have first hand experience. It's gonna be a browser game, so efficiency is key.

Also if you know of some books on this topic ...

thanks :)

[Boone]

Ah, well you're posting this question on the wrong site - try...

www.gamedev.net

...you'll find some smart cookies there! :thumbsup:

[AdamAtomic]

I did a lot of searching around for info about this a little while ago, and wasn't able to find very much that was helpful. Here are some general tips and things I came across when I was building my all-purpose 2-d engine (side-scrolling or top-down):

1 - If you are using a tilemapped level, a good shortcut is to programmatically calculate the only possible tiles you COULD be colliding with first. A sprite that is the size of 1 tile (like small Mario) can only collide with a max of 4 tiles each frame. The calculations are very fast compared to checking collision against every tile on the screen. If you are not using tilemaps for your level or collision hull, then there are other approaches you can take to get a good location proxy:
A: Arbitrarily divide the screen into a grid
B: Generate a BSP or quad tree from your level
Regardless of how you do it, this is FAR more important than having just a fast intersection checking algorithm, because it greatly reduces the number of times you have to run that check.

2 - Use a filtered approach. Check for simple collisions (like "am i standing on the floor?") first, and if that succeeds, just drop out and move on. Only check the special cases like corners colliding with corners (VERY ANNOYING) or pixel-level collisions if the easier cases/checks fail.

3 - If you are stuck on the corner-to-corner problem (did i hit the cliff side or land on top of it?) don't be afraid to use your global gravity variable to help you decide the best course of action.

4 - You can use your gravity variable to help you decide where to relocate a sprite if it hits a slanted surface too (always go against the gravity vector! if there is no gravity vector then follow the normal of the surface).

These are kind of vague, I know, but they are very good general rules for any 2D collision system, regardless of whether or not you are using tilemaps and square game objects like mine. I have been meaning to write a tutorial for doing a tilemap and sprite based collision system based on my work but I haven't had the time. Hope this helps!

[arramor]

thanks Adam A. It does help.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.