Collision cells, Hit or miss?

If you find it is slower with collision cells, please post a .capx demonstrating that with your FPS/performance details for each build. We can't help otherwise, and the majority of users say there is a big improvement.

I have uploaded the long awaited .Capx.--->

It's called "Improving upon the Performance!"

Take a Look Good Sir - All of our collective Trust rests upon You - You alone have the power to make things well...-

scirra.com/forum/improving-upon-the-performance_topic84725.html

STARTECHSTUDIOS Thanks for putting that up, not had chance myself, we will see if anything comes from it...

"the majority of users say there is a big improvement"

If that is the case, why are they not posting on this thread? that was my initial question...

Not really a performance problem, but there's another byproduct of the collision cell update that at least has affected me and the game I'm developing: particles no longer collide with sprites. I know (as Ashley has told me before) that particle and sprite collision was something not really supported or featured, and it may actually be some kind of hidden bug-feature, but I'm just stating it as it's my biggest concern with this update right now.

I'll put a link to my original post, where I also uploaded a capx in case anyone wants to look at it: scirra.com/forum/particles-sprites-and-collisions_topic84682.html

Kybele - post a bug report following all the guidelines or the problem won't be looked at.

So as STARTECHSTUDIOS reported (thanks for the clear repro!) there is an edge case with collision cells: turret behaviors with extremely long ranges can in some closes be slower. The turret behavior is not really designed for that, and it should be easy to work around. More details in this thread: http://www.scirra.com/forum/improving-upon-the-performance_topic84725.html

Ashley does the line of sight behavior cause similar issues? I have a layout with about 13 enemies spread over it and they have a pretty short line of site (300px or so) and that particular layout continues to generate upwards of 50K collision checks while all my others have dropped to less than 10K and in most cases less than 5K...

Ashley

Thanks for the quick reply and detailed response.

I greatly appreciate your concern for this topic...

Only one problem, the issue still exists in my current project which I have been working on for over 6 months...it is now broken.

I sent in a simple .capx and a detailed bug report, but the problem still remains unresolved.

So what are my choices:

Choice #1) Try to retool my project that has been finely tuned and was working perfectly before the update...

Choice #2) Use an older release of Construct 2 indefinitely :(

Choice #3) Ask the developers of Construct 2 on the forums to please help. (Personal Favorite)... :).

Choice #4) Throw in the 'Pixelated Towel.' Which I predict would probably lead me away from Construct 2...Most Disappointingly :(

I have posted a reply to your last message in the link:

scirra.com/forum/topic84725_post495791.html

Again, thank you for your attention to detail concerning this issue...it's great to have developers who are so responsive to the needs of their user base! You guys are Awesome!! Seriously... :D.

BluePhaze - quite possibly... but it still shouldn't be a problem unless you have loads of objects or can measure a reduction in framerate.

STARTECHSTUDIOS - as my post says, in theory #1 is straightforward: if you want turrets working over unlimited range, just replace them with events to always rotate towards the target.

Either way, I guess this proves edge cases exist where there's a big performance difference. I'll see if an option can be added to enable/disable collision cells after all.

Wouldn't it be better to just optimize the turret behavior and line of sight to work better in those edge cases? I.e. switch the turret off from collision cells if it detects that it's doing extra work...?

Ashley Thanks, yeah there is a big performance difference on that layout on mobile devices, the others run smooth, but that particular one stutters on many devices. And it is a much simpler layout than most of my others which have nowhere near the amount of collision checks happening. My only assumption is that it is the line of sight behavior. I have two sets of checks on that particular layout, the enemies test if they have collided with a particular type of sprite block (I originally had them checking against a family with all my terrain blocks, but changed it to see if it was causing the issue), and they also check to see if they have line of site with the player sprite as they patrol back and forth.

Somehow between these behaviors the 13 enemies are causing over 50k-90k collision checks. It is a bit crazy, luckily it is only one layout but it tends to kill performance. But with that said, it still performs better than it did with brute force. Brute force checks on that particular layout were doing 70-100k checks prior to the implementation of collision cells. So I am seeing the benefits, I just can't figure out this particular layouts issue.

Fimbul - it's very hard to define a specific point at which to switch over, and the switch point could always still make it slower depending on how many objects are involved. It's probably not practical.

BluePhaze - it's easy to test your theory: turn off the behavior and see if performance improves! Collision cells should never increase the collision checks count, but in some cases it may make each collision check more expensive.

Ashley, but do you even have to have a switch point? Wouldn't it be better if, instead of having the "use collision cells" be a project-wide setting, why not let it be a property of the turret/LoS behavior?

Fimbul - hmm, maybe - I'll see how easy it is to implement.

Ashley

Wow, thank you!

Can't wait to see the newest build!! :)