Ashley's Forum Posts

  • We could try moving to Capacitor, but it would probably be months of complicated work; if we dropped support for Cordova it would probably be highly disruptive as there would be a bunch of difficult backwards-compatibility issues; if we kept support for Cordova now we're maintaining two mobile exports which is a permanent drain on resources and focus; and then, as no software is perfect, we'd probably find Capacitor has a bunch of its own quirks and issues. In a worst-case scenario we have to do months of disruptive work, and the end result is no better, or even possibly worse. Often it can seem the grass is greener on the other side. We do occasionally shift between technologies, such as our current effort to move away from NW.js, but that has literally been years in the making (Windows WebView2 came out about 3 years ago) and it's much clearer there are significant gains to be had after completing the transition.

    Meanwhile bugs can be fixed - I expect Google will sort out the frame scheduling in the webview sooner or later, and if anything else comes up, make sure the issue has been filed and reported well (following all the guidelines). Fixing even a whole bunch of difficult bugs still likely works out as less work than moving to a whole new mobile framework. I think you can also try out TWAs already - they're based off web exports - see the TWA documentation here. It would be interesting if people tried that out and reported how it worked. For example if lots of people are already using TWAs and reporting that it works great, then we could more seriously consider improving support for it. But that approach doesn't support Cordova plugins - so what happens to all the advertising plugins for example? If we move to Capacitor, it still uses the Android Webview - so bugs with the webview would still need to be fixed. So it's not clear that any other approach will actually be better - which is why I think it's better to focus on making sure any bugs are fixed.

  • Just to clarify - browser games are completely safe and absolutely cannot do something like run an executable on your computer. Browsers are essentially a strong kind of security "sandbox" and have permission prompts to access anything potentially sensitive like your camera or microphone, and if you don't trust the website you can just deny permission and that's that.

    If you run an executable, that is something much more risky, as it could be some kind of malware, and downloaded desktop apps have far broader permissions by default - such as being able to read and write files, run other programs, access your camera and microphone without asking for permission, and so on.

    A possible source of confusion is Construct can export your project as a desktop app, using options like NW.js. This then does potentially have all the risks of desktop apps noted above, since those are all risks with any desktop software. However if you are only loading a HTML5 game in a browser, then it's basically completely safe and cannot harm your computer in any way.

  • JavaScript in Construct works the same as JavaScript in a web page. You can write the same code you'd use on a web page. There's nothing special about Construct's "JS implementation" - it's not Construct that implements JS, it's the browser.

    You may have difficulty with some APIs when Construct runs in a web worker, but by default when you add JS code it runs in the DOM, so as long as you don't change the 'Use worker' setting then there's nothing different to coding a web page.

  • I'm afraid as in this case it's often not possible to tell what went wrong from only a log. It could be a problem caused by a third-party addon your project uses, in which case you'd need to contact the addon developer for support. Otherwise if it's only using Construct official features, we'd need a full bug report to investigate (including e.g. a sample project).

  • Construct can run in a Web Worker where window is not defined. However in this case the solution is simple: use globalThis instead - globalThis.location.href works in both the DOM and Web Workers. In general, for this reason, always use globalThis instead of window.

  • I suspect that other games you've seen that appear to be running in the background are in fact using either the timer-based approach or catch-up-time approaches that Construct can also support. Any app that genuinely runs constantly in the background will do things like spin up laptop fans and drain battery, which people don't like and usually leave negative reviews for, and it's unnecessary and wasteful compared to the other approaches.

  • You need to include the subfolder path in folders mode, e.g. if the sound effect "sfx" is in the folder "myfolder", use "myfolder/sfx" instead of just "sfx". This is all covered in the manual guide on deprecated features.

  • Browsers basically forcibly suspend any content in the background to prevent them draining system resources and wasting battery. There isn't usually any way for web content to work around this.

    You can still make projects which seem to progress in the background though by using other workarounds - see the offline builder for one timer-based example that even works when the browser is entirely closed, and catch-up time which basically runs in fast-forward when you return to the tab. Either way you get the best of both worlds: it doesn't need to waste system resources while in the background, and it still looks and works as if it was running in the background.

  • Note that in general if you have a feature request you can submit it here.

  • See the Learn JavaScript in Construct course or the quick-start guide which covers the basics of accessing objects from JavaScript. I'd also recommend using TypeScript which will catch coding mistakes like this for you so probably save a lot of trouble.

  • https://www.hyperspaces.co.uk/device/

    I tried that on my PC display and got out a ruler to check, and it claims to be 25.4mm, but measures more like 33mm. So it's not very accurate!

    Anything which involves "maintain a database of all known devices in existence" is probably not a very good solution anyway...

  • This guide has some advice about importing third-party scripts.

  • There have been no changes to Construct's IAP plugin in the latest release cycle. The last change was in r394 back in June which updated the underlying Cordova plugin version. So if you were already using r397.2 stable and updated to r407, there have not been any changes to IAP.

  • Isn't that correct though? If you scale up the display to make everything larger, it in effect gives you a smaller screen size for the same size content, and so content should adapt accordingly. If you could ignore that effect, then you could make an app that keeps everything the same size ignoring the system display scale, which then defeats the purpose of changing the system display scale.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Normally you shouldn't set a minimum delta time at all. You don't want your game to start running in fast-forward if it goes over 60 FPS - what if someone has a 120 Hz display? It's intended to only be set for things like catch-up time.