Ashley's Forum Posts

  • Press F12, are any further errors in the browser console?

  • How significant is the mentioned code? Could it potentially corrupt projects or is it just minor stuff without any major impact?

    I'm not sure what scale to measure significance on, but there's lots of desktop-app specific code scattered across the editor, and most of it is now redundant as Chrome can basically do everything NW.js can now. Removing it helps simply the codebase and should reduce the number of bugs we have to deal with pertaining to that desktop-specific code too. In every case we'd just switch it over to doing what Chrome already does, so it seems unlikely any serious bugs will be introduced by doing this.

  • Yes I'm using C2 runtime for retro compatibility with IE11 and Edge + WebGL1.

    FYI the C3 runtime works with WebGL 1 too, so that is not a reason to stick to the C2 runtime.

  • I've been planning how we might approach the effective retirement of the desktop builds. With this plan, we won't actually really fully retire them: instead we will stop distributing builds ourselves (allowing direct downloads from nwjs.io instead), and gradually unify the codebase with the browser version.

    Currently the plan is:

    • Instead of providing our own desktop downloads, we will just provide the package.json file which you can add to any NW.js download.
    • Replace most NW.js code with the same code as is currently used in Chrome. For example this means deleting all the NW.js-specific saving code, and replacing it with the local file & folder saves as used in Chrome (but ideally without permission prompts).
    • The Windows Store download will be fully retired. Users will be advised to switch to either the Chrome or NW.js version.

    This means:

    • We no longer have to manage NW.js releases ourselves, freeing up our time.
    • You can download any NW.js version yourself, without having to wait for us to release it. This also includes using NW.js on other OSs that we didn't previously provide builds for (e.g. macOS, Linux).
    • We can delete the vast majority of NW.js-specific code and stop having to maintain it with bug fixes and such.
    • You can still preview and debug with NW.js features using the editor in NW.js.
    • It's largely backwards-compatible: everyone who has already downloaded the NW.js desktop download can keep using the editor with that.

    Basically this turns the NW.js version of the editor in to the same thing as you get in Chrome, but with NW.js features still enabled in preview mode. I think this covers everything we want, which is basically eliminating the NW.js maintenance overhead, while keeping all existing features that users rely on (like debugging with NW.js). We'll also provide the NW.js version of Remote Preview on a similar basis, so you can Remote Preview your project with NW.js features active somewhere else without having to send your full project.

    Let me know if you have any feedback or if there's anything I missed. I think the next step is to formally notify users of the Windows Store app that it will be retired, so I will do that in the near feature if there are no objections.

  • This should not happen with imported Web Font files in the C3 runtime, since it pre-loads the fonts before starting the game ensuring they can render correctly on the first frame. The C3 runtime does not work in IE11, so I assume you're using the C2 runtime? This should not be an issue for modern projects.

  • PNGs are a lossless format, so there is no way this could lose quality.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If it works in the browser console, it should work in scripting too. It must be a mistake in your code.

  • Just download the filename alone, e.g. "test.pdf". All project files are exported in the root, the subfolders are only for organisation in the Project Bar.

  • Set low-quality fullscreen mode, and Construct will render the game at a fixed size (the viewport size of the project), and stretch the result to fill the screen (according to the project sampling property).

  • That message does not come from Construct. It must be something to do with the configuration of the device.

  • Thanks for spotting that, I've updated the manual entry.

  • Loader layouts are shown while downloading the game. If you're using a desktop/mobile app, the game is available locally, so it doesn't need to download anything, so the loader layout won't need to sit there showing download progress, so it starts at 100% complete, at which point presumably your events proceed to the next layout.

    Construct couldn't skip that layout automatically even if it wanted to. It doesn't know what your events will do next. So it just sets the completion at 100%, and lets your events proceed.

  • It won't, unless you've actually measured that the game performance is bottlenecked on GPU memory bandwidth.

  • FYI, this is probably years of work. We would love to do all the ideas suggested by users, but unfortunately we are constrained by the laws of physics.

  • Most mobile devices have a display resolution of at least 1920x1080, so what do you need to adapt it for?