Optimizing Collision Checks

I went and revisited an old engine I was once working on but abandoned because it was ridiculously slow, and what I found via the debugger was, that, as I suspected originally, the number of collision checks were though the roof (due to the engine's need for multiple detectors).

Now, the question is, are there any methods for cutting that down to size? I was thinking of using a distance check to determine if a solid object is close enough to the player to actually be worth checking, because there's no point trying to check for a collision with an object that's ten-thousand pixels away or something, but I can't quite figure out how to do that.

Some ideas:

• check collisions on a timer. E.g. if you have slow moving objects, you can get away with 'Every 0.1 seconds' then 'Is overlapping'. 'On collision' still makes a collision check every tick, so if you can get away with every 0.1 seconds (approx. every 6 ticks), then it's going to be doing 6x fewer collision checks.

• reorder conditions. Consider:

+ A is overlapping B

+ A health > 50

This is inefficient since it does lots of collision checks for A overlapping B, then filters out some of A based on the health variable. This means a bunch of collision checks on A were unnecessary. Reordering it like this:

+ A health > 50

+ A is overlapping B

means that fewer collision checks are done, since only the subset of objects with health > 50 get tested.

• use fewer objects if possible, especially where testing collisions between two sets of objects with lots of instances. E.g. 'Is A overlapping B' with 100 instances of A and 100 instances of B requires about 10,000 collision checks - and if you're doing that per tick, obviously that's a huge CPU drain.

From what I can tell, the 'every 0.1 seconds' method mostly breaks the engine completely. To be more specific, the engine is a pure event-based Sonic-style platform engine, and the collision checks are for a set of collision 'sensors' checking for overlapping with terrain objects. The engine itself uses a lot of functions for collision checking. The engine itself is about a year old, but it still works fine, aside from being seriously unoptimized to hell and back.

So, yeah, using the 'every x seconds' condition doesn't work, and the other tips aren't really applicable here, which is why I was mainly asking for a distance-based method, since it would massively cut down the number of objects that would need to be checked at one time.

Nobody said making a Sonic engine was easy :p but thanks for the tips.

The collision engine already rejects collisions which are far away (when their bounding boxes don't overlap) almost immediately. You must have a seriously huge number of objects for the sheer number of them to cause a slowdown from just the bounding box checks... how many are we talking here?

Well, looking at the engine itself, it's a "tile-based" engine, but the number of objects on-screen that need to be checked at any one time isn't much. The player object has a set of 16 sensors (which are required for operations that overlap offset isn't appropriate for). It's not that many, but I'm still seeing the number of collision checks in the realm of nearly 2 million per second, which is kinda insane.

Besides, I did a re-examination of the debug results, and it provided an eye-opener. The events that take up the most CPU are the movement routines, which totals around 35% CPU use out of 45%, and considering it's a basic test level and it's still causing a lot of slowdown, that's not good at all. I think the way the engine itself is set up is incredibly inefficient, which is surprising, considering it's a port of a similar engine from Classic, which ran fine.

In short, I suspect that I'll need to find another implementation if I want to do a Sonic engine... Or just have someone write up a javascript behaviour. XD