# Collision check question.

Get help using Construct 2

### » Sun Apr 20, 2014 6:34 am

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?
B
19
S
5
Posts: 155
Reputation: 1,663

### » Sun Apr 20, 2014 10:03 am

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:

(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.
B
45
S
12
G
3
Posts: 1,210
Reputation: 7,559

### » Sun Apr 20, 2014 1:55 pm

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.
B
19
S
5
Posts: 155
Reputation: 1,663

### » Sun Apr 20, 2014 2:21 pm

nimos100 wrote:
(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
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
93
S
30
G
22
Posts: 1,987
Reputation: 20,203

### » Sun Apr 20, 2014 2:39 pm

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 )
You do not have the required permissions to view the files attached to this post.
B
45
S
12
G
3
Posts: 1,210
Reputation: 7,559

### » Sun Apr 20, 2014 2:53 pm

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.
B
19
S
5
Posts: 155
Reputation: 1,663

### » Sun Apr 20, 2014 3:09 pm

nimos100 wrote:
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?
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
93
S
30
G
22
Posts: 1,987
Reputation: 20,203

### » Sun Apr 20, 2014 3:24 pm

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.
B
45
S
12
G
3
Posts: 1,210
Reputation: 7,559

### » Sun Apr 20, 2014 3:36 pm

nimos100 wrote:
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.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
93
S
30
G
22
Posts: 1,987
Reputation: 20,203

### » Mon Apr 21, 2014 12:29 am

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.
B
45
S
12
G
3
Posts: 1,210
Reputation: 7,559

Next