r155 Collision Cells

After reading the beta post for r155 about Collision Cells it seems to me this would also make a very useful Picker Condition... for example if I have a very large level / layout as is described in that post I would also like to do AI logic less often the further away an NPC is from the player cell without doing a distance check on every single NPC in the layout... there are probably other such things where game devs could reduce work based on these cells.

I like the cells. I wanted Quadtree, but this is still vastly better than brute force and imporantly the factor of implementation.

I would also like to determine the cell size. I have a game where the entire concept is LOTS of objects. being able to set the cell size would be very helpful as the game takes place on one screen.

I could possibly add a "pick objects in same cell" type condition so you can make similar kinds of efficiency gains in events as well. However it would only have an effect when it's the first condition - the blog post I made about the optimisation covers why.

It is rarely true that logic can only be coded one way. So if I know that I can get larger performance gains by architecting the events so that they start off with picking by cell then doing other picking down below then that is how I would do it.

Not to just keep piling on (however if it would require about the same amount of work on your side...)

It might be logical to want to know what objects are in your current cell plus all the cells adjacent ... so you can spin up their AI (or whatever) as the player is approaching.

"Is on screen" maybe, or would los behavior work?

A simple distance() behavior would be nice.

Onscreen would probably just limit to the already established cell collision. If not it would still brute force.

As for distance() i'm 90% that would still run on only brute force as distance isn't part of cell collision.

"It is rarely true that logic can only be coded one way"

True, but I suspect this is based on archetictual limits. Requireing some changes would probably require some fundamental low level changes which could have some serious repurcussions.

but I agree, being able to the cell object list and *cough* cell resize would be great :)

Ashley, two questions about collision cells:

will the top level+first condition requirement for using the cells always be true?

also, in many cases I am filtering to one specific instance before doing a collision check (with another filtered single instance of another object).. am i right in thinking that in this case, there's no 'brute forcing' and as such, there is no advantage to trying to make them top level conditions in order to use the collision cells.

keepee - it will probably always be true, yes, because once another condition has filtered some instances you can't look in collision cells any more since the cells contain all instances.

You might still want to put collision checks at the top, even with other conditions. It depends on your project. If you have 1000 instances, a condition that filters down to a single instance still has to check the condition against all 1000 instances. The collision cells optimisation is unique in that it has the ability to only check the instances that happen to be in the same cell (assuming they're all fairly spread out), which could be a lot less, and then the next condition only needs to check those meeting the overlap condition. But the overlap condition could be more expensive if a lot of poly checks are being done.

Overall I'd advise it's probably best to still put collision/overlap conditions at the top. When you get to very large numbers of instances, they are actually a lot more efficient due to not even having to check many instances, which can save you having to run ordinary conditions on lots of instances too.

So instead of doing a scan potentially across 1000 objects with the "Pick instance with UID" condition looking for a matching UID... you would only scan for a matching UID on the objects in that Cell.

Ashley, okay cheers

is it just conditions that filter instances that stop the cell method?

It's okay to have them under other non-filtering conditions, functions and groups, right?

ggibson1

"..only scan for a matching UID on the objects in that Cell"

well, anything post-collision check would already be filtered down to those instances overlapping

Oh, 'Pick by UID' is another exception: it can immediately pick the correct instance without having to look at all of them.

And yes, it only actually needs to be the first condition for that object type. Other unrelated conditions or groups can be above it.

Ashley, pick by UID is actaully what i was using in the earlier post,

it's interesting for a situation i'm in because i'm picking by UID before collision checking, and a few events later I need to collision check against many instances.

But the whole thing is within a 'For Each ..' event which makes it awkward to separate out the latter half into a top level event to make use of the collision cell.

I'll have a crack anyway, thanks again

Thanks for the further explanation Ashley, that might be useful to know in the manual entries too.

is there a way to tell which collision mode is on? like in debugger? my game has large layout with quite a few collision objects, thought it would make a difference in this release, but i dont see improvement of fps on ipad3, which was running at 30fps unchanged.