arenos-nexus/Arenos Nexus/Library/PackageCache/com.unity.inputsystem@be6c4fd0abf5/Documentation~/timing-mixed-scenarios.md

93 lines
3.6 KiB
Markdown
Raw Permalink Normal View History

2025-09-25 22:01:28 +02:00
# Mixed timing scenarios with fixed and dynamic input
There are some situations where you might set the Update Mode **process in Dynamic Update** even when using input code in `FixedUpdate`, to minimize input latency, as described in the [previous section](./timing-optimize-fixed-update.md).
In this situation, for discrete events you must ensure that you use [`WasPressedThisFrame`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPressedThisFrame_) or [`WasReleasedThisFrame`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasReleasedThisFrame_) in `Update`, and pass through a variable to your `FixedUpdate` code to indicate the event happened. There may still be some latency between the frame in which the event occurred, and the next `FixedUpdate` call.
For example:
```c#
using UnityEngine;
using UnityEngine.InputSystem;
public class ExampleScript : MonoBehaviour
{
InputAction jumpAction;
bool jumpPressed;
private void Start()
{
jumpAction = InputSystem.actions.FindAction("Jump");
}
private void Update()
{
// read discrete jump pressed event here:
if (jumpAction.WasPressedThisFrame())
{
// set this variable to true, for use in FixedUpdate
jumpPressed = true;
}
}
void FixedUpdate()
{
if (jumpPressed)
{
// apply jump physics here
// set the variable to false so that the jump pressed physics are only applied once
jumpPressed = false;
}
}
}
```
## Minimum latency in mixed timing scenarios
A technique to give the user the feel of absolute minimum latency while still using `FixedUpdate` is to respond as fast as possible in `Update` giving some visual feedback, but also respond to that same input in `FixedUpdate` for your physics system code. For example, you could display the start of a "jump" animation immediately in `Update`, while applying physics to correspond with the "jump" animation in the next available `FixedUpdate` which might come slightly later.
In this scenario, set your Update Mode **Process events in Dynamic Update** which gives you the fastest response in your `Update` call. However for the reasons mentioned in the previous section, this might mean you miss discrete events if you use methods like [`WasPressedThisFrame`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPressedThisFrame_) in your `FixedUpdate` call. To avoid this problem, use a variable to pass through the pressed/released state of the discrete event from the event handler to your FixedUpdate call, and then clear it once your FixedUpdate code has acted on it. For example:
```c#
using UnityEngine;
using UnityEngine.InputSystem;
public class ExampleScript : MonoBehaviour
{
InputAction jumpAction;
bool jumpPressed;
private void Start()
{
jumpAction = InputSystem.actions.FindAction("Jump");
}
private void Update()
{
// at high FPS, its fastest to read actions here:
// read discrete jump pressed event here:
if (jumpAction.WasPressedThisFrame())
{
// start jump animation here
// set this variable to true, for use in FixedUpdate
jumpPressed = true;
}
}
void FixedUpdate()
{
if (jumpPressed)
{
// apply jump physics here
// set the variable to false so that the jump pressed physics are only applied once
jumpPressed = false;
}
}
}
```