Replace _physics_process() and _process() with _tick()

[josefkaragoli]

Describe the project you are working on

General project

Describe the problem or limitation you are having in your project

Currently, the general consensus is to have _process() used for non-physics tasks and _physics_process() for physics (it was even renamed from _fixed_process() to make this distinction clearer). However, in my opinion:

1) it isn't really beginner-friendly

I have seen many beginners use _process() or _physics_process() exclusively which isnt good practice - using process() can cause physics errors and _physics_process() can jitter on different refresh rate monitors

2) integration between them is not immediately clear

For example, if you were to have a character's motion (physics) drive animation (process), you would have to do a lot more work to be able to integrate them both, and mixing them both is not properly synchronised in most cases.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

My proposed solution is to use a system similar to Unity and UE4, which is to always use a fixed timestep, and use interpolation so that it can be displayed on screens that have a different refresh rate to the timestep (see https://github.com/lawnjelly/godot-smooth). This would effectively nullify the need for _process(). A fixed timestep is much easier to understand conceptually for beginners and also reduces some extra steps.

Additionally, it would help with networking as everything can be placed into a fixed timestep and the engine can handle interpolating it to look smooth on different refresh rate displays.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This functions just like physics_process(), it is called every 'tick' which the engine internally interpolates to work well on displays.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This enhancement is generally quite compatibility-breaking and changes the programming workflow.

Is there a reason why this should be core and not an add-on in the asset library?

This enhancement requires the removal of process and physics_process which is core and not possible as an asset

I look forward to seeing others opinions and am open-minded to any other solutions.

[YuriSizov]

Fixed framerate makes sense for physics and some other stuff, but not for rendering or reading user input for example. These two methods have very distinct applications, and as you've said using one exclusively doesn't make much sense. One must learn how to leverage both.

[Zireael07]

Unity has Update() and FixedUpdate(), so the equivalent to our process() and physics_process().
UE4, from what I can see, has Actor Tick() which is once per frame, so process()... and no fixed (physics) processing unless you tick a box somewhere deep in settings.

[josefkaragoli]

My biggest issue is the fact that animation driven by physics/movement cannot be placed in physics_process() since it doesn't require actual physics (collision detection etc) and would be bad practice to run it on the physics thread. But, it needs to be run at the same interval as physics in order to prevent desynchrony/jitter. This to me does not make sense to implement.

If I'm lacking some information I can close this

[Calinou]

and _physics_process() can jitter on different refresh rate monitors

See #671 and #1936. There proposals can coexist with the existing _process function.

[josefkaragoli]

Ok. closing