Locking target FPS at 90 Gives me 90 - 80 fps, and locking fps at 60 gives me 60 - 50 fps

I built my game for android with a locked fps at 90, which gives me 90 - 80 fps, and when I lock it at 60 the game gets 60 to 50 fps, this made me confused, shouldn’t locking the fps at 60 results in consistent 60 fps, if locking target fps at 90 gives me 90 to 80 and never even drops to 70?

I figured maybe the device gave me enough resources to reach the target fps, but I’m not sure that’s true. If that’s the case is there a way to demand more from the device?

My game looks better at consistent fps if anyone was wondering why lock the fps if I can get more. Any ideas or help is appreciated.

without information not sure how we are expected to help.

How are you “locking” your FPS? you havent said how? Are you turning on vsync? Are you setting Application.targetFrameRate?

Neither of these will “lock” the framerate but simply set a max cap and they both work differently.

Without seeing profiling outputs etc, its hard to tell what the issue is coupled with not knowing the method in use. How are you reading your FPS? Stats window in editor? Custom FPS display script? 3rd party overlay? etc

Context is king here on the forums so please be as detailed as you can and provide shots of all relevant telemetry if you are hoping to get some troubleshooting assistance :slight_smile:

I am setting a max cap using Application.targetFrameRate at the start of the game and I use a 3rd party overlay to read the FPS

This topic pops up here every couple months.
It is not possible to lock the framerate on a regular system. In the greater sense that is why real time computing requires very special software on bare metal - a typical OS makes it impossible.
Reason is your software can NOT predict:
1. how long it's own next tasks will take due to the extreme complexity
2. whether the OS will suspend your thread to let other threads work

The result is that one can provide an upper bound (because you just give up/idle your thread if you have computed too fast) but not a lower bound.

Unity made a blog post on the topic a few years back. Short version is Application.targetFrameRate is made to be efficient rather than exact. For exact rendering you have to look into manually controlling updates and renders.

Some sample code and links to a github repository are in the blog post if you want to see their approach.


Very insightful blog, thank you!
but I realized trying to lock the frame rate can be costly, and it won’t work for the wide range of devices I’m targeting. The best thing to do is, to have a lot of quality settings available for the players and let them finetune the game to their liking.

You shouldn’t target high frame rates on mobile anyway due to thermal throttling and power drain. Unless it’s absolutely key to your game, keep it at 30fps.

It depends on the game, but I absolutely disagree with the above statement.

In an era where 90 and 120hz phone displays are common, the whiplash when running a 30fps game is tremendous. Have the option for 30fps, but don’t default to it.


I suppose you render full resolution on those devices too? Just cause you can, doesn’t mean you should…

I actually do. We default to 80% of the full resolution depending on the device, but the options are there.

For our new game we’re attempting to pick a default resolution based on performance (we keep dropping it if it can’t get a smooth 60fps), but we start at native. New-ish mid range and above devices don’t really need to drop resolution.

1 Like

Have you seen these posts? I am targeting 90fps on modern phones and 60fps on older, and had to do this:

TLDR. Use the MainActivity.java modified to your game, and set your targetFrameRate at least 1 higher than what you want.

Also, for performance in general, it seems SetResolution to 80% is faster than the scaling from ScalableBufferManager to 80%. And it will also scale the UI down, which can be the main source of overdraw.

There are also issues with some android OS’s will auto-reduce to 60fps when not being touched for 5 seconds, but that’s another story.

1 Like