confusing performance

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?

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.

"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

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.

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

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.

Thanks for the clarification, think that was greatly needed

However in what circumstances is the extra functionality of "On collision" a benefit or where is it intended to be used? At least in my experience I mostly used it with bullets hitting an enemy and then the bullet is destroyed. However you say that it needs to keep track of when the separation happens and touch again. Where as "Is overlapping" doesn't do this and just checks for an overlap, which is really what you need when a bullet hits an enemy for instant as the bullet most likely is destroyed.

Im a bit uncertain how to formulate the question , but can you give an example where "On collision" would outshine "Is overlapping" meaning where the extra functionality is obvious or what to say? or if anyone else can? I would appreciate it, because im happy with the clarification, but sadly I still don't see the reason to use "On collision" over "Is overlapping", so an example would help me?

nimos100

Colludium already gave an example of this earlier in the thread. Using Overlap + Trigger Once, you may run into a situation where the the original object overlaps a second object while still having already overlapped the first one earlier in time. When this happens, Overlap + Trigger Once will fail to trigger.

This limitation can get exacerbated if you make use of families: Obj1 Overlap Family + Trigger Once.

For example, you have a Farmer object, and a Fruit Family which consists of three different objects Apple, Oranges, and Caimitos.

Your collision routine is:

Farmer Overlap FruitFamily + Trigger Once --> Spray the fruit with pesticide. (the fruit remains)
[/code:1092tdzb]

Here is a situation that might occur:
[ul]
[li] Farmer is walking quickly through the garden[/li]
[li] Farmer overlaps an Apple[/li]
[li] Overlap triggers and fruit is sprayed.[/li]
[li] Farmer sprite is fairly large and overlaps an Orange [/li]
[li] Since the farmer is still overlapping a FruitFamily (the apple), the overlap event will not be triggered.[/li][/ul]

So basically, the overlap will NOT trigger again until the farmer is not overlapping *[b]ANY[/b]* FruitFamily objects. On collision does not have this limitation.

CrudeMik

the debug mode automatically ads 20% cpu utilization if its shows 40 fps or 10% cpu utilization dont worrie about it if you run an old rig (core duo or smth under i5)

Thanks for the clarification, think that was greatly needed

However in what circumstances is the extra functionality of "On collision" a benefit or where is it intended to be used? At least in my experience I mostly used it with bullets hitting an enemy and then the bullet is destroyed. However you say that it needs to keep track of when the separation happens and touch again. Where as "Is overlapping" doesn't do this and just checks for an overlap, which is really what you need when a bullet hits an enemy for instant as the bullet most likely is destroyed.

Im a bit uncertain how to formulate the question , but can you give an example where "On collision" would outshine "Is overlapping" meaning where the extra functionality is obvious or what to say? or if anyone else can? I would appreciate it, because im happy with the clarification, but sadly I still don't see the reason to use "On collision" over "Is overlapping", so an example would help me?

A beam weapon that expands and hits an enemy, then keeps going and hits more enemies.

If you use Is Overlap, it will trigger many times on each enemy hit. If you add Trigger Once to it, it sometimes does not trigger on the subsequent enemy hits so the AoE is not reliable.

On Col works and trigger once for each instance and it will hit as many instance as it needs, but once only, very reliable.

The same applies for other AoE weapons, like an expanding nova or EMP circle, shockwaves, etc. On Col is 100% reliable.

—

[quote:2wp8gbis]If you use Is Overlap, it will trigger many times on each enemy hit. If you add Trigger Once to it, it sometimes does not trigger on the subsequent enemy hits so the AoE is not reliable.

See my earlier explanation, it explains why this happens. It is expected behavior and by-design.

Bottom-line:

"On Overlap + Trigger Once" keeps track at a per-Object Type/Family Level.

"On Collision" keeps track at a per-UID level.

See my earlier explanation, it explains why this happens. It is expected behavior and by-design.

Bottom-line:

"On Overlap + Trigger Once" keeps track at a per-Object Type/Family Level.

"On Collision" keeps track at a per-UID level.

Yes, its good to now know the pros & cons of both approach, where possible, use Is Overlap with Trigger Once, or without it with bullets that destroy themselves etc, since On Col has added overhead and should be used where required.

I had not considered using Is Overlap because I've always went with On Col, but definitely in future, where Is Overlap works fine, that should be used to optimize the game. With lots of col checks, such optimizations leads to major performance gains.

There's probably no performance difference between 'Is overlapping' and 'On collision' if you immediately destroy the object, since it then doesn't require any tracking since it doesn't exist any more. However you probably want to use 'On collision' for correctness since it picks instances for individual collisions. For example:

+ On collision between A and B

-> System: create explosion at A.X, A.Y

-> Destroy A

-> Destroy B

Note the use of a system action. This always works like you expect: an explosion is created with every collision.

+ Is A overlapping B

-> System: create explosion at A.X, A.Y

-> Destroy A

-> Destroy B

This has a nasty edge case: if two different A-B pairs overlap each other for the first time in the same tick, it will run the event with both pairs picked. The system action then runs once, creating only one explosion (and the A.X, A.Y expressions will return the position of just one of the two objects involved). Both sets of objects are correctly destroyed, but you only got one explosion. You can fix that again with "For each", but then you may as well just use "On collision".

ok I see your points, appreciated, thanks for that

yes then its better to use "on collision" ...

but why the cpu usage drop to 20 % when we use is overlap instead of using on collisions