Improving upon the Performance!

Link to .capx file (required! If link is blocked remove the http and www parts):

https://drive.google.com/file/d/0B_4xfuagH96rMHo4TlFHVm5EUlU/edit?usp=sharing

Steps to reproduce:
1. Install R-154 of Construct 2.
2. Run .Capx: (Notice the even and Steady framerate)...
3. Now Install R-158.2 of Construct 2...
4. Run .Capx: (Notice the Dramatic Difference in Framerate of R-158.2 WHILE RUNNING THE EXACT SAME .CAPX)...

Observed result:
Unequivocally, R-154 is far smoother than R-158.2, though the opposite should have Occurred...

Expected result:
I would Expect R-158.2 would have Much Better Performance than R-154

Browsers affected:
Chrome: Yes
Android 4.3: Yes

Operating system & service pack:
Windows 7 64-Bit.

Construct 2 version:
R-154 And R-158.2STARTECHSTUDIOS2014-01-28 05:52:26

I tested this Capx with Win7-64 system with R155 and R159 (on debug mode) using both latest FFox and Chrome and can confirm that the later version of Construct is definitely slower.

On 155 frame rates keep on close to 60 (with cpu load around 20%) but on 159 frame rate drops to single digits with cpu 100%.

[Ashley]

The Turret behavior now uses collision cells to avoid having to check lots of objects. This is good for games like RTSs, where you have loads of objects. In this case you just have one player object so it doesn't benefit so much.

The problem is the turret range is set to 10,000 - which seems excessive, it's the size of the entire layout. This is inefficient, since surely you don't want to bother dealing with turrets very far away from the player? It would be faster to simply ignore those turrets.

Collision cells mean that checking a 10,000 pixel radius involves checking a few hundred collision cells. Since you've told every turret to detect range over the entire layout, then created over a thousand turrets, it's now checking hundreds of thousands of collision cells. Before collision cells it would have only checked the player directly, so it is indeed doing a lot more work. So this is indeed a worst-case-scenario for collision cells. However if you had a reasonable turret range and hundreds of Player objects spread out over the layout, collision cells would make this far, far faster than not using collision cells (as is true of many other cases).

Basically this is mis-use of the turret behavior. Hit the range down to 1000, and the game appears to function identically but at an easy 60 FPS. If you could reduce the range further it would be even more efficient. If you want to detect the player over an infinite range, don't use the turret behavior - just use an 'every tick, rotate towards player' event (which effectively does a turret behavior over infinite range while circumventing collision cells).

Collision cells do make a trade-off, and some edge cases like this may be slower, but it should be easy to work around. Note this is also specific to the Turret behavior's use of collision cells, and does not affect collision cells in general. Closing as won't fix.Ashley2014-01-28 13:06:44

Considering the fact that not only my performance decreased after updating to collision cells, but also the performance of the projects of others which they have undoubtedly been working on for quite a while in some cases; perhaps the best option would be to leave collision cells on at default, but at least give users the option of turning them on or off...then the user could choose whatever option gives him/her the best performance (fine tuning the engine as it were, as is the case with many other features of Construct 2 such as pixel rounding, linear/point sampling, etc, etc.) This seems appropriate considering the fact that all of us are [aspiring] software developers after all...Doesn't that seem reasonable/logical?STARTECHSTUDIOS2014-01-28 23:11:59

Otherwise, I'll have to stick with release 154 forever...which doesn't sound very fun :(

same here, ill downgrade to 154, i spend two day optimizing a sh*tty game on debug with 40 objects(5 present on screen at a time) and 30 events, just to notice that there is no point. I know the technology is new and hipsterish, i personally hate it, since it barely performs well, but i got used to the engine, its nice(ignoring the editor which is flawed, needs a lot of work, and some of the functions..). Flash is 100x faster, and you dont have to spend days on debug, to optimize, unless you screw big time.

hopefully is just a temporary setback, but if it continues like this, ill drop it in heart bit, even if it means i will work more for my games, at least they will perform well.

[Ashley]

There is already an option to disable collision cells in the Turret and LOS behaviors, which are currently the only known sources of worse performance with collision cells.

I think it's great that performance is high on C2 priorities, and I really appreciate any development in that area, but for some projects the trade off is too much...

The problem is, the pivot point for this performance "trade off" is difficult to define, a global on off for collision cells would ensure all projects can use the optimal collision engine...

I agree... that would finally let me rest easy at night...

Please don't leave @lwgames, you seem a lovely person!