godotengine
Add a Frames option to the timer node
Adds a frame option to the Timer node. This is useful for frame-timed games such as doom-likes or tick-games.
I'm uncertain about using wait_time as fake ints for frame counting but introducing a hell of new variables seemed not optimal as well.
Looking forward to any feedback.
- Bugsquad edit, closes: https://github.com/godotengine/godot-proposals/issues/10879
Thank you for your contributions, but I would recommend opening a proposal first to gauge interest in this.
Implementation aside, personally, this feature is superfluous. Especially nowadays, a strict dependency on framerate is generally undesirable and prone to very, very nasty bugs.
If you want to gather seconds from a count in ticks, keep in mind you can evaluate expressions inside of the Inspector's input fields. With that knowledge, you can divide a number of ticks by, for example, the physics ticks per second. 5 ticks, 60 ticks per second, 5 / 60.0 (notice the float division) equals 0.0833333333, which is the corresponding time in seconds.
The engine's unit of time is often in seconds, so this is extremely consistent.
Fair points!
Thank you for your contributions, but I would recommend opening a proposal first to gauge interest in this.
I've aonly implemented this because of interest from discords and reddit. But yeah I guess a Proposal would have been better.
Implementation aside, personally, this feature is superfluous. Especially nowadays, a strict dependency on framerate is generally undesirable and prone to very, very nasty bugs.
Yes and no - sure it not needed for 99% of the users but you very often see people start their programming journey by cloning games and a lot of games used to be frame rate bound (see doom). So I still think its useful to have given the low maintenance this needs once implemented - especially because its completely optional and not the default.
If you want to gather seconds from a count in ticks, keep in mind you can evaluate expressions inside of the Inspector's input fields. With that knowledge, you can divide a number of ticks by, for example, the physics ticks per second. 5 ticks, 60 ticks per second,
5 / 60.0(notice thefloatdivision) equals0.0833333333, which is the corresponding time in seconds. The engine's unit of time is often in seconds, so this is extremely consistent.
On a second note - I had this problem multiple times before; for some reason github workflows/tests pass on my fork but then fail on PR. Is there a reason for that? (Also pre commit didn't pick up those issues as well for some reason)
On a second note - I had this problem multiple times before; for some reason github workflows/tests pass on my fork but then fail on PR. Is there a reason for that?
It's a fault of the checking system. Sometimes the servers fail for reasons entirely out of your control. Force-pushing (basically trying again) tends to fix it.
you very often see people start their programming journey by cloning games and a lot of games used to be frame rate bound (see doom).
I do sympathise. I was one of them, and I still am. Some parts of my code are framerate-dependent because it is sometimes faster to write and less bloated. But I still don't think it should be encouraged by implementing this feature on an easily accessible node, for the reasons I stated above. Code in a script tends to suffice.
In the era of variable refresh rates and arbitrary framerate limits, I'd say this encourages bad practices. I only know one game genre where durations are still expressed in frames (fighting games), and even then, I'd say it's legacy baggage at this point :slightly_smiling_face:
Either way, this should be discussed in a proposal.
On a second note - I had this problem multiple times before; for some reason github workflows/tests pass on my fork but then fail on PR. Is there a reason for that?
It's a fault of the checking system. Sometimes the servers fail for reasons entirely out of your control. Force-pushing (basically trying again) tends to fix it.
you very often see people start their programming journey by cloning games and a lot of games used to be frame rate bound (see doom).
I do sympathise. I was one of them, and I still am. Some parts of my code are framerate-dependent because it is sometimes faster to write and less bloated. But I still don't think it should be encouraged by implementing this feature on an easily accessible node, for the reasons I stated above. Code in a script tends to suffice.
I see thanks. Will open a Proposal