megatronx wrote:One day the Messiah will come, and you will know him by his name, which shall be "exe exporter"

That would still not correct the issue, C2 is sold as (and truly is) an html5 engine, it is not like the html5 export was "just an optionnal gift that could have bugs in it", it is the main exporter, even if one day there is native exporters (which in a way, would be kind of dumb multiplatform wise but that is not the question), that would stil be an issue, it could even be considered worse, as the main export would have more issues than the secondary ones.

Game design is all about decomposing the core of your game so it becomes simple instructions.

megatronx wrote:One day the Messiah will come, and you will know him by his name, which shall be "exe exporter"

That would still not correct the issue, C2 is sold as (and truly is) an html5 engine, it is not like the html5 export was "just an optionnal gift that could have bugs in it", it is the main exporter, even if one day there is native exporters (which in a way, would be kind of dumb multiplatform wise but that is not the question), that would stil be an issue, it could even be considered worse, as the main export would have more issues than the secondary ones.

I know. I was only joking. Best thing would be for us if someone would really nail down the wrappers.

Ashley wrote:I've looked in to this in the past and I think it's JIT compilation in the Javascript engine.

@Ashley, If JIT compilation is truly the issue, what sorts of Construct 2 events would you recommend we use in a "compiler" layout to force code to get pre-compiled? Should we call functions we use in the game, create and destroy objects, make Touch conditions etc.? Could this technique even work to reduce the problem?

CSS animations are fundamentally incompatible with the way C2 games render. They draw pixels in to a canvas, whereas CSS animations move about DOM elements (i.e. parts of the web page), and DOM elements carry a lot of overhead. In the early days of HTML5 there were some entirely DOM-based game engines, but they ran far slower than canvas ones, so realistically these days noone uses them. BTW realistically C2 always uses requestAnimationFrame; the setTimeout is a fallback for browsers without requestAnimationFrame support, which I think is pretty much only IE9 now.

I'd point out we had similar issues with Construct Classic, which was a native engine. People raised the same kinds of issue about frame drops from time to time. I think I mentioned this earlier, but ultimately a multi-tasking OS which has to hit a very precise 16.7ms timer frequency will in practice have some variation and possibly occasionally drop a frame. Classic worked better in fullscreen mode, and that might be true of browsers as well.

JIT compilation is basically completely invisible to the code. Every browser handles it differently, the way it's done changes over browser releases, there's no way for code to know if it's been JIT compiled or to force it to be done, and trying to force the browser to compile everything could have other detrimental effects like wasting memory or actually degrading performance, especially during startup. I don't think it's realistic to solve it by fiddling with the JIT - it needs to be handled by the browser makers in their javascript engines.

I just recently am having these issues with jerky movement in a game, I never noticed them before compiling and testing in CJS, the movement was always smooth and after switching to Crosswalk to support some 3rd party SDKs, the jerkiness is pretty extreme on layout starts and random times throughout play. It's really weird, game is running at 60fps but the jerkiness of the player movement is still there, which is actually game breaking for my game cause it causes you to die. I can make a blank layout with a tiny sprite and movement it with bullet, moveTo or just with the move forward and i get this crazy jerky movement, I've noticed the same thing with other engines such as Phaser, jerky movement just tweening a sprite from point to point. Looks like I'm going to have to switch to a non HTML5 engine, which sucks cause I really like C2.

@twg, How many HTML-5 game engines have you tried that do this? Does the jerky movement stop after a minute, or does it continue throughout the game? How severe is the jerkiness? How accurate is this simulation in regards to what you're experiencing with movement?

I want to figure out whether you are experiencing the exact same thing as me, and whether it's truly the JIT compilation that's doing this. If it's the JIT compilation, then I have hope that this will be fixed in the coming months.

@Dalal The jerky movement is pretty consistent throughout the game, seems to come at regular intervals, whether on a game with 50+ layouts and tons of sprites or a blank canvas with one sprite. Sometimes the movement is smooth then seconds later the jerky movement will be present. Your simulation is about what I am experiencing, but at times much more extreme. I tried testing a blank canvas with one sprite moving to 4 different points with a toggle for setting 4 different speeds(200/250/300/400p/s) on C2, Phaser and Crafty, I got the same results in Chrome, FF, IE and when compiling for device with Crosswalk, jerky inconsistent movement on all of them while fps remained 60+.