About the jerkiness on the movement...

  • I have done a lot of research on this topic as this is one big issue for me.

    my game seems to have a poor quality because of this, and it really anoys me. i cant make a game i love with construct 2 even if i love construct 2.

    here are my thoughts on this:

    1) it is NOT a construct problem! the jitter/stutter is everywhere in html5.

    take a look here: http://www.thewildernessdowntown.com/

    you ddont have to start the film. there are birds flying around smoothly and suddenly they begin to stutter, then they fly smoothly again.

    i see this issue with EVERY html 5 game where are objects moving. even with the simplest animation (using chrome or firefox).

    2) we are not alone with this problem and its not "new" so html 5 is new doesnt count. smooth movement and good audio are some of the MOST IMPORTANT things and should be the first things that work perfectly!

    http://stackoverflow.com/questions/2241 ... on-stutter

    http://stackoverflow.com/questions/1419 ... -in-chrome

    3) it is NOT a hardware problem, at least in most cases. it doesnt matter if its a galaxy s2(crosswalk) or my "high end" gaming pc. this issue of the "micro stuttering" is always present

    4) Colludium with the framedrop on start of layout: move all the objects you are using to the menu. then destroi them.

    it will better the lag when starting the main layout. at least that solves the 25fps for 5 seconds on start of layout problem for me <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

    5) we should look out mfor any information if this will befiuxed in a later version of canvas.

    i am especially speaking of crosswalk developpers. maybe they con do something. the least we should do is adress this issue to development teams of the software that causes it.

    6) if those issues dont get fixxed within the next 6 month i really see no pont to develop with html5 at all. eli0s i totally understand your frustration, its the same with me.

    the point is we (the developpers) did nothing wrong than chosing html5/canvas over a engine whith can handle our demand. html5/canvas might be god for point and click / drag and drop games. but nothing with "fast" animations then.

    7) Ashley thanks for reporting that issue. the interesting part for me (and i think for many others) will be when the crosswalk team implements the update (i speaking about the intel xdk for android releases)

    should we directly report this to the crosswalkteam (https://crosswalk-project.org/contribut ... _bugs.html)? or just wait till chromium has fixxed this issue and then report it there?

    kind regards

    joschi

  • j0schi

    Ashley already linked these, but again:

    Chrome Bug Report: Chrome issue 424563

    Firefox Bug Report: Firefox bug 1028893

    Nobody has commented on the firefox bug in two months (Ashley was the last). If nobody complains, this won't be fixed.

  • Thank you all for your advice and thoughts.

    So, after TiAm started a thread about the performance gains of making an object dormant instead of destroying it, I adjusted my earlier demo so that it no longer creates any sprites during run time. And, for my eyes at least, after destroying a few objects as j0schi suggested (thank you x 1000 for that great advice!!), the 'game' now runs very smoothly right from the start....

    While tinkering around with the settings, I found that the performance improved only if the objects that are to be destroyed are created inside the layout (I initially set them to be created at -200, -200 and that had no effect on the first 10 seconds of garbage collection; it was smooth thereafter, however).

    So, create and then destroy some stuff inside the layout and then don't create/destroy sprites during run time.... What about particles? I don't think they cause any stuttering. I'll try and put together another example to see if there are any limits / gains worthy of note.

  • Crosswalk is just a custom build of Chromium, so I don't think there's any point reporting it to them as well, just wait for it to get fixed in Chromium.

    A monitor running at 59 Hz will probably not help! A lot of games and possibly browsers are tuned to work at 60 Hz since it's the most common refresh rate, and being slightly off that could make you drop frames...

  • allright Ashley, thank you very much!

    Colludium, i am glad it helped. your demo now runs much better, i would say even if there are some jerk its one of the smoothest things i saw in html 5 so far... hahah

    regards

  • Ashley , you mean that it can cause games that run on other monitors and have 60hz refresh rate to drop frames???

    Colludium , I can't really tell if there is performance improvement at the beginning in this new test. It feels like there is, but maybe I just want it to be there. What I clearly notice now though, is something that Rayek mentioned earlier and it's very evident in your example now! In both Chrome(also in node web-kit) and IE 11, after the initial jerkiness settles down, there is a recurring stuttering period that lasts for a few seconds and repeats after 7-10 seconds. So, after you run the layout there is a pattern that goes like this: 1) Bad frame rate and intense stuttering for a few seconds 2) A buttery smooth experience that brings tears in my eyes and lasts for 7-10 (give or take) seconds 3) A continuous jerking period that lasts between 3 and 5 seconds (again, give or take) that evaporates those tears 4) repeat steps 2 and 3... In Firefox on the other hand, the damn thing is a stop motion fest, I can't believe how bad it runs something so simple.

  • I must confess that I only tested it in chrome, It was running butter smooth but my system is high spec. Let me try my old laptop and I'll report back. Excitement reduced a tad...

  • eli0s, so I tried the 'improved' version 2.1 on my old sony (512 mb graphics card) and the performance was appalling (visual artefacts on the draw of the background, and also the periodic stutter you mentioned) = totally unusable!

    So, I can only conclude that the 'fix' I mentioned before might only improve things for users of high-end hardware. I fear that it's going to be difficult/impossible to sell games of any dynamic complexity to people with average machines (my target market, I suspect) until the browser technology improves.

  • eli0s

    Wow, I glad/sad to hear your experiences with firefox. I hadn't tested with it in awhile, and my version was ancient. I assumed that was why it was performing so poorly for me. I updated to version 33, only to find that my game still stuttered terribly. That being said, my recycling fork exhibited noticeably less jank than my old create/destroy engine.

    Colludium

    Are you saying that the recycling approach gives a worse result on your older system, given the same test load (identical number of sprites)?

    I have yet to test a platform that has given me worse performance when recycling objects. I do have pretty good hardware (3570k, 16gb ram, ssd) but I usually run off of my iGPU, and was doing so in this case. My other computer is a netbook circa 2009, and thus, won't even run a blank layout. So...I'm caught at the extreme ends of the scale.

    I've got a friend with a low end dual-core laptop (pcmark is somewhere around 2000) and iGPU...I'll give his system a try when I can.

  • j0schi

    Whoa, thanks for the suggestion about creating/destroying some objects during the menu/loading/etc! I never would have thought of trying that.

  • TiAm

    No, I was just being unclear... The recycle method works much better than creating and destroying. However, when I tested my improved demo on my old computer I found that the performance was still poor when recycling (and better than when creating).

  • Ah, yes. That's unfortunate. Did you try firefox and chrome? I'm quite dismayed to see how badly my prototype performs in firefox, though admittedly it's a tough case (on the high graphics setting, there can be as many as 2500 objects onscreen, between player bullets, enemies, and enemy projectiles). Chrome does jank now and then, but it's definitely not as severe as Firefox.

  • Colludium , I think that Chrome having better overall performance (despite stuttering) is common for the most cases.

    As for your old sony machine and its poor performance, while I understand that older and weaker hardware can't simply perform as well as newer and more powerful machines do, I believe that the phenomenon that we describe can't be related just to plain horsepower. If indeed it is, then this is truly disastrous for HTML5/browser based games, because my system (for example), while quite old and underpowered by today's standards, can still run Crisis 3 at high settings, so our examples should look like a joke in comparison, considering that the CPU and GPU usage is pretty low while I test them. Also, this inconsistency in performance between browsers implies that the issue has to do with the software side of things.

    As for the recycling, I am positive that it helps to gain calculation power out of C2, but at least in our case the difference shouldn't be noticeable, there just ain't enough stuff happening to strain the machine.

    TiAm , I feel the same way, like I am not alone on this, but on the other hand, what can we do? This looks like it is inherently depended on the way browsers work. Let us hope that this is something reasonably easy to fix/improve and that our collective experiences written here and elsewhere will help the developers to do just that!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • eli0s

    Well, Ashley's second bug report for chrome got assigned very quickly...of course, the title was "Chrome is janky compared to IE11 in HTML5 game". IE is much better than it used to be, but frankly, it seems as though the general perception is still 'IE sucks'. If you can quantifiably show that IE does something better than firefox, there will probably be more interest.

    Maybe the new bugzilla entry should read: "Firefox lags behind IE in realtime HTML5 performance".

  • TiAm , you are right about IE. I think that it's also about people's habits and preferences. In my case, I do all my browsing with Firefox, ideally I would have wanted to play/run the games also with in Firefox's environment. As it is right now, since Chrome was and still is way ahead in audio issues, I use only Chrome. And since I detest for some reason IE look and feel, I only use it just to be sure that it will be able to display correctly what I am doing. When I publish something though, I always recommend Chrome for best user experience.

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