DRASTIC PERFORMANCE DECREASE ON NEW C2 VERSIONS

Problem Description

In the early days of Construct 2 I made an amazing project. It took me about 8 months. Everyone that played it absolutely loved it. It was revolutionary, amazing, and incredibly fun. Then when a newer version of Contruct 2 came out (I BELIEVE IT WAS THE COLLISION CELLS 'UPDATE'), my project completely broke and remains unplayable to this day. I am going to demonstrate the problem so any user of C2 can reproduce it...

Attach a Capx

1. C2 project created with r139 Capx Download (runs on C2 version r139):

https://drive.google.com/file/d/0B_4xfu ... sp=sharing

2. C2 project created with r239 Capx Download (runs on C2 version r239 +):

https://drive.google.com/file/d/0B_4xfu ... sp=sharing

Description of Capx

This concisely shows how r139 had Far Better Performance (before collision cells were implemented) than every other version after it including the latest stable version r239.

Steps to Reproduce Bug

• Step 1. Download Construct 2 Version 139 Here: https://www.scirra.com/construct2/releases/r139
• Step 2. Download the 2 capx files above.^^
• Step 3 etc. Run the 139 on r139 and 239 on r239...

Observed Result

The older version (139) version goes fast at approx 14 fps on my computer. But the new version (239) goes less than half as fast and eventually grinds to a hault not performing at all. How is this Better??

Expected Result

I expected this.

Affected Browsers

• Chrome: (YES)

Operating System and Service Pack

Windows 10 Latest

Construct 2 Version ID

r139-r239.

Having the black boxes both bullet behavior set to bounce off solids and being solid, it will bounce off on itself every tick, causing the massive performance drop.

Furthermore, is there any particular reason why your project utilizes a 10000 x 10000 window size?

STARTECHSTUDIOS please don't take this the wrong way as this is not meant to be a shot at you in any way, but these examples are set up very very poorly. It's almost like you're trying to make the performance bad (perhaps that was your intent?). I'm not referring to the large amount of sprites you have on screen either. I myself have a game with several hundred sprites on the screen at one time, all using the bullet behavior as well, collisions enabled, over 2000 events and my game still runs at 60fps even on my tablet.

EDIT: I took a couple minutes to fix some profile settings and moved a couple of your events around, getting rid of the every ticks etc and the 242 version now runs at a steady 28fps (up from 8fps before optimizing).

In addition, the project isn't set up to utilize the collision cells, which I think is what you were trying to show didn't work correctly?

Again, please don't take anything I'm saying as a shot against you in any way. I just want to show that doing a little optimization (I spent about 2-3 minutes on your capx) can make a huge difference in performance.

Burvey

I simply set up 2 identical projects and showed their performance comparatively. If the 242 version runs at 28 fps after your event changes, think of what the performance will be on the 139 version with the same changes!!! Why are you fighting for worse performance? It seems like better is better, right???????

colonel Justice

It doesn't really matter what the test is, if it shows clearly how the previous version is vastly superior, isn't it better? All I know is, my old project ran perfectly before and now no matter what I do it will not run anymore except at a slow crawl, whereas before it ran perfectly. That is the clear problem here. Whatever happened to Construct 2 made it much worse than before.

I'm not fighting for worse performance. Just trying to say that there are quick and easy ways to increase performance. And to be fair, you are correct, I did not take the time to test the changes on the 139 version to compare.

Burvey

Thank you, maybe something good can come out of this for all of us then.

I have real games that actually grind to a halt just like this, whereas with 139 they do not. C2 has drastically worse performance than it did before, and I believe it has something to do with the collision cells update. Ashley this is a big one, I think it happened right after the collision cells update. I can provide many more tests just like this to help illustrate the problem in order to benefit you and the c2/c3 community. Thank you for fixing this. Let me know how I can help: I'm committed to getting this one resolved. It's too big and too drastic/beneficial to go unnoticed or unfixed. Thank you, I'll provide more examples in days to come.. I have virtually unlimited examples of this problem so hopefully all of these help in resolving it. Good Luck!

Collision cells are a performance tool. Used correctly, they can increase performance. Used incorrectly, they can decrease it. IIRC, the size of each 'cell' is determined by the window size defined in the project properties. But, since you made that ridiculously huge, you rendered the collision cells completely ineffective at boosting performance. If you take that exact same project, lower the window size to something sane (like 640x480), and set the layout scale to compensate (like 0.05), you will get a very similar result, and it will be much faster. This is not a problem with the tool, this is a problem with how it's being used.

Johncw87

Thanks for your tip John. I don't want to make you work but could you do a quick little example of 139 vs 239 and show improved performance? That would be a huge help and shed light on this for all of us! ))

Thank you man.

Johncw87

Thanks for your tip John. I don't want to make you work but could you do a quick little example of 139 vs 239 and show improved performance? That would be a huge help and shed light on this for all of us! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">))

Thank you man. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Ok, but only because I was planning on re-installing Construct 2 to test something else anyway.

I took the project you posted, and made the modifications I mentioned. Window size is 500x500, and the layout scale is set to 0.05. I also modified the project XML so that Construct 2 rev 139 would open it. Visually, it's exactly the same.

https://dl.dropboxusercontent.com/u/207 ... 20fps.capx

In version 139, I get 22 - 27 fps, with an occasional dip

In version 242, I get above 50 fps, with an occasional dip.

These tests were run in Firefox 50 32-bit

The way this project is set up circumvents the collision cells optimisation. The cell size is the viewport size, so in this case by using a totally impractical size of 10000x10000 (honestly, surely nobody would ever choose that in practice?) forces all collisions to be made within one cell. So then you get the worst-case of all possible collision checks, plus the overhead of managing collision cells. That's probably why you're seeing it as slower.

If you set the viewport size to something reasonable, it runs far faster. Even with a viewport size of 1000x1000 it runs several times faster for me.

If you want a full view while using collision cells, set a reasonable viewport size, and then set a small layout scale so you can see everything. That way you'd get the same view but the improved performance too. I did this for some of the screenshots at the time. Also collision cells are an absolutely critical performance optimisation if used sensibly - in many cases they can completely eliminate 90% or more of all collision checks, which in many cases completely eliminates the performance overhead of collision checks. It's such a huge optimisation that it's definitely a good idea to work with it, not against it. Also I have to say reporting an issue about a change that was made over three years ago is not very helpful - the sooner you can make a report, the better.

Closing as won't fix.

Ashley

Thanks for your reply. If it is true that in some cases collision cells make the project worse, why not make a simple on/off toggle switch in the project bar so users can turn it off if it hinders performance? It will be on by default. That way there are no gripes and you don't have to perform a fancy (but less intuitive) shrink the window and reduce the scale trick to get it to work. It will remain on by default but can be turned off to increase performance in some cases. There is no harm in it surely, you already did it for turrets, just do it for the rest of the engine, please. I'm still not done testing the versions, it seems that collision cells will reduce performance except in cases with very small window sizes. A toggle switch would instantly fix this issue. Modern phones have displays reaching above the 1920 x 1080 viewport of most monitors, my current project is set at 1440x2560 to accommodate most modern smartphone screens. Wouldn't it be feasible to have a simple on/off switch to alleviate this? Thanks for your help

To turn off collision cells, you just make a event that 'disables' it by 'not playing nice to its rules'.

(according to my knowledge, and if interpret the rules correct )

Object1 is overlapping Object2 <------- will use collision cells

______ Actions .......

Object 1 is on screen <--- will exclude Object 1 from the collision cells (or any other pre-pick condition)

Object1 is overlapping Object2

______ Actions .......

See Ashleys blog.

99Instances2Go

A good try for sure. But the only problem is I don't think the 'is on screen' event can pick before the 'on collision' event. Otherwise yes, it would be a good trick for sure.