Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm implementing a 2D overworld where one can walk through an area that is not tile based. I was wondering the best way to implement collisions. In the past when I've done similar things, I've used one image (or set of images) to show an elaborately drawn world and then a second binary image that does nothing but differentiate "wall" and "not wall". Then, I'd use the first for all drawing to the screen, but the second for collision detection. Having another image of the same size to represent collisions seems like lots of overhead. Is there a better way to handle this?

(I'm currently using C++ with SDL, although I'm more interested in general concepts)

share|improve this question
up vote 1 down vote accepted

You can use a tile based collision approach independently whether the landscape itself is tile based or not. It's basically as fast as it can get and also as easy to implement as it can get.

If you need a really high precision and memory usage is a issue you can use a quad tree instead of a simple array. (A data structure with almost O(1) performance but which is more flexible in how much detail is stored.)

If you want more complex physics you probably want a collision polygon, so you can handle slopes, rotations etc. better.

share|improve this answer
Makes sense, and quadtrees will definitely be worth looking into, thank you! – akroy Jun 4 '12 at 1:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.