Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

  • Using the "is on mobile device" event, is it possible to disable the "Use mouse input" property only if the game is being played on a mobile phone? I can't seem to find the right action for it and blanket disabling would render the games useless on desktops.

    This kind of detection generally isn't correct: you can get desktop devices with touchscreens, and mobile devices with a mouse attached, so in some cases you'll either disable mouse input that the user wants to use, or leave mouse input enabled (and therefore risk double-triggers) where they want to use touch input. You can't simply assume that "is mobile" is the same as "uses touch input".

    [quote:1kicopng]In r237, the issue with double touch events can, sort of, be worked around using tap. However, in r253, even taps increase by 2 when iframed. Since I am trying both in the same Chrome version, there must have been some change in C2 around the way you receive user input?

    I checked, and our last change to the Touch plugin was in June 2017, before the release of r237. So I'm not sure what could have impacted this.

  • Sebastien

    Ctrl-F5 previews active layout. Most of the time I need to preview the entire project and there is no shortcut for it..

    F4

  • It's still in review. We hope to have it out soon.

  • I have no idea. It's entirely up to the translators.