The implementation is as simple as it can be : each frame, add current time to a queue, then dequeue elements older than 1 second. FPS is the number of items in the queue. In case of high precision timer, FPS is average of frame times in the queue. Because we remove elements older than 1 second, it's frame rate independent.
implementation is very fast : there is no division (at least for zero decimal FPS), modulo operation are implemented with masks and the loop will only iterate one time per call in average.
by default, it show zero decimal FPS. That one is very stable and responsive even with 35 Hz timer.
in case a higher precision timer is used (in the future), there is a flag HIGH_PRECISION_FPS that can be set. It calculate FPS with one decimal. The TIMER_RATE constant and ticcount variable should be updated accordingly.
Ideas for the future :
use 560 Hz timer implemented by @dougvj, when available
add two FPS modes in options menu : one with 35 Hz timer and one with faster timer created/destroyed on the fly. I think tasks module already support that. Or use a single high precision timer that is only created when FPS is on. 1000 Hz timer is clearly an overkill.
It's based on earlier discussion https://github.com/viti95/FastDoom/discussions/204
The implementation is as simple as it can be : each frame, add current time to a queue, then dequeue elements older than 1 second. FPS is the number of items in the queue. In case of high precision timer, FPS is average of frame times in the queue. Because we remove elements older than 1 second, it's frame rate independent.
HIGH_PRECISION_FPS
that can be set. It calculate FPS with one decimal. TheTIMER_RATE
constant andticcount
variable should be updated accordingly.Ideas for the future :