confusing performance

asteroid overllaping wth asteroid is the culprit, it will cause asteroid.count^2 collision checks per tick If I am correct.

overllaping and on collisions are actually similar, sometimes you can gain a little with overllaping as it is not checked as much in case of movement or creation.

also disabling collisions between the player and a far away asteroid could be in some cases a complete de-optimisation as if they are not in the same collision cell, no check is done, so make measurement first.

overllaping and on collisions are actually similar, sometimes you can gain a little with overllaping as it is not checked as much in case of movement or creation.

There is a difference between them as I see it. Take this example, this program does absolutely nothing at all. The code you see is all there is. I let it run for a few seconds so it settles. One is disabled for each test ofc.

Check the CPU util...now if I increase the number of yellow squares and still this program does nothing at all, than check the CPU changes.

If these functions are the same then how would you explain the severe increase CPU util from one to the other, when the program doesn't do anything? I agree with you that according to the manual they do the same, but clearly they do not give the same performance.

CrudeMik About optimizing collisions, read this: https://www.scirra.com/blog/ashley/6/co ... on-in-r155

IsOverlapping & OnCollision both use collision cell optimization, so there's no need to filter down the number of checked instances. From that blog: "If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells."

In the events you've shown, the 'asteroids OnCollision with ass_destroyer' is fine, but as you said the 'family asteroids IsOverlapping family asteroids' is expensive if it runs every tick. But I think you've only got that happening at the start. So I'm not sure where the problem is.

nimos100 not sure but AFAIK the debbuger can add an overhead, to be really fair you also have to make them behave the exact same way too to really evaluate a waste between the two (is overllapping does not have to verify if it was already colliding with the same exact instance in the past, while on collision does, also not sure what happens if you have 2 collisions at the same time that occurs between 1 sprite2 and 2 sprite in the same tick between on collision and is overllaping).

but that is interesting.

Its primarily the "On collision" under setup, try to disable that and let it run again. You shouldn't use "On collision" it is a performance killer

and what you suggest to replace "on collision" ?

overlapping ?

and what is the difference between them

I think event 4 would run smoother if you do it with a foreach combined .... not sure, but a similar situation helped with me.

Cause the way it runs now, it tries to check everything simultaneous.

event

for each fam asstroids

sub

fam astroids is overlapping fam astroids

trigger once

action

destroy fam astroids

If I am not mistaken, this will make the checking run consecutively.

Sorry to be off topic, but your naming conventions are epic. Ass_destroyer.

On topic now!

Limit collision checks. Maybe if objects are off screen you don't care about them? So it might be possible to disable collisions on those objects.

And when objects get a certain range or leave the layout it may be possible to destroy them.

The key is removing objects you don't need. And only doing logic with objects relevant.

nimos100 not sure but AFAIK the debbuger can add an overhead, to be really fair you also have to make them behave the exact same way too to really evaluate a waste between the two (is overllapping does not have to verify if it was already colliding with the same exact instance in the past, while on collision does, also not sure what happens if you have 2 collisions at the same time that occurs between 1 sprite2 and 2 sprite in the same tick between on collision and is overllaping).

but that is interesting.

Im not sure what you mean, what im showing is if you are testing for collisions using the two ways there are. Why waste is important im not sure, because if I increase the number of yellow squares the one using "On collision" will eventually drop in FPS due to amount of objects before the "Is overlapping". So im not looking for exact numbers, just that you can improve performance using one way over the other. Can you explain what you mean differently because Im not sure I understand what you mean?

> Its primarily the "On collision" under setup, try to disable that and let it run again. You shouldn't use "On collision" it is a performance killer

>

and what you suggest to replace "on collision" ?

overlapping ?

and what is the difference between them

Yeah I would replace "On collision" with overlapping due to performance. I don't know what the difference is, but just that you loose performance using "On collision" it can easily be tested, just make a program as in my example.

> I find no difference between On collision or Is Overlap.

>

That sounds weird, because there is no doubt when I test it that I get a huge difference in performance, do you have any data to show, that would be interesting to see?

Like how many objects etc. would like to see that.

~1400 objects peak, 60% CPU usage. No difference in CPU usage with On Col or Is Overlap. No difference in collision checks per tick.

>

> > I find no difference between On collision or Is Overlap.

> >

>

> That sounds weird, because there is no doubt when I test it that I get a huge difference in performance, do you have any data to show, that would be interesting to see?

>

> Like how many objects etc. would like to see that.

>

~1400 objects peak, 60% CPU usage. No difference in CPU usage with On Col or Is Overlap. No difference in collision checks per tick.

That makes no sense, that would kill/slow down my game if there was so many objects with "On collision". Can you do me another favour and run this program, or if anyone else could as well. And just disable "On collision" and enable "Is overlapping" and next try the other way around and screenshot the debug performance window. Because it seems strange that it would be that different. Have you done anything special with your "On collision"?.

[attachment=0:dissnu67][/attachment:dissnu67]

The results I get from this is these which uses 1024 objects:

nimos100 I get almost the same results as you.

That makes no sense, that would kill/slow down my game if there was so many objects with "On collision". Can you do me another favour and run this program, or if anyone else could as well. And just disable "On collision" and enable "Is overlapping" and next try the other way around and screenshot the debug performance window. Because it seems strange that it would be that different. Have you done anything special with your "On collision"?.

Your capx works as you say.

Give your sprites random bullet movement and then test with On Col vs Is Overlap. I suspect the behavior may change with a sprite that's constantly moving to one that is stationary.

Here's my debug shot.

[attachment=0:21q5k87z][/attachment:21q5k87z]

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.

There's some fights that happen off-screen that also needs to be calculated.

I have very low collision checks per tick though (much less than your examples), most of the calculations go for AI position, distance, angle, and lots of variables, so perhaps in my case, any efficiency gains with Is Overlap won't make much of a difference.

What's interesting is I took your capx, and did the On Col check AFTER a "Every 0.1 seconds" trigger.

[attachment=0:2zy7tnfp][/attachment:2zy7tnfp]

The Col per tick drop as expected as well as CPU usage went down to ~40%. BUT, fps is capped at much lower than 60 fps.

This does not occur for Is Overlap under the same scenario, CPU usage also went down but fps is 60.

There is something fundamentally bottlenecking On Col, causing a higher overhead that is limiting the rendering.

This needs an official input from Scirra. There is a large performance penalty associated with On Col vs Is Overlap.

This is quite an interesting finding but there is a marked differences between using "is-overlapping" with a "trigger once" compared to using the "on-collision" trigger. I've messed around with the example above to demonstrate this. This version includes drag and drop behavior, so you can select a green or purple square and drag it over the squares of the other color. Because of the squares' dimensions, if you drag a square to the other side of the screen it never stops overlapping at least one of the other types of object. Give it a try and you'll see different results for testing for an overlap and testing for a collision trigger. I added a text object to show the cpu time and fps, in case the debugger added some overhead that muddled the findings.

So, never say never use on-collision - just be aware of what you are asking the engine to test for.