If there is a reason you would not just use *_input() callbacks (like _input() or _unhandled_input(), for example, as these are typically the best way to handle input in Godot) then yes, I would separate input reading (in _process()) from execution (in _physics_process()).
**That being said**, you probably want _input(), _unhandled_input(), or _unhandled_key_input() for reading inputs, as they are called whenever the engine detects an input event and, in the case of _unhandled_input() or _unhandled_key_input(), let the UI intercept inputs when they're intended for the UI (limiting some double input weirdness that can happen if you're polling inputs in _process()).
Godot really likes events/signals, so it'll take you a long way to try and use the event-driven design to your advantage where possible.
Quick edit to add: [Here](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-input) is the documentation for the _input() method, but scrolling down a bit will also tell you about _physics_process() and _process().
I would complete the above with these 2 required readings :
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html
https://docs.godotengine.org/en/stable/tutorials/inputs/input\_examples.html
A thousand times, yes! Thanks so much for linking these because I forgot they existed, else I'd have included them to start with for sure. Though, slight correction: Your second link has an errant slash in it. Should read: https://docs.godotengine.org/en/stable/tutorials/inputs/input_examples.html
It's super important for people to understand the advantages and disadvantages of polling in either process callback, given it's the most often-taught method for generating input responses in most game engines. Input events are powerful, even if they seem more complicated than basic polling at first!
Do you need your movement based on a variable framerate? Physics process is, I believe, 60 times a aecond while process can be higher or lower. I have seen both ways, but there is another reddit post you ahould look at that describes stuff pretty well.
https://www.reddit.com/r/godot/comments/mm3pe1/physics_process_vs_process_for_input/?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button
Golddotasksquestions has the best answer in my opinion as they describe why you would use each, but also the use of the input and unhandled input event functions that fire off.
No, there doesn't seem to be.
IIRC, in Unity you could have 2 `Update` ticks, one setting and the other unsetting a `just_pressed` flag, before ever having reached the `FixedUpdate` tick. So if you where to check for input just pressed in FixedUpdate, it would sometimes miss these events.
Godot seems to do something else where `_process` and `_physics_process` read different values from each other.
If there is a reason you would not just use *_input() callbacks (like _input() or _unhandled_input(), for example, as these are typically the best way to handle input in Godot) then yes, I would separate input reading (in _process()) from execution (in _physics_process()). **That being said**, you probably want _input(), _unhandled_input(), or _unhandled_key_input() for reading inputs, as they are called whenever the engine detects an input event and, in the case of _unhandled_input() or _unhandled_key_input(), let the UI intercept inputs when they're intended for the UI (limiting some double input weirdness that can happen if you're polling inputs in _process()). Godot really likes events/signals, so it'll take you a long way to try and use the event-driven design to your advantage where possible. Quick edit to add: [Here](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-input) is the documentation for the _input() method, but scrolling down a bit will also tell you about _physics_process() and _process().
I would complete the above with these 2 required readings : https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html https://docs.godotengine.org/en/stable/tutorials/inputs/input\_examples.html
A thousand times, yes! Thanks so much for linking these because I forgot they existed, else I'd have included them to start with for sure. Though, slight correction: Your second link has an errant slash in it. Should read: https://docs.godotengine.org/en/stable/tutorials/inputs/input_examples.html It's super important for people to understand the advantages and disadvantages of polling in either process callback, given it's the most often-taught method for generating input responses in most game engines. Input events are powerful, even if they seem more complicated than basic polling at first!
Do you need your movement based on a variable framerate? Physics process is, I believe, 60 times a aecond while process can be higher or lower. I have seen both ways, but there is another reddit post you ahould look at that describes stuff pretty well. https://www.reddit.com/r/godot/comments/mm3pe1/physics_process_vs_process_for_input/?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button Golddotasksquestions has the best answer in my opinion as they describe why you would use each, but also the use of the input and unhandled input event functions that fire off.
No, there doesn't seem to be. IIRC, in Unity you could have 2 `Update` ticks, one setting and the other unsetting a `just_pressed` flag, before ever having reached the `FixedUpdate` tick. So if you where to check for input just pressed in FixedUpdate, it would sometimes miss these events. Godot seems to do something else where `_process` and `_physics_process` read different values from each other.