Picking Performance test.

I was having some performance issues and tried to figure out what caused it, but i was pretty sure it had to do something about the picking. So i created a new scene to test it out, and these were the results.

In my game i was using evaluate a lot, which seems to be very heavy on CPU. I was using it mostly because it looked neat to have everything in the same condition. But after doing this test I probably have to rethink a lot of my picking. Could anyone with deeper knowledge explain why some method is better than the other?

capx:

https://dl.dropboxusercontent.com/u/20560446/Scirra/pickperformance.capx

My idea for the difference between 'windowidth Evaluate' and 'windowidth Condition'. The 'windowidth Condition' uses short-circuit evaluation, the 'windowidth evaluate' the normal logical and operator.

https://en.wikipedia.org/wiki/Short-circuit_evaluation

Those using the system conditions are likely iterating over all instances, and possible objects that you aren't even picking.

Is on screen, and other filters can help with that.

The object / instance triggers are the best method, as they would likely pick the fewest instances.

biggest problem is that this runs ~60 times per sec. when you do a game you don't use that 60 times a sec. or you can lower it to 10x a sec or such.

but best thing to use is, as newt said triggers.

That is only one half of the story your capx tells.

Yes, you can pick based on a lot of things. In the end, this is not what really matters.

Because, see, you pick now those objects that you want to give the state 'state'. You still have to pick the others go give them the state 'unstate'. I dont know what you plan to do, set them solid/not solid ... colission/not ... lets just call it 'state'.

You gonna make Two internal loops, one for the 'state' and one for the 'unstate', if you do it this way. Not really optimized. You dont have the 'unstate' coverd in that capx, why i say its half the story.

Try to do it in 1 loop. 2 Examples in here.

https://www.dropbox.com/s/jhiouuxy5jemq ... .capx?dl=0

The point seems to be the filtering. Here's an image and capx of different events doing exactly the same thing.

1. First way is super heavy as it does not filter at all, goes through all and does it.

2. Second way is a bit cheaper as it filters by is on screen first. Very useful.

3. Even better is this weird way. On par with behaviours. First Checking opacity across the entire layout, picking the closest one setting it to 50, moving on to the next closest one setting it to 50, until it reached the distance limit of 150. Another event does the reverse thing to set it back to original opacity outside the distance limit. Super cheap and efficient.

4. Using the Line of Sight behaviour to do exactly the same thing, sligtly cheaper than no.3. Line of sight can even replace "is on screen" as an even cheaper substitute for filtering by screen size if you set the radius slightly bigger than the window width.

Conclusion, there are some good ways to do things and some bad ways. So far line of sight, and 'pick nearest/furthest' seems to be the most efficient ways to pick/filter.

capx:

https://dl.dropboxusercontent.com/u/20560446/Scirra/differentways.capx