Godot-proposals: _Process function that has a customized framerate

Created on 14 Oct 2019  路  5Comments  路  Source: godotengine/godot-proposals

Describe the project you are working on:
A 2D pong game.

Describe the problem or limitation you are having in your project:
It would be nice if I had a _process function or _physics function updated at a custom framerate.

Describe how this feature / enhancement will help you overcome this problem or limitation:
Would be usefull for certain functions that doesn't require to run every frame, maybe every half a second, or maybe a couple seconds or just 10 times in a second.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
Similar function to _process but it takes another argument that changes the function FPS, similar to a delay timer in miliseconds.

Describe implementation detail for your proposal (in code), if possible:
_process(delta, delay): // delay means the time between calls to this function.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Sure, can be done with a combination of timers, but is not a clean solution.

Is there a reason why this should be core and not an add-on in the asset library?:
Would make process that doesn't require to be run a full FPS like pathfinding or input check or periodic events, much more simpler, not require node setup with timers and overall improve the project optimization (since the function wont run at every frame).

archived core

Most helpful comment

Sure, can be done with a combination of timers, but is not a clean solution.

It's literally a matter of placing Timer, connecting timeout to the method and enabling autostart. The only problem would be that timeout might not happen at exactly 'wait_time' cycles, so you don't have accurate delta.

All 5 comments

Sure, can be done with a combination of timers, but is not a clean solution.

It's literally a matter of placing Timer, connecting timeout to the method and enabling autostart. The only problem would be that timeout might not happen at exactly 'wait_time' cycles, so you don't have accurate delta.

Yes, this is exactly what timers are intended to be used for.

If you need to run something every N physics frames, you could also perform a manual check:

extends Node

var physics_ticks := 0

func _physics_process(delta: float) -> void:
    physics_ticks += 1

    if physics_ticks % 10 == 0:
        # Will print 6 times per second by default
        print(physics_ticks)

I wouldn't recommend this unless you need something to be synchronized to physics, as you will need to adjust it manually if you ever change the physics FPS.

Also, I noticed we have Engine.get_frames_drawn(), but do we have an equivalent for the number of physics frames simulated?

Would make process that doesn't require to be run a full FPS like pathfinding or input check or periodic events

While I agree about pathfinding not having to be run every frame, you almost always want inputs to be polled every frame to decrease input lag :slightly_smiling_face:

@KoBeWi 馃憤 馃挴

I'll close this, as Timer nodes or a custom timer can already be used to achieve this efficiently.

Was this page helpful?
0 / 5 - 0 ratings