vector<float> frameTimes;
GameLoop()
{
// elapsedTime is calculated using QueryPerformanceCounter
// add the current elapsedTime to the vector
frameTimes.insert(frameTimes.begin(), elapsedTime);
if (frameTimes.size() > 50)
frameTimes.pop_back();
// FPS
float totalTime = 0.0f;
for (unsigned int i=0; i<frameTimes.size(); ++i)
totalTime += frameTimes[i];
float FPS = frameTimes.size()/totalTime;
}
Dynamically, but smoothly, calculating FPS
I'm trying to calculate the FPS of my game but the calculated FPS fluctuates and can be difficult to read. I currently am doing this:
Basically, this code will constantly have a list of how much time elapsed during the past 50 frames and will calculate the FPS accordingly. Can anyone think of a way to do this, yet maintain or more "stable" FPS that is easier to read?
Brett
[edited by - Bretttido on October 10, 2002 2:27:19 AM]
The way I have implemented to FPS is that every time i update my gamestate, i use the time elapsed since the last frame as a parameter. I add together the elapsed times, and keep track of the # of frames until the time elapsed becomes greater than one second, and then calculate the frames per second.
Or in algorithm form:
update(elapsedTime)
{
ttlElapsedTime += elapsedTime;
frames++;
if (ttlElapsedTime > 1.0f)
{
fps = frames / ttlElapsedTime;
ttlElapsedTime = 0;
frames = 0;
}
//rest of game logic - I ain''t gonna give you that
}
This updates the counter every second, but does not keep previous seconds frame rates as a history.
Hope it helps...
Or in algorithm form:
update(elapsedTime)
{
ttlElapsedTime += elapsedTime;
frames++;
if (ttlElapsedTime > 1.0f)
{
fps = frames / ttlElapsedTime;
ttlElapsedTime = 0;
frames = 0;
}
//rest of game logic - I ain''t gonna give you that
}
This updates the counter every second, but does not keep previous seconds frame rates as a history.
Hope it helps...
One way would be to count the actual number of frames rendered, and update the FPS counter when the time exceeds one second, then subtract by a second and begin the count again.
If you want a more stable FPS try increasing your History size to a much larger number... since your only keeping the past 50 frames if your game were running at 60fps you would only be keeping one second of history... if your game is much faster than that or calculation times vary alot then this number will fluctuate more frequently... otherwise you need to get an average and only update it every second or so like mentioned above...
-Ximmer
-Ximmer
Thanks for the input guys.
TheHermit, I''ll try your way out and see how well it fits my needs. Hopefully that''ll do the trick.
Ximmer, I''ve increased my history size to rather large values... 500 for instance, and that seems to make the FPS easier to read. However, it also causes it to converge to the correct FPS very slowly (and if for some reason the game ever runs at say... 5 FPS), it would take 100 seconds to converge to the correct FPS. This seems to be the fundamental problem with the way I''m try to calculate FPS: its updating is based how many frames have passed, not on time. I''m trying to think of a way to incorporate both frames passed and time passed without going overboard, hehe.
Brett
TheHermit, I''ll try your way out and see how well it fits my needs. Hopefully that''ll do the trick.
Ximmer, I''ve increased my history size to rather large values... 500 for instance, and that seems to make the FPS easier to read. However, it also causes it to converge to the correct FPS very slowly (and if for some reason the game ever runs at say... 5 FPS), it would take 100 seconds to converge to the correct FPS. This seems to be the fundamental problem with the way I''m try to calculate FPS: its updating is based how many frames have passed, not on time. I''m trying to think of a way to incorporate both frames passed and time passed without going overboard, hehe.
Brett
Yeah, I had the same problem. The "update every second" and "huge history buffer" methods don''t tell you much about the real framerate, especially if it changes a lot / quickly.
Here''s what I did:
-calculate elapsed time since last frame (= 1/fps) with a high resolution timer
-drop single values that are "way too low" (in my app, these were probably caused by page faults)
-smooth a bit with a small history buffer
-maintain a ''trend'' over the last 3 frames (getting higher, lower, or neither)
-display new average fps if a) the difference exceeds a tolerance b) it''s consistent with the trend
This worked amazingly well - large changes are displayed quickly, and it''s always readable.
HTH
Jan
Here''s what I did:
-calculate elapsed time since last frame (= 1/fps) with a high resolution timer
-drop single values that are "way too low" (in my app, these were probably caused by page faults)
-smooth a bit with a small history buffer
-maintain a ''trend'' over the last 3 frames (getting higher, lower, or neither)
-display new average fps if a) the difference exceeds a tolerance b) it''s consistent with the trend
This worked amazingly well - large changes are displayed quickly, and it''s always readable.
HTH
Jan
I presonally prefer the "Count number of frames, show after 1 second" method. The reason is, if you calculate time difference, and FPS too frequently, no matter how "hi res" your timer is, it may start to show incorrect values especially when the game is running really fast.
I havent read all the posts, but this is how I''d do it:
FPS += 0.1f / FrameTime; // FrameTime is time since last frame
FPS /= 1.1f;
assuming that FPS is 1.0f / Frametime, you add a tenth of that to FPS, and divide it by 1.1. Other numbers might work even better if your FPS is very high.
You just kind of make the FPS a weighed average of the "current" FPS and the "previous" FPS.
FPS += 0.1f / FrameTime; // FrameTime is time since last frame
FPS /= 1.1f;
assuming that FPS is 1.0f / Frametime, you add a tenth of that to FPS, and divide it by 1.1. Other numbers might work even better if your FPS is very high.
You just kind of make the FPS a weighed average of the "current" FPS and the "previous" FPS.
quote:Original post by Poya
I presonally prefer the "Count number of frames, show after 1 second" method. The reason is, if you calculate time difference, and FPS too frequently, no matter how "hi res" your timer is, it may start to show incorrect values especially when the game is running really fast.
Agreed, an approach like:
Increment FrameCountif TimeElapsed>1 seconds then Show "FPS: " FrameCount/TimeElapsed Reset TimeElapsed Reset FrameCount
will give good, precise results. If you want to normalize the framerate you could employ a circular array and average the last X seconds together:
History[Position]=NewestFPSPosition=(Position+1) mod HistorySizeReportedFPS=(History[0]+History[1]+History[2]....)/HistorySize
[edited by - michalson on October 10, 2002 12:18:05 PM]
quote:
-calculate elapsed time since last frame (= 1/fps) with a high resolution timer
-drop single values that are "way too low" (in my app, these were probably caused by page faults)
-smooth a bit with a small history buffer
-maintain a ''trend'' over the last 3 frames (getting higher, lower, or neither)
-display new average fps if a) the difference exceeds a tolerance b) it''s consistent with the trend
Wow, that worked amazingly well Jan. I think you just solved my problem. Though I''ve implemented it without dropping values that are "way too low", but that''s just because I very rarely have page faults, so its not an issue.
Before that, I had implemented the way up updating every second.. or every half second. And while that way is readable, it just doesn''t have that... "smooth" feel to it if you know what I mean.
Brett
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement