Ashley's Forum Posts

  • Set the color to white to use the original colors.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • On desktop if you see this happen, does resizing the browser window bring the dialog back?

  • I must point out that for any important digital work, you should make regular backups to avoid data loss in the event of any software/hardware failure, fire, theft, flood, etc.

  • Chrome has experimental support for accessing the file system which should come to stable release by the end of the year. You can use this to reload all the files from a folder-based project while the editor is still open. However the security model makes it very difficult to load from arbitrary file paths on disk - only files the user has explicitly approved access to can be read. That's why it's done by reloading from the files in the project folder, since those files can be accessed.

  • It's an issue we fixed in the latest beta.

  • Press F12 and check for any errors in the browser console. It's hard to help without more information, and usually detailed information is logged there.

    Alternatively try just saving the project a different way.

  • We support that too. Set a storyboard splash.

  • FWIW, this is fixed with built-in functions in Construct 3. Function parameters are preserved across waits in that case.

  • IIRC there isn't a way at the moment. The ColorValue expression currently exists only so you can set an object's color to the same color as another object.

  • I think some confusion about the loading screen arises from the question: what do you show when you are loading the loading screen?

    If you use a loader layout, Construct still shows the default loader while the loader layout itself is loading. This is just on the off-chance the user is on a very slow connection or for some reason your loader layout uses a lot of resources. If your loader layout is small and simple, it should load quickly - so you can set the default loader to "none" and you will only ever see your custom loader layout.

    Even if we supported some custom splash image for before the loader layout itself is loaded, what do you show while that is loading? At some point you just have to either show some pre-set message or image - which cannot be customised, because nothing is loaded yet, not even the settings for the game - or show nothing. You can already do both by using either Construct's default loader, or turning it off and showing nothing until the custom loader layout appears.

    If you have a small, simple custom loader layout, and you turn off the default loader, then you have basically arrived at the same thing as a splash image or custom spinner.

  • If you want to render the game at a lower resolution for performance reasons, use "Low quality" fullscreen mode. You can change that at runtime too.

    The "Use high-DPI display" was just another way of doing that but with a dependency on the display DPI - since low quality fullscreen mode is a more general way of doing that, the "use high-DPI display" option was removed in the C3 runtime.

  • You should be able to alter a few parts of the returned ImageData and then load it back in to the canvas with loadImagePixelData().

  • Sorry, I'm not sure what you're asking here? If you're asking for a new feature, I can't really tell what it involves from a quick read of this thread. I'd advise using the feature suggestions platform as usual with a comprehensive description anyway.

  • Well, not really, the events I mentioned are the best way to check timings. Maybe there's a problem with the debugger where it doesn't show updated information quickly or something.

  • Yep, this again... I think the thing most people don't understand is that native exports could actually make all of these problems worse. It would also involve such a colossal amount of work that it risks ruining the entire company. We've only come this far because web technology allows us to re-use virtually all our code across every platform.

    To just really quickly run through some of your points:

    Custom loading screens: loader layouts already let you show a layout as the loading screen, allowing for completely custom display. (Native engine is irrelevant here)

    Orientation: it's not clear why this is necessary? (Native engine makes no difference to this)

    Multiplayer: networking is a super complicated area and is basically an expert level feature. I was quite uneasy implementing it in the first place because of this - it's a huge jump to go from non-programming blocks to things like lag compensation in a real-time online multiplayer game. Even though Construct takes care of loads of details for you, you still have to deal with some fundamental complications like synchronization. I'm not sure what we could do to fundamentally fix this. (Native engine makes no difference to this)

    Monetisation: I know this is important, but it's a huge amount of work and requires constant maintenance to cover things like ads and IAP, and a regular source of awful bugs that are really, really hard to fix. We're a small team with limited resources. If we added any more services, I can imagine us quickly spending 100% of our time just maintaining them and dealing with all the problems. So our approach is to cover some basic options and leave other services - of which there are dozens and dozens - to third party developers. (Native engine would not solve this either, since it's to do with maintenance and workload)

    Performance: GPU drivers are native technology! So if driver problems cause poor performance, a native engine won't fix that either. In fact browsers have done a ton of work to avoid performance pitfalls and crashes in GPU drivers. Last I saw for example ANGLE (used by several browsers) had workarounds for hundreds of driver problems. If we make a native engine, we will have to re-do all that work ourselves, or face all the performance pitfalls, crashes and glitches. So I genuinely think a native engine would make this worse, not better. I often read about native developers having a total nightmare over this, so I think web technology is a good choice and this aspect of it is underrated.

    It's easy to think of native code as being a magical solution that makes everything better. But in many cases it's either irrelevant, or could actually make things worse. There was a better case for it if you go back 5+ years, but now I think there is very little reason at all for it - especially with technologies like WebGPU on the horizon that have a decent chance of actually overtaking native technologies in some respects.