Ashley's Forum Posts

  • I would assume that issue is completely unrelated and that this is not related to Construct itself. You should start by checking your Internet connection, and then if you're sure that's working, contact the host for support.

  • It sounds like network requests are failing. That type of thing is either a problem with your Internet connection or the server.

  • I'm not sure what you mean - async actions can do anything async at all, which includes posting to the DOM and back. The runtime doesn't care what the method does, it just waits for it.

  • An empty project fully minified and exported as a Playable Ad is about 480kb uncompressed or 160kb compressed.

    It's designed to work with Facebook Playable Ads. It may work with other networks, but it depends on their specific requirements.

  • You can sue AJAX to fetch a URL and store the result in Binary Data. One example that does this is Voice Recorder.

  • The Text object is limited by the maximum texture size of the device. If it goes bigger, it compensates by reducing the display quality. Therefore extremely large text objects won't look good. Use smaller text objects instead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • DOMElementHandler is for HTML elements specifically. DOMHandler is for everything else.

  • Construct uses modules, and in module workers JavaScript does not allow use of importScripts(). Use import() instead.

  • This is the Construct 2 bugs forum. Please report any problems in Construct 3 to https://github.com/Scirra/Construct-3-bugs following all the guidelines.

  • I just tried exporting the 'Flying along' template to Android in r252 with worker mode 'Auto', and played it for a couple of minutes. It looked reasonably smooth throughout.

    Could you file an issue with Google at crbug.com and let me know the bug number? Normally only Google can deal with jank issues as they occur in the browser engine, not Construct.

  • Well, if you make a new project, ISpriteInstance won't be defined until you add a sprite to the project.

  • It's not supported on iOS, because Safari does not yet support OffscreenCanvas. I believe Apple are working on it though.

  • Modules don't affect sub-classing. It should just work with ISpriteInstance. I just tested the Ghost Shooter code example and it works as expected both with ISpriteInstance and globalThis.ISpriteInstance.

  • I tried this on a Pixel 3 and it was perfectly smooth.

    The canary WebView may be unstable. Have you tried using the latest stable WebView?

    Also which device are you using specifically?

  • As of C3 r252, worker mode (i.e. hosting the entire runtime in a Web Worker) is now supported in Android apps. This is a potentially important feature to ensure high performance in Android apps with a smooth framerate. However some third-party addons designed to work with Cordova on Android may need updating to be compatible with it.

    History

    After much work, the C3 runtime has been using worker mode by default for over a year. However due to technical limitations the Android WebView, which powers Construct apps exported to Android, still did not support worker mode. Thanks to the addition of support for OffscreenCanvas in the Android WebView M90+, it's now possible to use worker mode in Android apps.

    During the past year or so, addons that integrated with Cordova on Android could ignore the possibility of worker mode, solely because the technical limitations in Android WebView previously meant it was not supported. However now that it's supported, some of those addons may need to be updated to support worker mode.

    Supporting worker mode

    In worker mode, all runtime code, including conditions, actions and expressions, run in a Web Worker. This means APIs only available on the DOM, such as document, are not available. It appears few Cordova plugins support web workers, so all calls to Cordova plugin code are effectively DOM calls, as they are only made available in the DOM context. Therefore Cordova plugins cannot be called directly from runtime code in worker mode.

    As with other platforms, the solution is to use a message-passing system built in to the runtime. To make a DOM call, or receive a notification from the DOM side, messages are posted between the worker and DOM context (interally using postMessage()). For more details see the section on DOM calls in the C3 runtime in the Addon SDK runtime scripts section. Most code interacting with Cordova plugins will likely need to be moved to a DOM-side script and use message passing to integrate with the runtime. The Construct runtime already does this internally anywhere it needs to use a Cordova plugin, including in official Construct plugins.

    Compatibility

    To avoid breaking lots of projects, Construct implements some compatibility logic in the Use worker project property. The default setting is Auto, which the vast majority of projects use. With this setting, Construct will enable worker mode on Android, unless the project uses any third-party addons, in which case it will disable it. This means third-party addons integrating with Cordova plugins will continue to run in DOM mode as they did before, and so continue to work as expected. In most cases this should avoid any breakage. However the downside is the user's project is unable to take advantage of the performance benefits of worker mode. It's also possible the user may notice a performance degradation when they add a third-party addon to their project, as the presence of a third-party addon will downgrade it from worker mode to DOM mode.

    Testing

    If the user chooses Yes for Use worker, it will still use worker mode in Android apps even with third party addons. As an addon developer, you can also use this setting to force worker mode in Android apps, and use that mode to develop and test your addon and verify it works again in worker mode.

    Future support

    In future, we will likely change Auto mode to also enable worker mode in Android apps even when the project uses third-party addons, to ensure as many projects as possible can get the performance benefits. We will wait several months before doing this to give addon developers time to update their addons.

    It is also likely in future that iOS will also end up supporting worker mode, in which case the same will apply for iOS. However if you update your addon to support worker mode, you should be able to easily cover both platforms, as you already have the messaging system in place.

    Even after making such a change, users will be able to continue using addons that don't support worker mode by changing the Use worker setting to No. The Use worker setting will also be supported indefinitely, as it is useful with the scripting feature. Therefore this change will not make old and unmaintained addons completely unusable - the user will be able to work around the lack of support for worker mode by changing the project settings. However it is preferable that as many third-party addons as possible are updated.