whats a good way to do collision detections.

the two things I've done are
1. Draw an imaginary box around objects, then cycle through all the objects to see if any are overlapping
2. Use chipmunk for collision.

The first one is okay, but a little bit clumsy, when it comes to shapes that aren't square.
The second one is good, but I feel its somewhat over kill to include chipmunk just for collision detections.

I can do some simple maths to find out if things are colliding, but I quickly run into frame issues cycling through all the objects (using ruby).

there can be about 100 - 200 objects that need collision detection.

I guess chipmunk is good for this because its in c

You can divide the level into small sectors if your objects are distributed well over the level and not all in one place, and then only check objects in the neighboring sectors. Other optimizations would be to work with integer (Fixnum) values only, as they are much faster than Floats. Or to take a look at the efforts of porting Gosu to Ruby 1.9, which might just be fast enough for you (ugly, but…). Just some ideas :)

is 1.9 that much faster? is it comparable to python?

how is it ugly? are you talking about getting it to work? or actually packaging and running it?

Yes, it should be on par with Python. Mostly, I find it sad that the well-supported Ruby 1.8 is so slow and that an update would fix many of these problems. But using the system-supplied Ruby sure feels safer—would've loved it if they shipped Leopard with 1.9 :(

With a working 1.9 Deployment Template, everything would be pretty easy actually; you could use it for development too instead of installing Ruby 1.9 in its entirety on your system. At least it's scheduled for the next version of Gosu, if that's of any help ;)

Depending on your type of game, this might be a good optimization.  For example, if you have a platformer without projectiles, you'd only really need to check collisions within a 30px box around the player, or something.  Even with projectiles, if they have a defined path you could limit your checking to that defined path and only when a projectile is active.

Adding Chipmunk shouldn't be too bad.  The collision detection is great.  However, if you were doing a tile-based RPG, for example, it'd be more trouble than it's worth.  In that case, you really only need to do adjacent tile checks in the direction of movement.  If you are doing something where you need running, jumping, falling, etc. then you get other stuff for free and the collision callbacks are really handy.

What kind of game you're working on?  I made a bullet hell shmup and the game works fine with 500 objects circle collisions. So I don't think 100 - 200 objects would be a problem, unless you're doing some sophisticate collision like pixel perfect or rotate rectangle :)

But if you just need box collision like your first choice, you don't really need chipmunk since I doubt the speed difference between box and circle collision aren't that significant.

How many pixel perfect collisions could be done?
50?100?

For those of you who have seen the source for Dimensions, you may have noticed a clumsy #check_collision method in game.rb. The course-interaction collision detection is separate and more advanced than this one, which is inter-object collision. Ideally, it verifies the object identity, cycles through specific other object(s) to check overlap, and executes code accordingly.

This could use optimization. Does anyone have specific ideas? I would try chipmunk, but unfortunately I'm running on windows which means that downloading and setting up any intelligent piece of software is a nightmare. I'm trying to make energy-efficient "green" code out of Ruby rather than updating and downloading new stuff.

yeah man,

divide the map into 8 or so quadrants and find which quadrant the object is located in then just do collision detection against other objects in the same quadrant. This is a very lo-fi version of the bsp technique

banister

It's usually called the octree method.