Handling input in _Input() versus _Process()

Help
1

Godot Version

4.2.2.

Question

I’m wondering what the functional differences are between handling my input in _Process() and in _Input(), and whether there are good tips or best practices for when to do which.

If I’ve got my_input bound to the left mouse button, what are the important differences between these two approaches? Are either of them selected for more long-term support or development?

public override void _Input(InputEvent @event)
{
	if (InputMap.EventIsAction(@event, "my_input") && (@event as InputEventMouseButton).Pressed)
	{
		//Logic here
	}
}

public override void _Process(double delta)
{
	if (Input.IsActionJustPressed("my_input"))
	{
		//Logic here
	}
}

The main difference I can see is that _Process() gives you access to delta, which can be useful for a variety of reasons. I don’t see any competing or complementary benefit to using _Input(), though, so I’m wondering why I shouldn’t just put everything in _Process. Consolidating input in one place feels cleaner, and lets me similarly consolidate higher-level logic for different input modes. I assume there’s a downside I’m not aware of yet!

2

Input is event based, process is called each frame
You usually put your movement handling inside physics_process as it is called once per physics tick rather than once per frame
I use input for event based stuff like the player pressed escape

2 Likes
3

Since the two approaches target different use-cases, as mentioned in the previous post, I don’t see any if them being deprecated or removed.

1 Like
4

Yeah they’re not getting deprecated both are very different. Best practice is to not handle input in process though

1 Like
5

That’s a good point about process versus physics_process. Is there any reason we shouldn’t handle particular input types, or generally any input, in physics_process?

Currently I’ve got some logic in input and some elsewhere, and I’m writing high-level logic for disabling or modifying what input types are possible based on game or UI state (for example, disabling input during a cinematic camera or a tutorial). It feels like it would be cleaner to do this if all input were handled in the same place, rather than putting checks for input modes in multiple different functions. Not a huge deal, but it made me question why I’d be using input in the first place.

1 Like
6

I would use input for event based inputs, such as the player hitting the escape key or left clicking the mouse.

I would use physics_process for inputs that last in time, such as the player pressing the w key to go forward.

I would also use input for mouse movement stuff since it is event based as well

2 Likes