C2 performance still depressing

  • Lunatrap. Yes noticeable jank in your video.

    I think the only option at present is to learn new tools if you are serious about making games you can release. That of course is a real shame because C2 itself is an excellent tool. But you can't keep waiting and hoping things out of your control will improve.

  • megatronx have you ever reported this behaviour with a real bug report? It seems odd that this shouldn't be fixable, especially if there is a 3rd party plug that does it right.

  • So The Next Penelope runs great - doesn't use platforming. All of the people complaining are using default platforming behavior. That's what I'm taking from this.

    In our case, the enemies also use the platform behavior if they are ground based. Our jank isn't like Lunatrap 's on every machine. I haven't seen our game do that in a long time. I see random stutters like something is loading... sometimes at the start of a layout it might do it heavily or not at all - sometimes in the middle of a layout it can happen. It's the ones that get the big jank where the jumping goes haywire, etc.

  • megatronx have you ever reported this behaviour with a real bug report? It seems odd that this shouldn't be fixable, especially if there is a 3rd party plug that does it right.

    Well, I didn't think of it as bug, until you mention it, but just as a bad programing. Maybe even assumed that it was only problem due to my events, and since there was instantly working alternative, I just forgot all about it. I also thought people might have known about it! I don't really know why I assumed that.

  • All basic behaviours should work. If you have one of those rare and reproducible cases where one doesn't, *please* report it. It's the only way to improve things

  • I don't use platforming in my game and I don't have any noticeable jank right now.

  • So The Next Penelope runs great - doesn't use platforming. All of the people complaining are using default platforming behavior. That's what I'm taking from this

    Well you didnt read the OP. The thread has been hijacked somewhat i feel

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm on the C2 boat since 2012, developed two projects on it, one really (and maybe too) big and one quite small and simple. I putted them on hold last year due to the lack of a real monetization support (at the time there was only the infamous ludei->mopub->admob thing with ridicolous fill rates and entire days of broken servers) and checked them from time to time to see how the html5 ecosystem was improving.

    What puzzles me is that my apps keep loosing performance everytime I came back checking them.

    There's one project (the bigger) that worked more than decently on devices really weak by today standards (with X-Walk performing even better than Ludei's Canvas+) and now, without changing anything in my code since one year, is struggling on a Nexus 5 and, despite its heavy optimization for mobile devices, even on my desktop which is quite a beast of machine.

    Unfortunately this is related to the enormous mess the chromium team has done recently and, since chromium is packed in every serious exporter we have, the situation is really depressing both for desktop and mobile developers.

    For example here's a link with some benchmarks runned over various chromium version.

    https://code.google.com/p/chromium/issues/detail?id=456507&q=fps&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

    Although the OP of the linked post is blaming D3D binding and he's talking about the WebGL renderer, I can assure that the regression curve is basically the same on Android (so there must be a different culprit than D3D) and affects also Canvas2D performance (Maybe in a minor way, and that's probably why I found today some post on this forum claiming that Canvas2D seems more consistent than WebGL on some games).

    At least mobile developers have cordova/cocoonjs/canvas+ integration at the horizon... sounds strange saying this in 2015 but with the chromium suicide, cocoonjs/canvas+ is now again the state of the art of HTML5 mobile performance (but I've been burned a lot of times before, so I become ultracareful with Ludei's announcements)

  • Well you didnt read the OP. The thread has been hijacked somewhat i feel

    It sure has! Lots of valid bits flying around though.

  • Just commenting to keep these type post at top - they need to be known and addressed - in fact should be stickied!

  • Just commenting to keep these type post at top - they need to be known and addressed - in fact should be stickied!

    I think I agree that there should be something stickied but maybe just a locked thread with the sentence "Eventually everything will work out."

    It works great with all those fans who leave negative reviews on Steam, YouTube, and Twitter for engine bugs I can't fix or even reproduce in any of my testing computers ; )

  • I don't know if this is relevant to performance or not, but Ashley posted this recently on his twitter:

    [quote:3202i0vo]Sounds like there is finally consensus about canvas rendering from workers with OffscreenCanvas: https://wiki.whatwg.org/wiki/OffscreenCanvas

    Would need a runtime rewrite to use that though...

    [It would mean that the] entire runtime could run in a worker, unaffected by any main thread jank. Realistically this is a post-C3 project.

    I'm guessing that means our games would utilize more cores? I don't remember how many are being used, but considering 48.8% of Steam users have 2 cores and 48% have 3+ cores, that might be good.

  • alspal that'd be sweet, and since Construct 3 isn't out yet I would really, extremely, very much like it to take advantage of something like that and replace the runtime instead of just waiting until C4 comes.

  • I'd rather wait an other year or so for C3 if I have to to get these kind of improvements.

  • It might help a bit to run the engine in a worker, but I wouldn't expect it to be a transformative improvement. Running the engine on the main thread means it contends with other browser work happening on the main thread, but browser developers already work hard to keep the main thread as free as possible (by making the browser do its own work in other threads - already using other cores if available - see this blog) specifically so there's as much time as possible to be spent running JS code. I don't know, I'd guess at maybe at best a 10% improvement running in a worker. As the blog post mentions, a nice thing about browser engines is they already split work across cores where possible.

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