0
\$\begingroup\$

I'm sure the problem is me.

Here is a simple look script (from a tutorial, actually).

I'm getting inconsistent results between editor and runtime. I'm guessing its a framerate thing.

Code:

using UnityEngine;
using Mirror;
using Cinemachine;

public class PlayerCameraController : NetworkBehaviour
{
    [Header("Camera")]
    [SerializeField] private Vector2 maxFollowOffset = new Vector2(-1f, 6f);
    [SerializeField] private Vector2 cameraVelocity = new Vector2(4f, 0.25f);

    [SerializeField] private Transform playerTransform = null;
    [SerializeField] private CinemachineVirtualCamera virtualCamera = null;

    private Controls controls;
    private Controls Controls {
        get {
            if (controls != null) { return controls; }
            return controls = new Controls();
        }
    }
    private CinemachineTransposer transposer;

    public override void OnStartAuthority()
    {
        transposer = virtualCamera.GetCinemachineComponent<CinemachineTransposer>();
        virtualCamera.gameObject.SetActive(true);
          
        Controls.Player.Look.performed += ctx => Look(ctx.ReadValue<Vector2>());

        enabled = true;
    }

    [ClientCallback]
    private void OnEnable() => Controls.Enable();

    [ClientCallback]
    private void OnDisable() => Controls.Disable();

    private void Look(Vector2 lookAxis) {
        float deltaTime = Time.deltaTime;

        float followOffset = Mathf.Clamp(
            transposer.m_FollowOffset.y - (lookAxis.y * cameraVelocity.y * deltaTime),
            maxFollowOffset.x,
            maxFollowOffset.y);


        transposer.m_FollowOffset.y = followOffset;
        playerTransform.Rotate(0f, lookAxis.x * cameraVelocity.x * deltaTime, 0f);
    }
}

The code seems right. Watching the values of Vector2 lookAxis reveals that the numbers are slightly different coming into the function based on environment.

Is there something wrong with this code that would give different results between editor and runtime?

\$\endgroup\$
8
  • \$\begingroup\$ Does the lookAxis variable represent a mouse movement delta in pixels, or an analog stick displacement, or something else? \$\endgroup\$
    – DMGregory
    Commented Jul 7, 2020 at 1:45
  • \$\begingroup\$ Hello again @DMGregory. Its Mouse Delta. Whether pixels or otherwise I do not know. \$\endgroup\$ Commented Jul 7, 2020 at 2:17
  • \$\begingroup\$ Are the inconsistencies enough to affect your application in a meaningful way? E.g. if it returns ".2" each frame in the Editor and returns ".199", ".201", ".199" in the runtime, the inconsistencies are probably trivial and unlikely to affect user experience. If you don't know if it's returning a value in pixels, it's possible that the value is in pixels and thus would be affected by the screen resolution. You might have a different resolution selected in the Unity Editor game window than on your actual monitor. \$\endgroup\$
    – Kevin
    Commented Jul 7, 2020 at 2:31
  • \$\begingroup\$ Its a pretty significant difference actually. I'll have to look into the input settings of this one and see if there is a better way to do it. \$\endgroup\$ Commented Jul 7, 2020 at 2:54
  • \$\begingroup\$ Sounds like you're double-dipping by multiplying by Time.deltaTime then. A mouse delta will already be larger on a long frame or smaller on a short frame, given a constant speed of mouse movement, just given that there's more or less time to accumulate travel. By multiplying by deltaTime, you're effectively squaring your frame time adjustment, making it more sluggish at high framerates. \$\endgroup\$
    – DMGregory
    Commented Jul 7, 2020 at 3:26

1 Answer 1

1
\$\begingroup\$

The problem was (in my case) that I didn't realize Time.deltaTime can get in the way in some cases. Explained by @DMGregory and @Kevin in the comments.

Sounds like you're double-dipping by multiplying by Time.deltaTime then. A mouse delta will already be larger on a long frame or smaller on a short frame, given a constant speed of mouse movement, just given that there's more or less time to accumulate travel. By multiplying by deltaTime, you're effectively squaring your frame time adjustment, making it more sluggish at high framerates.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ "using Time.deltaTime in Unity's new input system is not necessary" This is the wrong take-away. This has nothing to do with new versus old input system. This has to do with incremental/relative input (like mouse deltas, which also exist in the old input system in the form of GetAxis("MouseX")) and absolute input (like analog stick deflection, which also exists in the new input system). So you still want to use deltaTime with the new input system, in the same cases you'd use it in the old input system. This case just isn't one of those. \$\endgroup\$
    – DMGregory
    Commented Jul 8, 2020 at 1:39
  • \$\begingroup\$ Changed. I definitely took much about the input systems for granted. \$\endgroup\$ Commented Jul 8, 2020 at 1:40
  • \$\begingroup\$ If you want mouse movement to be fps-independent you're actually better off DIVIDING by Time.deltaTime. This ensures irregularities in distance are accounted for by treating it as a velocity. (Distance/time, m/s, km/h or mph are all good ways to remember this) \$\endgroup\$
    – Weckar E.
    Commented Jul 11, 2020 at 15:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .