Ashley's Forum Posts

    This forum post will serve as preliminary documentation for the new support for WebGPU in r337 and how to update effects to support it. As WebGPU is an entirely new graphics technology, it uses a completely different sharing language called WGSL. All built-in effects in Construct have already been ported to WGSL. However third-party effects must be converted to WGSL by their developers.

    To get started, download the latest effect SDK files from the Addon SDK manual. This now includes WGSL ports of both sample effects.

    For background reading see the blog posts A brief history of graphics on the web and WebGPU and From WebGL to WebGPU in Construct. There is another post about porting WebGL shaders to WebGPU, but it is currently out of date referring to an older syntax that no longer works, so to avoid confusion this is not linked to here.

    Compatibility

    All existing third-party effects will default to only supporting WebGL. If a project uses an effect that only supports WebGL, it will block enabling WebGPU for that project. The user will have to download an updated effect with support for WebGPU in order to enable WebGPU for their project, otherwise their only other option to enable WebGPU is to remove the effect from the project.

    Note that Construct's WebGPU renderer includes an upgraded effect compositor. As a result in some cases there may be differences between the way WebGL and WebGPU effects are handled. Most of the time these differences are likely to be bugs, although some differences may be intentional improvements.

    Enabling WebGPU rendering

    Currently to enable the WebGPU renderer the following must be done:

    1. Use Construct 3 r337+ (r344 is the stable release as of May 2023)
    2. Use Chrome or Edge 113+ (stable release as of May 2023)
    3. In Project Properties, under the 'Advanced' section, set 'Use WebGPU' to 'Yes' (note the default is 'Auto' which currently defaults to off)

    To verify the WebGPU renderer is in use, preview the project, press F12 to open the browser console, and look for the console log message indicating Construct's renderer. There should be a line that reads:

    [C3 runtime] Hosted in worker, rendering with WebGPU

    The "rendering with WebGPU" phrase indicates the WebGPU renderer is in use. If it says "rendering with WebGL" then it is not using the WebGPU renderer and so you will not be able to test WGSL shaders.

    Be sure to test your shader works with both WebGPU and WebGL. It should look identical in both cases, as that is what users will expect (although you could improve the quality or performance using additional WGSL features if possible).

    Further documentation

    As of October 2023 the documentation for writing WGSL shaders is now available in the Addon SDK documentation for WebGPU shaders.

    Conclusion

    Construct's WebGPU renderer has some way to go before it is production-ready, but we are beginning the process of rolling out WebGPU support in Construct over the coming months as browsers start to ship support for WebGPU, starting with Chrome 113. As a first step third-party effect addons need to be ported to WGSL so the effects don't block users upgrading to the WebGPU renderer. The preliminary support for WebGPU in Construct 3 r337+ and this preliminary documentation should help developers get started on this in advance of WebGPU support being extended further to general Construct users.

  • Inventing an entire UI system that replicates what HTML and CSS can already do is such a vast project that I judge it to be infeasible anyway with our resources. So it's not like needing to supporting consoles suddenly makes an in-engine UI library feasible.

    I think the all-round best solution is for consoles to support HTML5 games!

  • I'm afraid there's no way to disable this at the moment. I filed an issue with Google about trying to disable it, but nothing has been done yet.

  • In short, it's because consoles don't support HTML5 games. It's a shame as the technology works brilliantly, especially with the latest features like WebGPU, and JavaScript performance is extraordinary these days. If consoles did support HTML5 games, we'd add support for consoles at no additional cost.

    However with no HTML5 support, the only option is to rewrite the entire engine in technologies that consoles do support. This might even end up needing a rewrite per console platform. This is a project that would probably take several staff working for years to get anywhere near full compatibility, if it's even possible - browser things like iframes and the HTML Element object with custom HTML and CSS may never be portable. That would be hugely expensive to the company - and a huge loss if it wasn't compensated by a corresponding vast increase sales - and mess up our whole single-codebase strategy that has worked so well for many years (and which I think is a large part of the reason we even came this far).

    There's tons more to say about the subject, and I totally get it that people are very keen for this, and I'd do it if I thought it was realistic for us. But for the time being I think third-party porting services is a pragmatic compromise. What would really make it realistic is for consoles to support HTML5 games. The more people who push console makers for that, the more it will help incentivize them.

  • You do not have permission to view this post

  • Some time ago I spent a while updating this and mobile devices should no longer resize the window when the virtual keyboard appears - it should instead be shifting the display upwards or just overlaying the keyboard, not resizing the view. I just checked with Remote Preview on my Android phone and it is indeed working like that for me.

  • It seems to still be working fine for me. It's difficult to help without more details about precisely what you're doing.

  • The renderer indicates a major performance caveat. Software rendering may be in use. This can result in significantly degraded performance.

    This generally means your graphics drivers are either broken or out of date and so now you're getting software rendering instead of hardware acceleration. Try installing any available system software updates, or updating the graphics driver. You can check the status of the GPU in Chrome by visiting chrome://gpu.

  • The IDragDropBehaviorInstance documentation includes the isEnabled property which can be used for that.

  • It's up to you, but in general I would say if a function affects a specific instance of an object it would be better as a custom action.

    For example a "show game over" task is probably better as a function, and a "play object animation" task is probably better as a custom action.

    It's a similar question as to whether to use a global function or class method in programming languages - often you can use either and the choice is a judgement.

  • I used an image editor and checked the actual text colors. They're identical. The color does not change. It's just that sometimes thin lines look different to thick lines.

  • If I download that project and open it in r335, it seems to preview fine.

    As ever it's difficult to help unless you can file an issue following all the guidelines, as we need all that information to be able to help.

  • The functions feature was redesigned in 2019. Now it's built-in and you don't need to first add the Function object.

  • If you choose a local font available only on your device, and other devices don't have it, then those devices will pick a different font as a fallback, causing a different appearance. If you want a consistent appearance, try importing a Web Font and using that instead.

    The color isn't changing - it's just an illusion caused by the different thickness of the text.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads