Physics changing based on FPS

Unity Engine
, , , , ,
1

Hi, I’m fairly new to coding so I don’t really understand much of the terminology yet.

I’ve been trying to make a jump script for my game but the results have been giving me a headache past few days.

The problem is: changes in FPS causes the game physics to be different. In my case (as far as I can tell) the difference in fps causes the jump to be higher with lower fps. I tried running the game on two different PCs and the jump is a lot higher on the weaker PC.

Things I tried:

-Calling the jump in fixed update
-Calling the jump in update (I added time.deltatime to the jump force to make up for it)
-Calling the jump in update (without time.deltatime)
-Changing gravity under physics in project settings

I tried reading up online about others having similar issues but I didn’t find anything that could help. I am totally bamboozled.

Here’s what I have right now in my jump script:

using UnityEngine;

public class PlayerJump : MonoBehaviour
{
    
    public Rigidbody rb;

    
    public float jumpForce = 7000f;

    private bool startJump;

    public bool IsGrounded
    {
        get; private set;
    }

    

    
    private void Start()
    {
        rb = GetComponent<Rigidbody>();
    }


    void Update()
    {
        startJump = Input.GetButtonDown("Jump");

        if (startJump && IsGrounded)
        {
            jump();
        }

    }

    void OnCollisionEnter()
    {
        IsGrounded = true;
    }

    void OnCollisionExit()
    {
        IsGrounded = false;
    }

    private void jump()
    {
        rb.AddForce(Vector3.up * jumpForce * Time.deltaTime, ForceMode.Impulse);
    }

    


}
2

The reason is that you apply the force only once, when the button is pressed, but use Time.deltaTime to calculate it. So with higher frame rates, the force is lower. Time.deltaTime is usually used for continuous forces/movement. Remove Time.deltaTime from the jump method, and it should work.

2 Likes
3

Yeah, never use Time.deltaTime with AddForce, choose the proper ForceMode instead, which will factor in deltaTime when necessary.

From the documentation:

“continuous”: Intended to be applied over multiple frames, factors in deltaTime and should be called from FixedUpdate.
“instant”: Intended to be called only once, does not factor in deltaTime and can be called from anywhere.

1 Like
4

Thanks for the replies! That did it! I can’t believe the solution was so simple, I was scratching my head for hours…
Also what would you say is the general idea of when to use FixedUpdate and when not to? Because I was under the impression FixedUpdate takes deltatime into account and Update does not.

5

Generally, if something interacts with physics, it’s not a bad idea to put it in FixedUpdate.

More specifically, if something happens over multiple physics timesteps / frames, then it needs to be in FixedUpdate (e.g. AddForce with a continuous ForceMode or raycasts / queries that should continuously check for hits). If something only happens once, then it doesn’t matter where it’s called from (e.g. AddForce with an instant ForceMode or a single query).

The reason is that FixedUpdate does not 1:1 relate to Update. Depending on the FPS, there might be multiple FixedUpdate per Update or none at all. If you don’t put continuous physics code in FixedUpdate, it might run too often or not often enough, making your physics code framerate-dependent.

Not sure what you mean by “takes deltatime into account”. FixedUpdate runs at a fixed timestep (Time.fixedDeltaTime) but you should still apply deltaTime where necessary. Without deltaTime, your calculations in FixedUpdate might not depend on the framerate but they’ll instead depend on the fixed timestep. If you ever need to change the timestep, your calculations will slow down or speed up. Multiplying by deltaTime turns a value from “per frame” / “per timestep” to “per second”, which is usually a more useful and stable unit to work with.

1 Like