As per the title. After experimenting with the new asm.js I created a simple stress test to demonstrate the difference between r195 and r196 physics. It appeared that r196 caused more frames to be dropped and a larger variance in delta time than r195 - surprisingly for both asm.js and the box2d web options. It is also apparent that there is no difference in performance between the two physics options (both r195 and r196) when the browser is stressed in this way - which is representative of a game that is max-ing out the browser but is still just playable. A stress test to a lower fps would, arguably, not be as representative of a properly optimized game. I was skeptical at first and re-installed each version of C2 multiple times and the results were consistent on my system.
Attach a Capx
Description of Capx
The project has one layout. It creates or destroys physics objects to stress the browser unless the frame rate is between 55-57 fps. The physics objects are bounded to stay on the visible layout; at the top a horizontal waterfall graph of delta time is drawn to show the variances of dt with time, in addition to the returned instantaneous fps and object count value.
Steps to Reproduce Bug
As you can see from the images above, the number of high value delta times in r195 was much lower than in r196. Of note, there is no discernable difference between the number of objects that each physics engine could support. The images are of NW 10.5 which provided the cleanest and highest performing rendering.
1. I would expect there to be no difference in dropped frame rates / large values for delta time, between each type of physics engine in r195 and r196.
2. I would expect there to be an apparent improvement in performance when running in asm.js compared to box 2d.
Operating System and Service Pack
Construct 2 Version ID
r195 (64 bit) and r196 (64 bit)
Thank you for writing this up! I was waiting for someone to do it.
So yeah, Inoticed it by eye in the first few seconds of my game, even though there're a whole 2 physics objects. I can definitely verify that it exists.
And it happened somewhere in the transition between 195 and 196, regardless of the physics engine used, it seems.
Can't reproduce with the latest Chrome. I'm not really interested in testing old node-webkit versions, since Chrome updates usually improve performance and has focused on asm.js in particular lately. So you're basically testing Chrome 35 and I'm testing Chrome 40 (which will come through to NW.js soon enough).
I get 1200-1300 objects with box2dweb and 2200+ objects with asm.js here on Chrome, and the dt variations were not much different - in fact it was much more stable at first with asm.js since it could easily reach a steady 60 FPS until the object count started reducing the framerate. The variations may in fact be crbug.com/422000 anyway.
Develop games in your browser. Powerful, performant & highly capable.
Ashley I get drops/pauses on Chrome and NW. :/ Should I submit a separate bug report? This was introduced in 196, as 195 was working 100% without any issues. 196.2 also does not fix anything for me.
I understand your reluctance to accept older NW images as proof, but I had also tested this in the latest Chrome, the latest Firefox and the latest IE11 before I submitted the report. So, here is an image of my results running in the latest build of Chrome Version 40.0.2214.94 m:
As you can see, this simple test causes lots of dropped frames, many per second, only in the r196 rendered tests. I suspect that any difference you encounter in your tests (with respect to this and to the hike in performance you get with asm.js) could be down to you using NASA spec hardware.... Of interest, I had one test run that showed 2300 objects for both asm.js and box2d web in concurrent tests on chrome. I have not been able to reproduce that performance since the one occurrence... Just to be sure, have you tested this on other hardware at all? As this is all on a single open tab of the latest stable Chrome, it is unlikely that this difference would be attributable to a chrome bug.
Not sure if related, but hopefully so: my game only lags on lower frame rates. When in debug it hits 60 fps, there're no issues. But lower and it starts choking. I don't have anything less powerful to test on, so unfortunately I can't do much more testing.
Verified on Firefox, Chrome, and NW.js exports.