confusing performance

Discussion and feedback on Construct 2

Post » Sat Feb 28, 2015 12:09 pm

It's as if is-overlapping uses collision cells but on-collision does a brute force check of the objects....
B
68
S
17
G
65
Posts: 2,182
Reputation: 41,304

Post » Sat Feb 28, 2015 3:47 pm

@Colludium

Unfortunately, even if the window and layout dimensions are identical (which means C2 only creates a single cell, https://www.scirra.com/blog/ashley/6/collision-cell-optimisation-in-r155), I still see the same performance degradation with the collision_test_capx sample.

Oddly, I've never run into this issue even with thousands of objects in a level with "On Collision" because I have a hibernation system that periodically puts objects that are too far away from the player into a "suspended state". Then, I have upper-level picking conditions filter only active objects before the "On Collision" subevent.

This is in contrast to C2 best practices: (quote from @Ashley)
Make sure collision conditions are the first condition in the top-level event. When no objects are picked, the collision conditions can make efficient use of collision cells to reduce the number of checks made, ensuring performance is good in all circumstances.

If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells ... If a prior condition picked a large number of instances, it must brute-force collision checks again.


I agree with what everyone has said so far, I'd love to get some official feedback about this.
B
31
S
7
G
8
Posts: 232
Reputation: 6,214

Post » Sat Feb 28, 2015 5:16 pm

@cacotigon - good point re collision cells and the performance difference; I didn't check the cell count when I was looking at it. It's like the engine is doing a for-loop check of each object for the on-collision trigger check...
B
68
S
17
G
65
Posts: 2,182
Reputation: 41,304

Post » Sun Mar 01, 2015 2:25 am

cacotigon wrote:@Colludium

Unfortunately, even if the window and layout dimensions are identical (which means C2 only creates a single cell, https://www.scirra.com/blog/ashley/6/collision-cell-optimisation-in-r155), I still see the same performance degradation with the collision_test_capx sample.

Oddly, I've never run into this issue even with thousands of objects in a level with "On Collision" because I have a hibernation system that periodically puts objects that are too far away from the player into a "suspended state". Then, I have upper-level picking conditions filter only active objects before the "On Collision" subevent.

This is in contrast to C2 best practices: (quote from @Ashley)
Make sure collision conditions are the first condition in the top-level event. When no objects are picked, the collision conditions can make efficient use of collision cells to reduce the number of checks made, ensuring performance is good in all circumstances.

If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells ... If a prior condition picked a large number of instances, it must brute-force collision checks again.


I agree with what everyone has said so far, I'd love to get some official feedback about this.


hi
what does mean this "Make sure collision conditions are the first condition in the top-level event" ?

and as ashley say "is overlape=cell collisions (new method)" and "on collisions=brute force (old method)

so i think we should use is overlapping method for betterperformance
B
38
S
11
G
4
Posts: 712
Reputation: 5,471

Post » Sun Mar 01, 2015 4:09 am

matrixreal wrote:hi
what does mean this "Make sure collision conditions are the first condition in the top-level event" ?

and as ashley say "is overlape=cell collisions (new method)" and "on collisions=brute force (old method)

so i think we should use is overlapping method for betterperformance


Hi, that's not what Ashley says in the blog in the r155 blog (link).

In "The new way: collision cells" he says: "It includes Sprite's On collision and Is overlapping conditions... "

and in Caveat 2 he says: "If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells. Looking in collision cells returns all possible instances, not just those that have met prior conditions. If a prior condition picked a large number of instances, it must brute-force collision checks again."

Thus the official line is that On-Collision will use collision cells providing the collision check is the first event in an event group that picks or filters instances of an object.
B
68
S
17
G
65
Posts: 2,182
Reputation: 41,304

Post » Sun Mar 01, 2015 9:54 am

i dont get it, can someone please post a image of how you must do this¿

"Make sure collision conditions are the first condition in the top-level event"

how it would look like in a event sheet?

is

is overlapping
>>>> >damage = 0

or

is overlapping
damage = 0

can someone please explain me?
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

Post » Sun Mar 01, 2015 10:54 am

Lunatrap wrote:i dont get it, can someone please post a image of how you must do this¿

"Make sure collision conditions are the first condition in the top-level event"

how it would look like in a event sheet?

is

is overlapping
>>>> >damage = 0

or

is overlapping
damage = 0

can someone please explain me?


As far as I understand it, it shouldn't matter, what is important is that you don't pick any objects first, since that is what should disable the collision cells and force brute force. So both your examples are correct or the way it should be according to r155.
B
44
S
11
G
2
Posts: 1,181
Reputation: 6,801

Post » Sun Mar 01, 2015 11:21 am

Lunatrap wrote: "Make sure collision conditions are the first condition in the top-level event"


But then again you should put them first, since that will improve performances regardless of what is stated in r155 as some others have mentioned as well :D

Ashley and those did some tests that are in r155, which clearly shows improvements, so something must have happened from there to now, because I doubt they would have missed this performance difference if they tested both of them back then, especially because in there tests they also uses a lot of objects and you don't really need any numbers to see that there is a difference between them.
B
44
S
11
G
2
Posts: 1,181
Reputation: 6,801

Post » Sun Mar 01, 2015 11:41 am

'On collision' does more work than 'Is overlapping', so it makes sense that it's slower. It's probably not obvious to you what the extra work is though. It has to fire once per pair of overlapping instances, and not fire again until they separate and touch again. This tracking work is pretty complicated and has to track things over time, since it has to remember if it's fired 'On collision' for an existing pair of instances that are already touching. On the other hand 'Is overlapping' just makes a collision check on the spot and doesn't need to remember or track anything.

Both ways still use collision cells though so scale well to large layouts.
Scirra Founder
B
378
S
219
G
84
Posts: 23,863
Reputation: 187,919

Post » Sun Mar 01, 2015 11:50 am

Thanks, that makes a lot of sense now. There's definitely places where Is Overlap is a better way and again, other situations where On Col is better.
B
67
S
24
G
19
Posts: 1,754
Reputation: 17,526

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests