# How to calculate FPS and what factors affect FPS?

In this case, FPS means Frames Per Second and that means the number of frames that graphic hardware render in one second. I'm wondering what kind of stuffs could affect FPS?

So, for some tests I created a simple scene in Unity with some cubes and capsules and then create a empty game object and then add this c# code to it:

public class FPSReport : MonoBehaviour {

public double Fps;

void Update ()
{
Fps = 1.0 / Time.deltaTime;
}
}


I think it can tell me the FPS. When I played it it worked but it wasn't more than 30.

I was saw a lot of games that their fps was normally on 150. Is this fps rate ok?

If I add more objects, textures, animations , etc ... to my scene.

• What happen to my fps?
• Could it attain zero? and
• If it attain zero, what is the meaning of a zero FPS (the hardware stopped working?!)?

In general to calculate the FPS, you need the following:

• cn: counter of how many frames you've rendered
• time_start: the time since you've started counting
• time_now: the current time

To calculate the FPS, you simply evaluate this formula (all taken from this answer):

FPS = cn / (time_now - time_start)

One thing that often greatly influences the run-time and therefore the FPS is whether you are running a debug or release build. The debug builds are often slower by multiple order of magnitudes, since they contain a lot of additional information and checks that help with the debugging process while slowing the application down considerably.

Regarding your concrete FPS quantity: There is no way for us to tell whether that value is "ok" since it depends on so many factors that we don't know about, such as your system in general, the current resource usage by other processes / applications, etc.

Unity has a FPS limiter built in that ensures that the FPS do not cross a certain limit (and thus preserves computation power for other processes).

To disable it, put this somewhere in your script:

Application.targetFrameRate = -1

Additionally "vertical synchronization" (VSync) might be enabled which forces the GPU to only emit new frames as fast as the monitor can actually display them to the user (this basically locks the rendering frame rate to the monitor framerate). This sometimes can prevent "coil whines".

To check whether VSync is enabled in Unity go to:

Edit → Project Settings → Quality

The default quality profile is "Good", so expand "Good" and set "VSYNC Count" to "Don't Sync" (source).

In general: For the human eye you need at the bare minimum 20 FPS to fool the brain into thinking that it sees a fluid motion. Usually 30 frames is considered enough for a smooth game. Everything above is basically luxury (= unused computation power) that could be put to use to render the scene in higher fidelity (= select higher quality settings in the game's configuration = better textures, better shaders, higher long-range visibility/more objects rendered).

The more elements you add to the scene (be it objects, more or higher-resolution textures, additional animations, shader effects, etc.), the longer your scene will take to render and the lower the FPS will get.

Theoretically you could reach 0 FPS, if your application stops rendering all together either because the software decides to (some games check if the game window has lost its focus and then stop rendering to preserve the computer power for other processes) or if there is really no computation power given to your application at all because all other processes have a higher priority and use up all resources.

• The human eye does not have a shutter so it can see well above 30fps so it's not unused computing power, but it might be computing power that can be better used elsewhere. The question is if the improved fps significantly improves your game more than improving the quality of the image. See 30vs60.com and notice the difference.
– Seph
Jan 7 '15 at 11:14