Best way to calculate framerate - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Best way to calculate framerate (/thread-3912.html)
Pages: 1 2
Best way to calculate framerate - ferum - Sep 5, 2006 07:06 AM
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.
What is the best way to do it?
Best way to calculate framerate - TomorrowPlusX - Sep 5, 2006 07:53 AM
This works pretty well for me, but I doubt it's the "best".
It's called from the function Application::loop() which is called continuously from a timer.
Best way to calculate framerate - ferum - Sep 5, 2006 10:26 AM
hmm... I don't know C++, What does "::" mean?
Best way to calculate framerate - aarku - Sep 5, 2006 10:35 AM
Read the comments there. That's the best way I've used. (No complaints!)
Best way to calculate framerate - akb825 - Sep 5, 2006 12:17 PM
If you're using C, I suggest using gettimeofday. Here's a little snippet of code that should work.
BTW, to answer your question about C++, :: is scope resolution, whether with a class or namespace.
Best way to calculate framerate - ferum - Sep 5, 2006 12:25 PM
Ok what's wrong with my port of that code to non-Unity-dependent C?
It keeps telling me the frame rate is either 1, less than 1, or infinity.
here's my port:
currentTime and FPS_lastFrameTime are in milliseconds, and FPSupdate is called at the end of my display function.
Best way to calculate framerate - akb825 - Sep 5, 2006 01:43 PM
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.
Best way to calculate framerate - PowerMacX - Sep 5, 2006 07:37 PM
Here is what I use:
In plain C, it would look something like this:
Best way to calculate framerate - aarku - Sep 6, 2006 10:51 AM
Best way to calculate framerate - AnotherJake - Sep 6, 2006 01:03 PM
Here's yet another way to do it in C which will update a string every half second for convenience:
Best way to calculate framerate - kelvin - Sep 6, 2006 04:03 PM
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.
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.
Best way to calculate framerate - kelvin - Sep 6, 2006 04:14 PM
TomorrowPlusX Wrote:This works pretty well for me, but I doubt it's the "best".
You've got a divide by zero error waiting to happen on fast machines.
Note: this goes for all the above implementations in this thread. (except mine of course)
Best way to calculate framerate - OneSadCookie - Sep 6, 2006 04:20 PM
It's not an error to do a floating-point divide by zero (you'll get infinity or -infinity, but that's not a major issue)
Best way to calculate framerate - Greywhind - Sep 6, 2006 06:12 PM
Here's how I do it using SDL (I think this is all of it... didn't check carefully...):
Keep a variable that is updated at the end of each frame called "startFrame" (at the end of each game loop, this code should be run:
If I missed something, please forgive me - I'm somewhat busy at the moment and didn't have much time to write this.
Best way to calculate framerate - PowerMacX - Sep 6, 2006 06:24 PM
kelvin Wrote:Not that I've done this before, but I just thought of a way to get live FPS with good accuracy...
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: