Can someone give me a detailed explanation about frame rate and fps concepts?
-
7\$\begingroup\$ In this context "frame rate" and "fps" are synonymous. However, you might also see the term "fps" in relation to the genre of the game - First Person Shooter. \$\endgroup\$– ChrisFCommented Sep 7, 2011 at 15:04
-
\$\begingroup\$ And some recent related news: techreport.com/articles.x/21516 \$\endgroup\$– HouseCommented Sep 9, 2011 at 16:43
3 Answers
"Frame rate" and "FPS" (frames per second) are usually the same thing. A "frame" is usually a single image in the series of images presented to your screen rapidly so as to give the illusion of motion in your game, and so the terms generally refer to how many of those images your game can simulate and produce within one second.
FPS is often used as a crude measurement of performance, but it's important to remember that it's a non-linear measurement: the difference between 30 and 60 FPS is much larger than 60 and 90 FPS.
Occasionally you will see the term applied in a context where "frame" doesn't refer directly to a unit of graphics/simulation processing overall, but to something narrower in scope. The idea is the same, though: how many of these steps does the program produce within one second.
-
3\$\begingroup\$ One advantage to achieving and maintaining a FPS higher than the eye can reasonably consume is that is protects you from the occasional downward spike in FPS dropping you to a point where visual artifacts could be detected. The human eye's flicker fusion point tends to be around 60 FPS, in any case. \$\endgroup\$– user1430Commented Sep 7, 2011 at 15:14
-
1\$\begingroup\$ @bane: It's true that the eye stops detecting flicker sometime between 50 and 75Hz, but the human eye can see far more than that in "pictures per second". US military research has shown pilots can identify planes better-than-chance having only seen them for 1/220th of a second. Still, the limiter in any practical environment is going to be your display technology - usually 60Hz. \$\endgroup\$– user744Commented Sep 7, 2011 at 15:59
-
1\$\begingroup\$ @ashes: Trivially, it's a y = 1/x curve. \$\endgroup\$– user744Commented Sep 7, 2011 at 16:00
-
3\$\begingroup\$ @bane: ms/frame is the first measurement you should be looking at for optimization purposes. This is the reciprocal of frames/second; you should not be looking at frames/second for optimization purposes unless you remember that it's really got this non-linear relationship to how good your optimizations are. Josh's link goes into great detail. \$\endgroup\$– user744Commented Sep 7, 2011 at 17:57
-
1\$\begingroup\$ I'm nitpicking here, but framerate and fps are not "the same thing". Literally, fps is one unit for measurement of framerate. Just as meters is one unit for measurement of length. \$\endgroup\$ Commented Oct 18, 2012 at 11:21
FPS = frames per second. A frame is basically your screen with something drawn on it. 60FPS means that something draws on your screen 60 times in one second. Because our eyes (or should I say the image processing cortex in the brain) is limited, if you draw something on very fast and move it each time - it will seem like it moves to our brain. That's how cartoons are done.
A "frame" is once around the game loop:
while( game_running ):
update()
draw()
update() involves things like
- Reading user input
- Computing enemy next moves
draw() is just drawing the current state of the game, as computed by update().
So here a "frame" is BOTH an update/draw cycle. FPS (frames per second) is a rough measure of how many times you can do your basic game loop per second, so by that its a rough measure of game performance.
Any number of things can be the bottle neck in your frame rate. It could be the CPU intensive AI code. It could be your collision detection routines before you added a reasonable space partitioning scheme. It could be the GPU itself.
If it contains an accurate physics solver, your physics solver will need to perform more than one iteration step per "frame" displayed (CarSim for example requires something like 1000 iterations every 1/60 second, simply to retain stability in the solution).
-
2\$\begingroup\$ -1 for necessarily coupling display refresh rates to game logic refresh rates. Your definition needs work. Please, inform yourself first, or you are potentially misinforming others. This is generally very bad for performance, and immediately rules out the use of any deterministic simulation characteristics, i.e. proper realtime physics calculations and multiplayer capabilities relying on same. These are the kind of fundamentals that are neither difficult to understand nor to implement. \$\endgroup\$– EngineerCommented Sep 7, 2011 at 21:02
-
\$\begingroup\$ Interestingly I was going to include something about this, but for the purposes of explaining what a frame is, I think this is adequate. I'll add something on the
VIRTUAL SECOND
later. \$\endgroup\$– boboboboCommented Sep 7, 2011 at 21:11 -
\$\begingroup\$ I shall gladly remove the negative once you have. \$\endgroup\$– EngineerCommented Sep 7, 2011 at 21:31
-
\$\begingroup\$ I don't agree completely with your answer. To use your own example, physics engines often run much faster like 1000 times per second. This is often phrased as 'the physics engine runs at 1000 fps'. I would define frames per second as: 'how many times all work is done by a given system per frame'. This keeps the definition wide enough to apply also to physics engines and other subsystems that run at their own pace in games. Hopefully it's not too vague. \$\endgroup\$– Roy T.Commented Sep 7, 2011 at 21:47
-
\$\begingroup\$ -1, Josh's third paragraph covers the same ground as your entire answer without getting bogged down in irrelevant details. \$\endgroup\$– user744Commented Sep 7, 2011 at 22:35