The collision cell ambiguity issue

Arima, You often mention that you can just dump a lot of events under a "object > 0" to be more efficient with events, but would this not be contrary to how Ashley has explained the collision cell system (which is as far as I understand the only way collision should be done).

https://www.scirra.com/blog/ashley/6/co ... on-in-r155

[quote:28xpwteo]To avoid this, our new advice is: 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.

So it seems clear to just put overlaps as a top level event and condition (nothing above it) if we want to gain the benefits of cell optimization.

[quote:28xpwteo]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.

But this statement brings up ambiguity, so it's saying that if the overlap comes after only "certain instances" or "large number of instances" it won't work — this implies that there are some unspecified circumstances where we can have the overlaps use cell optimisation when placed after other events/conditions, but what are they? It's too annoying to test, since the debugger doesn't distinguish between cell optimized collision checks and brute force collision checks.

If it was "If Instance.Var = 10", then that would need to be below the collision, rather than above, but what Arima said, I understood this as the top picking event, not a condition to see if the object actually existed.

o yea

Yeah, system>compare values doesn't do any picking so it should be fine.

The collision check conditions only need to be the first condition that picks for that object type. (It's just easier to phrase the advice as "make it the first condition".) You can actually have any number of conditions either in the System object or unrelated object types, so long as the first condition in the whole event branch that picks from that object type is the collision check event - then it still uses collision cells.

You can still get away with picking instances before the collision check, as long as you pick a few instances. For example:

+ Sprite: pick a single instance

+ Sprite: test overlap with Sprite2

-> actions

This doesn't use collision cells, but only needs to collision check a single instance, so is fast anyway. However if you did:

+ Sprite: pick 1000 instances

+ Sprite: test overlap with Sprite2

This doesn't use collision cells and forces 1000 collision checks. If you put the conditions the other way round it would likely have done fewer collision checks based on objects in the same cell. Whether or not you can get away with this depends on how many instances you pick and whether it's less than the number of objects in the collision cell, which is pretty hard to estimate. Therefore the recommendation is to always put the collision check first, since it removes the worst-case possibility of forcing a large number of collision checks.

I'm a bit confused.

I have 20 instances of same object with variable

10 of them have variable set to 0, other 10 set to 1.

And they just moving around layout within its borders.

+System: Pick Sprite where Sprite.Variable = 1

+Sprite: Is overlapping Sprite

-> Sprite: Flash

In debugger it shows:

Collision checks/sec = 5400 (~90/tick)

Poly checks/sec = ~2 (~5/tick)

Moved cell/sec = 0 (~0/tick)

Cell count = 0

but if I do

+Sprite: Is overlapping Sprite

+System: Pick Sprite where Sprite.Variable = 1

-> Sprite: Flash

In debugger it shows

Collision checks/sec = ~22900 (~380/tick)

Poly checks/sec = ~240 (~8/tick)

Moved cell/sec = goes from 0 to 9 (~0/tick)

Cell count = goes from 1 to 3

So how Collision cells optimization works if I get much more collision checks? and it's only 20 instances

Tested on r164.2

That's odd, maybe cell optimization either isn't working at all or the debugger is silly?

No, it's just 'Sprite overlaps Sprite' requires N^2 checks. The first event picks 10 instances then needs 10x9 = 90 collision checks (not 10x10 since it doesn't have to check if it overlaps itself, only the others). The second does the collision check first needing 20x19 = 380 collision checks, then filters them down to the 10 with the variable set. I presume your layout is the size of the window? In this case collision cells have no effect. They work best when objects are distributed over a large layout.

I presume your layout is the size of the window? In this case collision cells have no effect. They work best when objects are distributed over a large layout.

Ahh, so thats is. You should mention this in your blog post, that it works only when layout size is bigger than window size.

Just tested it and yes they are working fine on large layout.

Thanks for clearing this out.