_physics_process doubts

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By 2plus2makes5

If a node uses _physics_process(delta) should all the other nodes, especially the scenes that contains it, use it too even if they don’t do physics to avoid eventual synchronization issues?

Or said in other terms if a node do physics then the scene that includes it for transitivity does physics too even if it doesn’t use physics instructions and so we should use _physics_process?

Or said again in other terms should a project use only one type of process? But if so isn’t _process basically useless since collisions are essential?

If not we are using both _process and _physics_process, is there any warning or something we should know about their interaction?

If different nodes can use different process functions can a single node use _physics_process for physics and _process for everything else?

2
:bust_in_silhouette: Reply From: avencherus

I suppose the rename to physics from fixed, is a bit ambiguous.

There are two game loops provided by the engine. One with fixed timesteps (what you would use for physics) and the variable timestep version (generally for animation).

They’re not limited to these things, it mainly boils down to how consistent you want the delta and frame execution to be. For most things in my experience I use the fixed/physics loop.

Thanks for the answer! :slight_smile:
So i should use only one or the other right?
Sorry if i bother you but what happens if i use the _physics_process and the game runs slower than 60fps?

2plus2makes5 | 2018-05-04 16:22

You can use both at the same time if you so desire. I’m fairly sure that _process() can potentially execute multiple times during the time between one frame and the next. The delta is passes will be variable. The naming of it in places is IDLE, so it may be intended to be space for low priority things to occur in the left over time.

So if you have something that deals with toggling a state exactly once a frame, you’ll want physics process.

You have to try these things and see the pros and cons for your particular logic.

As far as what Godot does when its fixed processing is overwhelmed, I don’t know, I haven’t had time to study the source as I would like. You can review the main loop here: https://github.com/godotengine/godot/blob/master/main/main.cpp#L1719

At a glance it has the standard time accumulation, so it can potentially execute multiple frames in one iteration to catch up. There is some local iters variable, but it doesn’t appear to get used for anything.

All I can say is that if your game lags at the target frame rates, a fixed time step loop generally is designed to account for all the frames regardless of this, but it can fall behind permanently if the performance demand isn’t a temporary hiccup. If you have these performance issues, it means either:

  • You should begin exploring optimizations.
  • If that’s not possible, lower the frame rate.
  • If not an option, then you have too much game and too little PC, so raise the minimum system requirements.

avencherus | 2018-05-05 04:56

Thanks for the detailed answer! :smiley:

2plus2makes5 | 2018-05-05 08:18

Quite welcome. =)

avencherus | 2018-05-06 00:35