Best way to calculate framerate

My program is based in SDL with fixed-interval game update cycles (like this), and written in C. I was wondering how best to calculate the framerate.

The only way that I could think of would be to have an int FPS that was incremented after every call to my display function, then have an SDL timer that fired every second that printed the number and set it back to zero.

First off, if your times are in milliseconds, you should be subtracting timeLeft by (currentTime - FPS_lastFrameTime)/1000.0f, and you should be adding accum by 1000.0f/(currentTime - FPS_lastFrameTime). If your program is going over 1000 fps, you will get an infinite framerate at times, as well, since the difference is 0. (very possible if it's a simple program) Also, the problem with doing everything in milliseconds is it's usually too rough of an interval. (for example, if it takes 9 ms for a render, it's going at 111.111 fps, while if it takes 10 ms it's going at 100 fps) The advantage of using my method is it theoretically has 1000 times the precision since it has a resolution down to 1 microsecond, and everything is already done in seconds.

Not that I've done this before, but I just thought of a way to get live FPS with good accuracy...

Set up a sliding window calculation:
1) Set up a Queue of timestamps.
2) Every frame put a timestamp in the Queue.

To calculate your sliding window FPS:
Lets say your window is 3 seconds.
1) poll the Queue and discard timestamps until you reach a timestamp that is within the last 3 seconds.
2) divide the Queue count by 3.0
3) there's no step 3!

This method for calculating FPS will give you a live average of the last 3 seconds with higher accuracy than any other method. If you set your window to 1 second, you get an exact number of frames for the last second. The nice thing about the live average is that you can see your FPS for EVERY SINGLE FRAME. if you were so inclined, you could graph the result and get a non-chunky live view of your throughput.

Implementation details:
Fear not, I've also thought of a novel way to implement this sliding window. Use a ring buffer (will eliminate allocations) of doubles (ints might be slightly faster) for your Queue. This will be very very fast and keep FPS calculation to a minimum. Also, doing the poll dump is trivial and fast. Just traverse and compare. If you are calculating FPS every frame with a 1 second window, you'll on average do just 1 inequality check and 2 adds.

When you reach a Queue overflow, simply over-write the head of the Queue and move the head down the line. When you do this, you get a capped FPS (I'd say 1024 (you can wrap it with a bit manipulation) is a nice sized ring buffer to allocate) calculation.

When you think about it, saving memory to calculate FPS is really not beneficial at all. You're trying to calculate how fast you are going! Why slow down (even infinitesimally) for some useless approximate calculation? Nowadays 4KB for a sliding window is practically free. And the calculation... well, this implementation is about as cheap as you can get. (and it's live!)

[edit:] I just thought of something else: Since your Queue is sorted (in theory) you can traverse it like a binary tree. If you are using the ring buffer implementation with 1024 spaces, you'll never have to compare more than 11 entries!

[edit again:] Perhaps the best way to do the poll dump is to do an exponential search up, then an exponential search down. Since the index you're looking for is *most likely* near the head of the queue, you'll probably find it faster searching up than down.

kelvin Wrote:Not that I've done this before, but I just thought of a way to get live FPS with good accuracy...

Set up a sliding window calculation:
1) Set up a Queue of timestamps.
2) Every frame put a timestamp in the Queue.

To calculate your sliding window FPS:
Lets say your window is 3 seconds.
1) poll the Queue and discard timestamps until you reach a timestamp that is within the last 3 seconds.
2) divide the Queue count by 3.0
3) there's no step 3!

This method for calculating FPS will give you a live average of the last 3 seconds with higher accuracy than any other method. If you set your window to 1 second, you get an exact number of frames for the last second. The nice thing about the live average is that you can see your FPS for EVERY SINGLE FRAME. if you were so inclined, you could graph the result and get a non-chunky live view of your throughput.

Or... you could just use exponential smoothing (what I posted earlier) to get very similar results. Actually, not only is exponential smoothing a lot simpler to implement, it also suffers less lag so maybe not just "similar" but "better" results: