Ashley's Recent Forum Activity

  • newt is right - despite the fact they appear to do similar things (background blending with a formula), blend modes are implemented completely differently to shader effects. A blend mode is a simple switch between different blends in the GPU's fixed function pipeline, but there's a limited set to choose between. A shader is a small, custom-written program that is executed by the GPU on the programmable pipeline, and can do more or less anything. Also due to the way GPUs work we have to take a slower path for programmable background-blending effects which includes an additional surface copy at the end. Additive is one of the few fixed function blends, but for everything else (like multiply) we use programmable shaders.

    So yes, there's a performance difference, but it comes down to the architecture of the GPU hardware. We can't program around that.

  • You don't need to "Add to desktop" to get games to work offline. All games exported by Construct automatically work offline, even in the browser. See this tutorial.

  • The preview in the desktop build is already an NW.js preview.

  • Key text.behaviors.timer.conditions.is-timer-running.display-text: placeholder {0} in English string but missing in translation

    English: Is {my} {0} running

    Translation: Is {my}{0 [/ i] actief?

    In english there is no question mark, so maybe in the translation no question mark?

    There are two typos in that: "{0" instead of "{0}", and "[/ i]" has a space in the middle where it shouldn't. I guess the question mark shouldn't be there either, generally the grammar should match the English, but I don't really feel qualified to say - every language has its own conventions and styles so I'd leave that up to the translator.

  • Thanks, I'm following that issue and will answer any engine details if they come up.

  • I'd prefer to see how the bug reports go first. We have to support a range of platforms, not just NW.js, so I'm most interested in the broadest fix possible. Even if we added this to NW.js, if there really is an issue with the GC performance, it'd only be a matter of time before it came up again with Chrome or Cordova apps on Android, so this seems to be the best approach to start with. Also if it doesn't happen in other browsers, that is good evidence it's fixable.

  • Only the "full" version points at GC (labelled "DOM GC (complete sweep)" - not sure why it's doing that...). The "cut" version just shows a long tick but unfortunately doesn't seem to indicate why that is.

    You can definitely file this as an issue with Chrome. Nobody needs to have any knowledge of the internals to file a bug, just make a web repro, attach the trace you recorded, and say the issue is it spends too long in "DOM GC (complete sweep)". I've seen them fix similar issues in the past too, no need to assume that it's impossible.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've added a new download that loads the latest beta release of C3 (see OP). Note currently you have to be online to use the beta channel download, because it currently does a redirect to the latest beta release on the server side. We'll update this in future to work better offline.

  • I don't think this quite qualifies as proof the jank is caused by GC. Could you try taking a performance profile over the time that causes jank? Press F12 to open dev tools in NW.js, and then start a recording in the Performance tab and try to capture the jank. If the performance profile measures the jank and actually tags the time period spent as some kind of GC, that would prove it. Until then, best not to jump to conclusions! I tried this myself but couldn't see any issue (over 30 seconds it spent <10ms in GC), but I do have a lot of memory on this system. I also tried pressing the "collect garbage" button in dev tools while the performance profile was recording, and again no significant GC time was measured.

    Even if it is GC, I think it would be better to file a Chrome bug to optimise this aspect of the GC. It looks like it only needs to unload 5 tracks, and freeing memory should essentially be a matter of tagging some memory regions as free instead of in use, i.e. very little work. So I'm not sure what it could be doing that would take any noticable amount of time. If there is a problem and it gets fixed, then it also improves all games everywhere else the Chromium engine is used, e.g. in the Chrome browser, all Cordova games on Android, etc. So this would improve all platforms, which is a much better end result, rather than providing a hack to work around a GC performance issue in just one variant of the Chromium engine.

  • I think speech recognition might be part of the proprietary Chrome code that isn't available in Chromium, and therefore not in NW.js either.

  • Do you have any actual problems that would be solved by this, or evidence that jank is actually caused by GC? I've never been a huge fan of garbage collectors but browser's modern GCs are pretty good and do generally slice work in to small (non-janking) updates and concurrent collection. I haven't seen GC obviously causing jank for some time now. Most jank issues seem to come down to some kind of system v-sync timing issue, and the last other cause I saw in the forum, was forcing synchronous texture loading during gameplay.

    Exposing this also has some downsides: modern browsers have multiple tiers of collection, ranging from nursery collection (with negligible performance overhead) to full heap collections (which can jank hard). The GC is designed to as far as possible only use the lower levels of GC and avoid expensive full heap collections, and even then if it has to, it tries to do it concurrently and in small time slices. The "gc()" command is a real sledgehammer that immediately hits the full heap collection. Also I'm not sure but it might even force it to be synchronous (no time slicing/concurrent work). Browser GCs are also generally pretty good at scheduling these only when it's needed, so if you force one ahead of time, chances are it's not needed and there's not much point doing the work. So, in fact, adding this could make jank problems worse, not better.

  • Closing. Please also report issues specific to Cocoon to the Cocoon developers.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,773,413 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs