PSA: Platform behavior change in r338+

1 favourites
  • 7 posts
From the Asset Store
Simplistic hyper-casual game with nature elements. Tap to switch between the 4 elements and reach a better score.
  • 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.

  • The only downside I found so far is that I used to use this logic to detect the player bonking the head (e.g. mario style on a block). Though theoretically this could falsely trigger at the peak of a jump it never caused any issues.

    if(vectorY === 0 && !onFloor)
    

    With the old version the player would have vectorY set to 0 for a frame when bonking so this would work consistently every time, but with the new version it's not the case as the player never has vectorY at 0. Guess I'll have to find a new way to detect bonking. :)

  • I discovered another potential backwards-compatibility issue this caused. Previously if you set the position of an object with the Platform behavior exactly adjacent to a Jumpthru object (e.g. setting its position to Jumpthru.X, Jumpthru.BboxTop) then the player would land on it. After this change the player now falls through the Jumpthru. This affected the Kiwi Story demo game which does this when the player walks through a door.

    Previously this essentially relied on the bug in the Platform behavior processing things in the wrong order. In Construct an object exactly adjacent to another one counts as overlapping it, and so moving a Platform object exactly adjacent to a Jumpthru is in theory the same as moving the Platform object halfway inside the Jumpthru. So in both cases the correct thing to do is to allow the Platform behavior to fall through the jumpthru, as it didn't land on top from a position not overlapping it. So with the latest fix the Platform behavior now does the correct thing of falling through, but due to the fact the previous bug meant things were processed in the wrong order it allowed it to handle it as landing on the Jumpthru instead.

    Unfortunately this means adjusting the Platform behavior to keep compatibility with the way it used to work is extremely complicated, as it means trying to retro-fit a subtle bug on to what is now the correct code. This also makes it a risky change as making such a change could easily break something else, and maintaining complicated quirks like this long-term is also challenging.

    Meanwhile the workaround is straightforward: it works fine if you position the player slightly above the Jumpthru instead of adjacent to it (e.g. setting its position to Jumpthru.X, Jumpthru.BboxTop - 1). So while once again we are always extremely reluctant to make breaking changes, I think we will have to go with adjusting projects instead of changing the Platform behavior. Hopefully this is easy as it is a straightforward change to make. I made this change in a single place in the Kiwi Story project and it fixed the problem. So this is another thing to watch out for with the latest change to the Platform behavior.

  • Ashley See the video below, it was tested on r344, when I set the min fps to 60, all the jumps are good, just as designed, when I remove the min fps, the jump just doesn't work as I expected. With this fix, shouldn't it behave the same regardless of fps?

    youtube.com/shorts/BfAjadTSSmc

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm afraid it's impossible to comment on just a video. If you think there is still a problem please file an issue following all the guidelines, as we need all that information to be able to investigate and help.

  • R344 Platform inconsistently when side close to the wall still moving. Since this is not a bug, it was not committed to github, just wanted to discuss it here.

    Take the built-in platform game example as an case: In the R366 version, the Platform will not be considered as 'is moving' when it side close to the wall, When he moves to the edge of the wall, he will stop and no particle animation will appear. But on R344 it behaves inconsistently.it will still be moving.

    R336: When walking on a wall, it stops.(Animation: Idle, particles: stop)

    R344: When walking on the wall, it will continue to be moving.(Animation: Walk, particles: playing)

    This is a screen recording of the same example in different versions, you can observe the difference between R336 and R344.

    Open Example .c3p R336 R344
    #open=world-to-hud-position Example1-R336 Example1-R344
    #open=shockwave-spell Example2-R336 Example2-R344

    details: Windows 10 / Chrome 113.0.5672.129 / Approx 8 GB / NVIDIA GeForce RTX 3050 / Direct3D11 / WebGL 2.0 / Monitor 60 Hz

    ----

    Is this a BUG? Not exactly. It's just a tricky way to rely on "abnormal" platform performance. Because on other monitors, the above situation is different. Here is an observation of the same case at 144Hz:

    Example2-R336

    R344: When walking on the wall, it's twitching

    R336: When walking on a wall, keep animation playing.

    Apparently R344 is look better.

    In order to adapt to this change, I had to change the method of control player animation, so that walking on the wall can stop and no longer create dust particles. For example, in the case of CAE BRIDGE(#open=cave-bridge) , VectorX is used to judge based on the speed of movement.

    If possible, I wish Platform could have more control over the behavior near the wall. For example when close to a wall:

    - keep moving

    - slow down until stop

    - stop immediately

  • So did this bug just affect gravity? If so then it's a simple fix if you do some minor caculations and testing and it's only a good thing that you made the change.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)