Ashley's Recent Forum Activity

  • You do not have permission to view this post

  • It's a difficult problem - if you run at v-sync rate, you can't use a fixed time step, otherwise the speed of the game changes depending on the display refresh rate. I suppose you could use a fixed framerate based on timers, but it would probably look janky, as it's no longer aligned with the display refreshing. I suppose also physics could be run with separate fixed timesteps and v-sync independently of that, but it's quite a complex thing to implement, and it also multiplies the CPU usage.

    I think it's still possible to design reliable physics games with a variable time-step - it does add some nondeterminism, but you can change the steppings to increase precision (at the cost of more CPU), and then your game design needs to avoid knife-edge balances since those could fall either way with small nondeterministic results - but those won't do something like push a ball over a wall as they're too small, so as long as you have robust designs, it should be OK.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It works fine for me, and I've not seen anyone else reporting this problem. It looks like something specific to your system interfering with network requests and breaking them. Usually this is caused by browser extensions, but I guess it might be something else - possibly even some kind of malware, antivirus or proxy that is trying to inject different content in your network requests.

    I don't think Chrome Sync has anything to do with this. It shouldn't affect network requests at all AFAIK.

  • Construct itself doesn't impose any limit. If Dropbox imposes a limit, it's out of our control, and you'd probably have to take it up with them.

  • By far the easiest and quickest way to get help is to share a sample project. Otherwise all anyone can do is guess.

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,398,315 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
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x3
    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
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs