Improving upon the Performance!

0 favourites
From the Asset Store
City ride is a game to improve your memory.You have to focus and remember the information related to passengers of previ
  • Link to .capx file (required! If link is blocked remove the http and www parts):

    drive.google.com/file/d/0B_4xfuagH96rMHo4TlFHVm5EUlU/edit

    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.2

  • 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%.

  • 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.

  • 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?

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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!

  • Collision cells are a *huge* performance optimisation that make some games so much faster they go from unplayable to 60 FPS. It is well worth working around the minor edge cases where it can be slower.

  • I can vouch for this, my performance increased by over 10 fold. I was having over 80,000 collision checks on some layouts, now those layouts are under 8,000 collision checks. HUGE Difference!

  • Ashley

    I agree that the potential for collision cells optimization could turn Construct 2 into the most powerful coding engine around, and I agree that it is quite worth optimizing, and I would submit that providing an on/off toggle would greatly accelerate your development towards that end. In fact, the benefits for you, us, and the entire Construct 2 engine itself would be worth providing it alone...You see, as users experiment with turning the switch on and off, they would soon realize not only how collision cells are better, but if there ever were a rare circumstance that turning them on made it worse, then they would wonder why...they will then easily report it to you, they will figure out exactly what is causing the worse performance and it could then be fixed for the next build!!! I strongly believe that for the development of Construct 2's performance, it would majorly benefit you and the Construct 2 User-Base as a whole to place an on/off toggle so that the real problems will be rooted out, and so the real benefits may be seen first hand and so players will agreeably/without exception, stop asking for it here on the forums!!! :].

    Please consider doing this as this will:

    1. Root out all of the performance problems as comparisons take place,

    2. Stop all Petitioning for it on all of these forums, and

    3. Make C-2 better in every way as you have more tools and feedback to use to improve the Performance - making little adjustments here and there where needed!!! :].

    You're the Best Ashley!!! :]

    Let's make Construct 2 the Best Engine Around!!! :D.

  • Ashley

    Even for just one experimental build...Have everyone check their performance with it on and with it off, if everyone has better performance with it on then case closed. But if there are issues then we can fix them! -

    Thank you Ashley. :)

  • STARTECHSTUDIOS - I currently have no evidence (.capx examples) that collision cells reduce performance. I see no reason to create an option unless you show me this kind of evidence. We already added switches for the two behaviors which sometimes need it.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)