confusing performance

Colludium

I tested your capx, On Col was using 94% CPU versus around 10% of Is Overlap with Trigger Once.

— - I had about the same - the On-Collision has a massive and surprising overhead to it. I would certainly use Overlap / Trigger Once if the situation allows; however, if you need to know whenever a collision happens to a new object, while another similar object is overlapping, the On Collision trigger seems to be the simple way to go (although I'm sure that you could use Overlap with an array for a much better result in situations like this). I'm pretty sure that Ashley said in another thread that the two methods in that example are essentially identical - but that clearly isn't the case!

...Just to add - the main difference is that a second or subsequent overlap condition will not be registered by using overlap/trigger once, whereas the On Collision does detect multiple occurrences of collisions between multiple objects.

Each bullet has to check against enemies, each enemy has a separate left & right shield which when depleted, the collision is ignored and checks if it collides with the hull afterwards. Drones also check for collision to enable/disable some movement.

Looking at your collision count in the screenshot, even though you have 1300+ objects, it doesn't actually do a lot of collision checks (approx. 115 / t). Which obvious is because it not 900-1200 bullets, but mostly all kinds of other objects. But you could try for fun to increase the fire rate of your ships and maybe set the bullet damage to 0 or something and just really let the ships fire like crazy to crank up the numbers of bullets and see how much performance drops and how quickly. Because with low amount of objects, you wont really see a huge difference. And 115 /t collisions are very low already, which ofc is just good that you don't need more.

— - I had about the same - the On-Collision has a massive and surprising overhead to it. I would certainly use Overlap / Trigger Once if the situation allows; however, if you need to know whenever a collision happens to a new object, while another similar object is overlapping, the On Collision trigger seems to be the simple way to go (although I'm sure that you could use Overlap with an array for a much better result in situations like this). I'm pretty sure that Ashley said in another thread that the two methods in that example are essentially identical - but that clearly isn't the case!

In my context, most of the col occur with bullets or lasers and such so I can do Is Overlap -> disable collision of bullet & spawn various effects then destroy bullet. So it only triggers once.

On Col seem to have a very high overhead and its limiting the CPU in other ways, because even in situations where its 40% CPU usage, the fps isn't 60, its down to ~40.

I think this is a big deal, we should ask Ashley about this.

Number of objects too large

FYI to everyone: debug readings are not to be trusted. If you really want to run comparisons, make a spritefont readout and populate it with fps/cpu/objCount/etc.

Anyway: When I experimented with this back a few months ago, my impression was that 'on collision' and 'is overlapping' tended to be similar to each other vis-a-vis CPU usage. However, when pushed really hard (bullet hell shooter with thousands of bullets), 'is overlapping' had pretty consistent performance, whereas 'on collision' seemed to cause more instances of stutter and slowdown, even if the average CPU/FPS was the same.

Interesting findings. I'm seeing a improvement by doing this (image below), though compared with the complex collision checks going on in the other event sheets, this is still taking up the most % which I don't quite get. As TiAm says though debug readings are not 100% accurate.

Hasuak - yes I have very silly naming conventions haha.

FYI to everyone: debug readings are not to be trusted. If you really want to run comparisons, make a spritefont readout and populate it with fps/cpu/objCount/etc.

Anyway: When I experimented with this back a few months ago, my impression was that 'on collision' and 'is overlapping' tended to be similar to each other vis-a-vis CPU usage. However, when pushed really hard (bullet hell shooter with thousands of bullets), 'is overlapping' had pretty consistent performance, whereas 'on collision' seemed to cause more instances of stutter and slowdown, even if the average CPU/FPS was the same.

I know that the readings are not 100% accurate, but I don't see the huge importance in that, as stated earlier, its not that important whether its 90.1% CPU Util or 91.3%. But that you can and will see a difference in performance and a severe FPS drop, which you don't have to measure really because you can see everything is lagging around.

According to the r155 collision changes that someone posted earlier, not all of it seems to be working as stated there. It says that for optimal performance it is suggested that you put "Is overlapping" before any other picking condition to avoid C2 having to brute force collision checks. However in another program I made for testing collision, I get better performance (10-13 FPS improvement) when putting "Is overlapping" as the last condition, after Im done with the picking conditions, which should make it brute force and therefore give worse performance, but its the exact opposite from my experience at least. And that test is with 1700-2000 moving objects, so 10-13 fps is not a small increase.

(After running it again, its actually more like 17-23 fps with 1740 object)

It's as if is-overlapping uses collision cells but on-collision does a brute force check of the objects....

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)

[quote:1ts1pur8]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.

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...

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)

[quote:2iv7jitu]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

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.