Accurate FPS measurement
Author
A simple question : how can I measure correctly FPS for the display ?
Today, I use a simple counter. This counter is incremented by 1 each time entering the Render() loop. Every 1 second (I use a multimedia timer), I display the value of this counter and reset it. Is there a more accurate way to calculate FPS ?
Thanks for the answers.
Amarhys
That should be fine. The only potential problem is in accurately timing one second - depending on the granularity and frame rate you could end up recording the frame rate every 1.05 or 1.1 seconds (for example), which is technically wrong. However, the difference would probably be so small as to not really be a problem.
If absolute precision is important, then go get friendly with the windows timing features and their (many) problems [grin]
Jack
If absolute precision is important, then go get friendly with the windows timing features and their (many) problems [grin]
Jack
That's pretty much as accurate as you can be.
You could interpolate/average the framerate over more than only the last second to get a more stable value. You can disable vsync so the framerate is clamped to 60 or so fps. And you can use the QueryPerformanceCounter (if available on the system) for additional precision.
What do you need the framerate for? If it's just for debugging purposes, I wouldn't worry too much about accuracy. If it for physics simulation, you'd best use some integrators to achieve a stable simulation.
You could interpolate/average the framerate over more than only the last second to get a more stable value. You can disable vsync so the framerate is clamped to 60 or so fps. And you can use the QueryPerformanceCounter (if available on the system) for additional precision.
What do you need the framerate for? If it's just for debugging purposes, I wouldn't worry too much about accuracy. If it for physics simulation, you'd best use some integrators to achieve a stable simulation.
Quote:Original post by WanMaster
And you can use the QueryPerformanceCounter (if available on the system) for additional precision.
Yea, I absolutely recommend this. It is a lot more accurate than the traditional WinAPI timers.
If you look at DXUT, it has a nice little Timer class that wraps QPC for you.
QPC should be good enough in 99% of cases, but it's worth noting that it's not perfect [smile]
IIRC, there was a multi-core bug in Windows recently where the cores would get out of sync (thus your threads could go nuts). Then there is the wonderful speedstep technologies that you often find on laptops that can appear to slow time down [lol]
This mini-article is well worth reading.
Jack
IIRC, there was a multi-core bug in Windows recently where the cores would get out of sync (thus your threads could go nuts). Then there is the wonderful speedstep technologies that you often find on laptops that can appear to slow time down [lol]
This mini-article is well worth reading.
Jack
Author
Hi,
Thanks to all of you for your answers.
I want to calculate FPS for debug purpose. I am working on a 2D game engine and I would like to know how the way I manipulate textures, vertex buffers, etc... impact the display. 90% accuracy is enough for me.
Amarhys
Thanks to all of you for your answers.
I want to calculate FPS for debug purpose. I am working on a 2D game engine and I would like to know how the way I manipulate textures, vertex buffers, etc... impact the display. 90% accuracy is enough for me.
Amarhys
Quote:Original post by WanMaster
That's pretty much as accurate as you can be.
You could interpolate/average the framerate over more than only the last second to get a more stable value. You can disable vsync so the framerate is clamped to 60 or so fps. And you can use the QueryPerformanceCounter (if available on the system) for additional precision.
What do you need the framerate for? If it's just for debugging purposes, I wouldn't worry too much about accuracy. If it for physics simulation, you'd best use some integrators to achieve a stable simulation.
integrators? never heard of that approach.
Quote:Original post by amarhysI am working on a 2D game engine and I would like to know how the way I manipulate textures, vertex buffers, etc... impact the display. 90% accuracy is enough for me.
When it comes down to performance profiling you want all the accuracy and precision you can get. I'd say you'd want to use QPC/QPF and output frame time rather than frame rate in this case. The last thing you want to be doing is making optimization decisions based on flawed/incorrect data [wink]
hth
Jack
Quote:Original post by Alpha_ProgDesQuote:Original post by WanMaster
That's pretty much as accurate as you can be.
You could interpolate/average the framerate over more than only the last second to get a more stable value. You can disable vsync so the framerate is clamped to 60 or so fps. And you can use the QueryPerformanceCounter (if available on the system) for additional precision.
What do you need the framerate for? If it's just for debugging purposes, I wouldn't worry too much about accuracy. If it for physics simulation, you'd best use some integrators to achieve a stable simulation.
integrators? never heard of that approach.
What I meant was, that if he needs a very accurate framerate because some physics simulation goes out of control, he should fix that using some verlet integration method for example. I didn't mean he should integrate the frame rate itself. [smile]
I didn't know the reason why he needed more accuracy, so I took some wild guesses.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
