About the jerkiness on the movement...

Yeah - IE is smoother than Chrome by a long way. Pity its interface is so, well, Microsoft...!!

Wow, this might explain the micro-pauses I'm getting with my game on CocoonJS! Perhaps there is hope after all, since Ashley's theory seems pretty spot on.

If anyone is interested, I made a thread on Ludei's website, requesting them to also look into their compiler to see if they can fix the frame dropping. If you're also a "Cocooner" then please upvote the thread to show your interest in the issue.

And also, I made a simulation of what my simple bouncing square application looks like on my phone through CocoonJS. I have always assumed the stutter was simply garbage collection, but now I'm thinking it's a combination of that and synchronous compilation. Whatever it is, I hope it can be fixed soon!

Poking around, it looks like construct 2 uses

requestAnimationFrame

and

setTimeout

Like Dalal said, this causes problems. Browsers can do only one thing at a time, and with javascript this eventually leads to this stuttering.

The solution? As far as I can tell is to use CSS for animations.

found this example online.

http://www.html5rocks.com/en/tutorials/ ... e-raf.html (The way it looks like Construct 2 animates using requestAnimationFrame)

http://www.html5rocks.com/en/tutorials/ ... imple.html (The same animation using css)

Edit:

Also reading about GSAP

http://greensock.com/gsap

Looks fairly promising.

As for if this necessarily will help with smooth animations I cant say. I feel a square box is rather different than an animated character/object changing frames.

Part of the issue also falls to device vertical sync and fps. I took the example from page 1, changed speed to always match fps. And obviously there was 0 jittering.

The problem is it moved slower than I like.

There could be an internal issue within construct and how it draws frames, because it does not match the refresh rate. (Everything takes place logically as if 60fps I believe?)

Digging around, it looked like this is due to that setTimeout code I was talking about. It looks like it is set to 16ms (60fps) which obviously is bad. Static frame rate/refresh/logic has these issues. A dynamic system would always look smooth. Able to adjust with fps drops and rises.

I could be wrong about how construct is animating things. But It would probably be better if it animated based on dt rather than using the timeout.

The people with high refresh devices don't see nearly as much jitter because they refresh so fast it compensates for any fps variance.

Ahhhhh screw it. Everything I know and keep reading about game/film/web animation and why it looks "jerky/jittery" all comes back to interpolation. If you interpolate between delta time and desired speed things should look smooth(er). I think the issue comes from while speed might be interpolated etc, the animation frames themselves are not. The draw calls themselves should interpolate what we see, I don't think it does.

Part of the issue also falls to device vertical sync and fps. I took the example from page 1, changed speed to always match fps. And obviously there was 0 jittering.

The problem is it moved slower than I like.

Can you please post the changed example? I am curious to see if it will perform with 0 jittering on my machine also.

As for the CSS vs RequestAnimationFrame, call me crazy but the CSS performs worse on my system! That's on Chrome, Firefox and IE 11 doesn't animate the thing at all!

As for the CSS vs RequestAnimationFrame, call me crazy but the CSS performs worse on my system! That's on Chrome, Firefox and IE 11 doesn't animate the thing at all!

On my system actually RequestAnimationFrame looks almost like stop-motion animation, while CSS is nice and smooth. Tested in Chrome only.

shinkan , damn, this is getting really frustrating, how come there is so much inconsistency between so simple things! We'll never figure this out like this!

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

megatronx , this is heretic! Damn you exe worshipers, you will be fragmented beyond compilation!

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.

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

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