Ashley's Forum Posts

  • Construct remains primarily a 2D engine and so things like collisions continue to work in 2D. You can add logic to "fake" 3D collision detection such as in the First-person platformer example, but Construct is not a full 3D engine, it's a 2D engine with a few 3D features that you can use creatively.

  • If you want to use an external text editor, save the project to a folder, and then you can edit individual files separately.

  • Please file an issue following all the guidelines. It's difficult to help if you miss out required details, like the system info which tells us about your system and software details.

  • Please note suggestions in replies to this thread will not be considered. See the original post for details on posting suggestions.

  • I meant that if they already have the tech to run an HTML5 game in browser, they should(?) be able to run it native?

    Yes, the tech is all there - but they need to add support for running HTML5 games inside console apps so they can be distributed through the stores.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You don't need to use scripting to call a function from a string. The event system allows for this too with the function maps feature.

  • Summary: in Construct 3 r338+, the Platform behavior may jump a little higher or further at typical framerates like 60 FPS, mainly when using double-jumps. This post explains why this change has happened and what you can do about it.

    Framerate dependent jump height/distance bug

    A subtle framerate dependence in the Platform behavior was recently discovered. This affected all existing Construct games using the Platform behavior. At higher framerates the player could jump slightly higher or further. This appears to mainly affect double jumps - our testing has not shown a significant difference with single jumps. For example at 60 FPS a wall may have been just about too high to jump on to, but when playing at 120 FPS the player could just about jump on top of the wall.

    In other words the platform behavior had a shortfall depending on the framerate, and the lower the framerate the greater the shortfall. So at a theoretical infinite framerate achieved the full jump height with no shortfall; at 120 FPS there was a tiny shortfall; and at 60 FPS there was a slightly larger shortfall. Historically most displays have run at 60 FPS and so this was not a problem in practice, but these days the greater prevalence of high refresh rate displays means this has become a more significant problem. For example in some cases the player could successfully make a jump at 120 FPS when it's impossible at 60 FPS.

    The framerate dependence issue has been fixed in r338. This means the jump height and distance at all framerates should align to the theoretical maximum (as if there was an infinite framerate), subject to floating point precision issues (which generally cause only a sub-pixel variance).

    Backwards compatibility implications

    However now the issue has been fixed, it means at the most common 60 FPS framerate, the player can jump slightly higher or further. This may mean that the player can now achieve jumps that were previously impossible, which could affect your level design.

    Note however that such cases are likely existing bugs in your project. For example if a player can now achieve a previously impossible jump at 60 FPS, it could well have already been previously achievable at 120 FPS, because the bug allowed a greater jump height/distance at higher framerates. Now the bug is fixed it aligns the jump height/distance at 60 FPS to the same distance achievable at higher framerates. So it is now more consistent and if you need to change your level design, it means it will likely then be robust at all framerates, rather than having different outcomes depending on the framerate.

    We take backwards compatibility extremely seriously and changing how existing features work is something we work hard to avoid and are extremely reluctant to do deliberately. However in this case projects were already affected by a framerate-dependency bug, and the fix makes sure it is consistent across different framerates. The change also appears to be limited to double-jumps, so projects only using single jumps should not have any significant difference. The fix helps ensure the Platform behavior is more reliable overall for the future. Leaving the bug in place would have meant on-going framerate dependency problems lasting indefinitely.

    Compensating for the change

    Some projects may not be affected and won't need any changes. Please test your projects carefully in r338+ to check for any differences. If it's a problem for your project that previously unachievable jumps can now be reached, there are a couple of options you have:

    1. Adjust the level design to compensate. For example if a jump from one platform to another that is not meant to be achievable can now be reached, then move the platforms slightly further apart. Alternatively add invisible objects that block movement to guarantee the jump is impossible.
    2. Slightly reduce the jump strength to compensate. You may need to experiment with this to get the right number, but it looks like subtracting gravity / 120 from the jump strength compensates the double-jump height. For example if the jump strength is 500 and gravity is 1500, then subtracting 1500/120 = 12.5 gives a jump strength of 487.5. This may affect the single-jump height though, and you might want to try varying other parameters.

    Conclusion

    The Platform behavior may double-jump slightly higher in r338+. This was done to fix an existing framerate-dependency bug that was already affecting projects, and also ensures better reliability for the Platform behavior in future. However as it is a change to the way the movement works, existing projects should be carefully tested and adjusted if necessary.

  • You do not have permission to view this post

  • Unless you file an issue following all the guidelines, it's impossible to tell what's going on, and there are several common reasons that aren't actually Construct's fault. Perhaps you have a browser extension that's breaking Construct. Perhaps the project is corrupt. If anyone runs in to a problem we need them to file an issue following all the guidelines, as that's the only way it's possible for us to help. No software is perfect and despite our best efforts often fixing dozens of bugs a week, sometimes mistakes happen, and we need users to co-operate in order for us to help them.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • A red bar means an error occurred during loading. You'd need to look in the browser console log messages to see what the error was.

    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!