How can I make a gdscript _process function run less often, like once every 15 frames instead of as fast as it can? Is there a built in function or would it be best to just count the frames then run after 15?
#How to make _process run less often
mellow spear
mighty onyx
Why do you want to or think you need to do this? This has code smell all over it.
mellow spear
Just to optimize games in general. I have a lot of enemies in the game at once, and their scripts don't need to run that often.
Im not quite sure what code smell all over it means.
lapis knot
Unless they are stationary, I don't see why your enemies wouldn't need to run the code that often. And you shouldn't worry too much about the number of enemies on screen honestly...
https://www.youtube.com/watch?v=_z7Z7PrTD_M
mellow spear
Okay, even if it isn’t necessary, how is it typically done? Just for learning. Worst case scenario it doesn’t work, I learn how it works, and I got back to the old code.
Also I don’t see why it would never be necessary. If I have a very expensive path finding algorithm, I don’t really need them to reroute every frame.
slender nova
Okay, even if it isn’t necessary, how is it typically done? Just for learning. W...
Uh, I will say this: You almost definitely will not ever really need to make _process run slower. However, you may have something you only want to happen every fourth process tick or so. If that's the case, you can implement a global timer than emits a signal, and have anything that needs to happen only so often subscribe to that signal with a function. You could call the function something like _on_tick() or something like that. I've done this before, and it works just fine. You can create a global group for anything that will be receiving this signal, and have the node or autoload that contains the timer also connect the timer's timeout signal to all things in that group so long as they have the correct method. This automates connecting all these up so you don't have to do it by hand every time.
slender nova
A more advanced approach might be not using a timer, but instead writing the timer as a ticking-down variable in a script, using the _process(delta) there to tick it down by delta amount each _process tick. You can have another variable store the accumulated delta values, and pass that accumulated amount each time you have a signal emit when the timer you created in the script hits zero. That way you get your slower tick signal happening without sacrificing access to the frame time. This is probably only important for visual sync of certain things to avoid weirdness that can sometimes occur otherwise.
Here's an example of the timer script:
extends Node
const TIMER_RESET: float = 0.34 # just over 1/3 a second, so this will happen three times/second
var timer_tick: float = TIMER_RESET
var accumulated_delta: float = 0.0
signal tick(acc_delta: float)
func _process(delta):
timer_tick -= delta
accumulated_delta += delta
if timer_tick <= 0.0:
tick.emit(accumulated_delta)
timer_tick += TIMER_RESET
accumulated_delta = timer_tick - TIMER_RESET
func _ready():
var timer_subscribed: Array[Node] = get_nodes_in_group("timer subscribed")
for sub in timer_subscribed:
if sub.has_method("_on_tick"):
tick.connect(sub._on_tick)
and here's what the receiving function looks like with no code, (just comments of course):
func _on_tick(acc_delta: float): # Use "_acc_delta" if not using. Avoids non-critical error message.
# Do some code here
# pass lets the code execution continue without error when there are no lines of real code in the function yet.
pass
That makes sense, thank you!