All Questions

Community

F
Vitalii Franchuk

User input is delayed by one physics process call

So, if I get it right, this state-machine based code would cause 1 _physics_process's delta delay before user's input will be processed.

For example, character is on the floor and in the idle state. When the user presses a move button, idle state would receive non zero velocity vector from the parent's get_move_direction method. In that case, idle state will call transition to move state. But user's input will not be processed immediately.

Delta in _physics_process is very tiny. But can this delay in input processing affect game feel somehow? It could be that applying players input will be delayed to the next frame.

Example:

_physics_process is called, user pressed a button, but we simply call transition to move state and not actually applying this movement

_process is called, frame is rerendered into the screen

_physics_process called again, now the move state applies movement

But we have already missed whole frame!

Maybe it would be great to try another solution:

  1. create method should_transit_to(current_velocity), which will return state name to transit to or null if all ok.
  2. in the state machine call should_transit_to, if not null returned then transit to new scene and run this block again. But if null is returned then we can call physics_process and we will know that state can immediately react to players input.
  • Nathan Lovato replied

    Definitely, a one-frame delay is a one-frame delay. It can be hard to spot but it'll affect the game.

    I have to step through the code and think about it. Maybe calling State.physics_process() directly after calling State.enter() in StateMachine.transition_to() would do the trick.

    Thanks for pointing this out.