Ashley's Forum Posts

  • In the video you only disable WebGPU for the project, not for the editor. You need to disable WebGPU for the editor in Settings to be able to enable the effects and see them in the editor. If you still think there's a problem, you'll need to file an issue following all the guidelines.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The "SkendPow" effect also doesn't support WebGPU. You'll need to disable WebGPU and go back to using WebGL only for such effects.

    Construct has supported WebGPU for a couple of years now, just disabled by default until now, so there's been plenty of time for addon developers to provide a WebGPU port. I'm afraid this type of thing is one of the risks of using unmaintained third-party addons.

    • Post link icon

    I'm afraid for security and privacy reasons we cannot provide support for payment or subscription related questions in a public forum, so closing - please contact supportnoi@construct.net for such queries.

  • It shouldn't crash and my own tests work OK. It's hard to say more unless you file an issue following the guidelines. It's also possible it's crashing on Steam's side, for example if the app was somehow misconfigured.

  • A similar issue was posted here - my response there may be worth trying.

  • Like most HTML objects in Construct, you can use the Set attribute action. However you'll probably need to have that set before navigating, so you'll need to do something like set the initial URL to be empty (or some placeholder), then on startup set the attribute and then navigate to the intended URL.

  • It's working fine for me.

  • Try disabling WebGPU in Settings and see if that helps (note there is one setting for the editor, and another for your project). Also try installing any available system software updates or graphics driver updates, as it might be a graphics driver issue.

  • There's a search field in the toolbar there. Doesn't that do what you need?

  • All you need to do is visit https://editor.construct.net/r449-3/, with the version in the URL there, to load that version. It should only take a second.

  • That post is over 10 years old and is pretty out of date in some key details now. Perhaps I should do another blog focusing on the modern WebGPU renderer.

  • You do not have permission to view this post

  • In short, use the Steamworks plugin instead of Greenworks, and export using the Windows WebView2, macOS WKWebView or Linux CEF export options. The documentation tab of the Steamworks plugin has more information.

  • Can you not design your layouts with the right initial objects placed? Then both layout-by-layout memory loading, and spritesheet generation, should work better.

  • Construct attempts to group images based on their usage on layouts in your project (similar to the way layout-by-layout image loading works as described in memory usage. Have you designed your project this way? Or do you rely on a lot of dynamic loading, in which case Construct won't be able to know which images go together?

    Spritesheeting is also a broad and complex topic with a lot of subtle tradeoffs. Even if Construct separated the images to different spritesheets as you want, in some cases it might actually increase memory usage: removing one image might not actually allow the spritesheet to be resized any smaller, and adding a new spritesheet may increase the total memory usage. For example in your image, removing image 3 doesn't look like it'd allow the spritesheet to step down a size, but then you added a new spritesheet. More spritesheets also means reduced runtime performance and a higher download size.

    Spritesheets fundamentally trade-off memory granularity with efficiency. It's hard to design spritesheets for an entire project that never unnecessarily load something. Many projects will use different sets of images at different times within the same layout, and may well make use of dynamic loading and unloading. The only way to guarantee nothing is ever loaded unnecessarily is to turn off spritesheeting, but then that will make the project significantly less efficient.

    In short there are a lot of non-obvious things going on with spritesheeting. A worst case scenario is we add some feature to manually configure this, someone goes and spends hours tweaking their spritesheet layouts, and then it's less efficient than what Construct would have done automatically. Or it significantly increases the download size and load time, and they wonder if it was worth it to de-optimize that. Or it turns out it only reduced overall memory usage by 2% because Construct was actually doing a decent enough job, and something else would have been a much better use of their time. Having spent many years tweaking the trade-offs with the spritesheet generation in Construct, I'd definitely say it's one of those areas that sounds straightforward, but is full of endless edge cases and complexity. Leaving Construct to do a reasonable job automatically is probably good enough.