- Home /
How can I prevent Input.GetAxis from sporadically reporting deltas of 0.0?
I'm using the mouse to drag an object around. On every single frame, I use that object's change in position to drive certain effects (like rotation, color, etc.)
Unfortunately, these effects were very jittery, even under smooth, constant mouse movement. So I decided to log Time.frameCount, Input.mousePosition, and Input.GetAxis deltas inside an Update method. Here's what that looks like while making smooth circles with the mouse:
Frame: 31 Position: (477.3, 230.8, 0.0) Delta: (1.8, -1.3)
Frame: 32 Position: (477.3, 230.8, 0.0) Delta: (0.8, -0.4)
Frame: 33 Position: (522.5, 217.5, 0.0) Delta: (3.5, -0.6)
Frame: 34 Position: (522.5, 217.5, 0.0) Delta: (0.0, 0.0) <--
Frame: 35 Position: (565.5, 220.4, 0.0) Delta: (3.7, 0.9)
Frame: 36 Position: (565.5, 220.4, 0.0) Delta: (0.0, 0.0) <--
Frame: 37 Position: (586.3, 239.0, 0.0) Delta: (1.3, 2.2)
Frame: 38 Position: (589.3, 260.5, 0.0) Delta: (0.2, 1.4)
Frame: 39 Position: (589.3, 272.4, 0.0) Delta: (-0.2, 2.4)
For some reason Input regularly fails to update the mouse on some frames, as seen on frames 34 and 36 above.
Things I've tried:
Swapping out my mouse and using the MacBook trackpad to rule out hardware polling issues. (same results)
Caching deltas and reusing the previous when 0.0 is detected, correcting for missed frames after. (feels kinda "swimmy")
Calculating my own deltas using mousePosition (same results, naturally)
Lerping the mouse-driven object's position. (degrades response time)
It's been suggested that Input is only updated 20 times per second (or less) under constant mouse movement. I'm testing at 60 fps, so that would explain the behavior I'm seeing.
But I'm at wit's end as to how to fix or compensate for this. For example, how could you possibly create a smooth first person shooter when view angle is directly driven by mouse movement but the mouse is considered momentarily stationary at least 1 out of every 20 rendered frames?
Thanks for any insights!
The polling of Input is done on Update() or FixedUpdate()? If its Update(), did you try it in FixedUpdate()?
From my research, I understand that Input is done at the beginning of Update(), and that you should avoid polling Input in FixedUpdate() because it is not synchronized with the framerate and therefore you could miss your chance to respond to updates or events.
I could always be corrected, though, because it's all new to me!
Yes, input should not be in FixedUpdate() at least for buttons, I'm not sure about axes. I tried having a Coroutine wait for fixed update and it constantly missed my button presses.
I actually just tested this debug in FixedUpdate(), and yeah, it has the same issues.
Fwiw, I have my Fixed Timestep set to 0.04 for performance reasons - 25 fixed frames per second - which is close to the 20 fps that Input is supposedly running at, so I guess it's not surprising they exhibit similar behavior.
You could try adding some smoothing yourself by applying the average of the last 2 or 3 deltas. Quick and dirty but it may help ;)
Your answer
Follow this Question
Related Questions
Achieve framerate independent AddTorque rotaion with mouse drag. 2 Answers
Why does holding down any button cause ~20-30 FPS loss? 1 Answer
[SOLVED] Input.GetAxis("Horizontal") returns wrong value? -1 Answers
Help In Making a SphereCast for 3D Tire! Working RayCast Script included! 0 Answers
Get axis literal keyboard or mouse value... not possible? 0 Answers