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:
- 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.
- 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.