Collision check question.

Hey all

I realize that having a game with multiple collision events can put a drag on performance. Let's take an example of a ball hitting objects on the screen. Say obj1 is near the right, obj2 is near the left, obj3 near floor etc.. and if ball hits obj1 the ball turn blue,obj2-red etc.... So these objects are at certain x,y positions.

What i would normally do is, make an event 'when ball is in collision with obj1-turn ball blue'. Now what if added another condition of 'ball is within x' , where the object lies within the x limit. Will this help on improving performance?. instead of checking for collisions every tick for every ball-object comb, it would only check if ball is within the object's x range. Does it work that way?, or have i mistaken it?

[quote:yh0c4699]What i would normally do is, make an event 'when ball is in collision with obj1-turn ball blue'. Now what if added another condition of 'ball is within x' , where the object lies within the x limit. Will this help on improving performance?. instead of checking for collisions every tick for every ball-object comb, it would only check if ball is within the object's x range. Does it work that way?, or have i mistaken it?

There are some things you can do to improve performance. First of all never use "On collision", which sounds a bit weird when that is what you want to do . However that event for some reason is very demanding and if you need to do a lot of collision detection that will kill performance quite fast. Instead use "Is overlapping".

Also your idea of only check for collision based on range seems to be the most effective way of improving performance, This is from a test I did some time ago:

[quote:yh0c4699]

(Collision group is the name of the group in my program that does the distance checking, not something you find in C2)

1. Using overlapping (With the Collision group disabled)

Number of objects: 2490

FPS: 8-9

Collision checks per sec: 18000-21000

2. Using On collision event (With the Collision group disabled)

Number of objects: 2512

FPS: 2-3

Collision checks per sec: 1013025+

3. Using overlapping (With the Collision group Enabled)

Number of objects: 2501

FPS: 29-30

Collision checks per sec: 12000-15000

4. Using On collision event (With the Collision group enabled)

Number of objects: 2464

FPS: 3-4

Collision checks per sec: 2048000-3100000

These are my tests that I just did, as it removes overlapping objects before checking collisions, there is a slight difference in amount of objects. But nothing that will change the results in any significant way.

But if you look at the collision per secs, which is from the debugger, it goes nuts on the On collision event, even when you remove the squares that are overlapping. So something is clearly not the same but there aint really a lot you can do with the "On collision" event as its part of C2 and cant be modified.

Number 3 uses a functionality that disable collision checking based on range. So adding something like this can increase performance quite a lot.

So what you have found is that :

-Using 'overlapping object' is only slightly better than 'on collision with object' when either condition is checked every tick.

-Using 'overlapping object' is significantly better than 'on collision with object' if it is checked only when the ball(for example) is within a certain specified range of the target object.

Well ill test it out and see what i find. Thanks for the help.

[quote:w6x57yis]

(Collision group is the name of the group in my program that does the distance checking, not something you find in C2)

1. Using overlapping (With the Collision group disabled)

Number of objects: 2490

FPS: 8-9

Collision checks per sec: 18000-21000

2. Using On collision event (With the Collision group disabled)

Number of objects: 2512

FPS: 2-3

Collision checks per sec: 1013025+

3. Using overlapping (With the Collision group Enabled)

Number of objects: 2501

FPS: 29-30

Collision checks per sec: 12000-15000

4. Using On collision event (With the Collision group enabled)

Number of objects: 2464

FPS: 3-4

Collision checks per sec: 2048000-3100000

These are my tests that I just did, as it removes overlapping objects before checking collisions, there is a slight difference in amount of objects. But nothing that will change the results in any significant way.

But if you look at the collision per secs, which is from the debugger, it goes nuts on the On collision event, even when you remove the squares that are overlapping. So something is clearly not the same but there aint really a lot you can do with the "On collision" event as its part of C2 and cant be modified.

Number 3 uses a functionality that disable collision checking based on range. So adding something like this can increase performance quite a lot.

Can I ask you why you'd need a group for distance checking? Wouldn't simple comparison of distance be enough?

• Distance < n

-- Is overlapping

--- do stuff

[quote:21y0ke04]Can I ask you why you'd need a group for distance checking? Wouldn't simple comparison of distance be enough?

• Distance < n

-- Is overlapping

--- do stuff

I guess you might be able to do that as well, but I haven't tested that, so not sure what performance that would get you. But from guessing I would assume that you would get worse performance, as you are just introducing another check for no apparent reason. You might as well just use "Is overlapping" without the distance check, as C2 will still check for overlapping regardless of that distance check.

What my group does is it actually turn Off/On whether an object should even be checked for collisions based on distance between objects. So as C2 checks for collisions for each object, suddenly there are far less objects (Those outside range) what it doesn't test against and therefore its basically a test whether its better to just make collision checks for each object, or if its worth using distance checks to turn off collision detection all together for certain objects, even though it requires a distance check to do it. And based on my testing at least it can in fact improve performance quite a lot, as to not doing it.

(Just disable the group called "Disable collision" to see the difference, and yes its a terrible group name )

[quote:3r8eqs02]What my group does is it actually turn Off/On whether an object should even be checked for collisions based on distance between objects.

Oh, i was using the 'distance>/<n' as megatronx was saying. I thought you were just using groups for your convenience.

I need to know how to do this, ill try to figure it out, but if you don't mind giving a quick tut.

And i noticed that instance variables aren't triggered or set as needed when the 'overlapping..' condition is met, it gets triggered or set when 'on collision..' conditions .

Oh thanks you put up an example.

[quote:3mnglyep]Can I ask you why you'd need a group for distance checking? Wouldn't simple comparison of distance be enough?

- Distance < n

-- Is overlapping

--- do stuff

I guess you might be able to do that as well, but I haven't tested that, so not sure what performance that would get you. But from guessing I would assume that you would get worse performance, as you are just introducing another check for no apparent reason. You might as well just use "Is overlapping" without the distance check, as C2 will still check for overlapping regardless of that distance check.

What my group does is it actually turn Off/On whether an object should even be checked for collisions based on distance between objects. So as C2 checks for collisions for each object, suddenly there are far less objects (Those outside range) what it doesn't test against and therefore its basically a test whether its better to just make collision checks for each object, or if its worth using distance checks to turn off collision detection all together for certain objects, even though it requires a distance check to do it. And based on my testing at least it can in fact improve performance quite a lot, as to not doing it.

(Just disable the group called "Disable collision" to see the difference, and yes its a terrible group name )

Thx for the capx, will check it when update to latest stable when will be released. Although, you do check for distance, right? So if distance is less then X, then you turn collisions off, yeah?

[quote:3f6l3apv]Thx for the capx, will check it when update to latest stable when will be released. Although, you do check for distance, right? So if distance is less then X, then you turn collisions off, yeah?

Yes and its fairly simple to add.

Here are the code:

As you can see its pretty straight forward to add.

[quote:32bv2yu0]Thx for the capx, will check it when update to latest stable when will be released. Although, you do check for distance, right? So if distance is less then X, then you turn collisions off, yeah?

Yes and its fairly simple to add.

Here are the code:

As you can see its pretty straight forward to add.

That's cool, but it wont work for a platformer at all ( cause enemies will fall trough floor)... unless you'd make your own behavior that will move the enemies across without need for collision checks with solids, something like : Check for overlap at offset -> decide on direction -> Check for terrain type ( as check if its straight, or rising etc ) -> Set destination X,Y -> turn this chain off, an set moving on -> Repeat the process on arrival.

[quote:x8i2uje6]That's cool, but it wont work for a platformer at all ( cause enemies will fall trough floor)... unless you'd make your own behavior that will move the enemies across without need for collision checks with solids, something like : Check for overlap at offset -> decide on direction -> Check for terrain type ( as check if its straight, or rising etc ) -> Set destination X,Y -> turn this chain off, an set moving on -> Repeat the process on arrival.

Yeah agree. There are some other problems with this approach as well, if objects doesn't have the same sizes, proportions, then I doubt it will work correctly.

But it was only created for testing purposes and never meant for being used in a project. So copy/pasting it to a game I doubt would work very well, but if you have a project which seems to suffer due to a lot of collisions checks, there might be a way to improve performance, if you spend some time on it.

I just implemented this form of distance-based collision enabling/disabling. It's drastically reduced my collision checks from a max of 200 down to like a max of 10. However the debugger claims far higher CPU % utilization. Exporting to the phone now to check whether this change increases performance due to collision checks reduced, or slaughters performance due to higher CPU utilization.

Edit: Yeah this destroys performance on mobile due to the higher CPU usage all the "For Each" loops cause. Collisions/tick average was about 4 compared to ~80+ though lol.

I did the same thing to my mobile game, but in my case there was a performance boost of about 20%. (went from 2000 checks to 0-40)

I suppose it has to do with the processor on the device, I test on a Galaxy S3.

I'd love to hear an expert's opinion on this.

Yup same here, a clear performance improvement. But i guess this depends on the number of objects you have for which you have to enable/disable collision.

But, after further testing this, I found that there is a limit to what can you do until it starts getting slow again.

If set every object in mi game to "collisions disabled" and make the game check distance for them in order to enable their collision when is going to be needed, the game actually gets slower. But if i only do it for the couple of objects that do the most interactions, the game performs better than without the distance enabling. And not even by much. but it clearly gets smoother. The rest of the objects interact so little with other things that they are better left by default.

I guess that's cause of the higher cpu usage ionC2 mentioned. So we can conclude that there will only be a noticeable performance improvement if we enable/disable collision only with objects that interact most frequently.