Ashley's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,770,358 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs