Question Forcing Unity to run at 60 fps

Hi,

For my game, I want Unity to run at a steady 60 fps. It's a deterministic pixel-perfect precision platformer, and for games like that, a locked framerate is pretty much required.

The way I currently handle it is this :

- If vsync is off, I rely on Application.targetFramerate, which seems to work well enough
- If vsync is enabled and the refreshrate is a multiple of 60 (more or less), I rely on QualitySettings.vSyncCount
- If vsync is enabled and the refreshrate is not a multiple of 60, I use a combination of thread.sleep and spinlocking to get as close to 60fps as I can.

The sleeping/spinlock is based on this article : https://blogs.unity3d.com/2019/06/03/precise-framerates-in-unity/
But I fixed a couple of issues with that where the game would behave strange when it's either ahead or behind schedule.

This all works well - except when it doesn't. It's rare, but for some people the game runs way too fast. My guess is that the OS or Unity don't always report the refreshrate correctly, possibly due to some weird driver settings. So my game is probably setting vSyncCount incorrectly and/or bypassing the spinlock mechanism. Of course I can't rule out that there's just a bug in my code, but that doesn't seem to be the case.

So how do other people handle this? I realize that for many games, the solution is to make the game run independently of the framerate or use FixedUpdate for gameplay - but I can't be the only person who wants gameplay and rendering the be in lockstep at 60fps.

Here's a good article on the subject (not specific to Unity though) : https://medium.com/@tglaiel/how-to-make-your-game-run-at-60fps-24c61210fe75

In this article, they describe a hack which measures the refresh rate for a couple of frames, which I guess I could do but it doesn't seem ideal. For one, I'd need to run this test every time the game regains focus (because driver settings may have changed), and that sounds fragile.

Any suggestions would be appreciated.

 

I can't answer why some players would be seeing strange framerates, but for any deterministic gameplay, you'd be better off relying on FixedUpdate as opposed to using Update and relying on having that exact framerate. Using FixedUpdate would solve your current problem (even if the target FPS gets unlocked, FixedUpdate will still run exactly the right number of times with exactly predictable deltaTime values), as well as if the user drops some frames (it'll run FixedUpdate more times in one visual frame until it catches up).

 

Thanks. I was considering this, but the problem I have with that is that Unity updates input in Update and not in FixedUpdate. So if at a certain refresh rate Update is called twice and FixedUpdate is called once, some inputs could get missed in the FixedUpdate.
I guess I can work around that, but it does seem kind of weird that I'd be updating gameplay outside of the rendering loop but rely on input that's being captured during the rendering loop.

 

It's a little more subtle than that: edge triggered input is only guaranteed in Update(), eg,

Input.GetKeyDown/Up()

or

Input.GetMouseButtonDown/Up();

, the detection of transition from one state to another.

Continuous stuff like all the Input Axis methods and just asking "is this key held down now?" (Input.GetKey()) are all perfectly valid in FixedUpdate().

For edge stuff you can read it in Update(), set a boolean, but be sure to "consume" that boolean by setting it false when you act on it in FixedUpdate(). That way you won't get two jumps just because two FixedUpdate()s get processed at the moment you pressed Jump in Update.

 

Thanks. I rely on GetKeyDown/Up a lot, I don't use input axis methods. Honestly, Unity should have an option to tie input to FixedUpdate instead of Update.

Setting some bools would work in most cases, but one edge case would be this - still assuming two updates for one fixed : let's say a user presses and releases a key really fast. One update gets the press, the next gets the release. Then by the time FixedUpdate gets called, it would think the key is both pressed and released, since my gameplay code would need to take both into account.

Obviously this might be rare, but my game is designed for speedrunners and I don't want a game that misses inputs when it's too fast.

So I'd probably need to delay the release until the next frame, and you can see that things start to get quite complex. And I'd have to tie it in with InControl which I use for controllers (which does support updating in FixedUpdate, but probably best to have keyboard and controller inputs consistent).

Edit : Sorry if I sound negative, I appreciate the suggestions! I'm just a little stuck on these issues

 

Sounds like you just need an input queue... capture the events in Update() and stick them in the queue, then pull them out in FixedUpdate() appropriately.

 

Since FixedUpdate runs before Update in any given frame, if you read the input in Update but then react to it in FixedUpdate, doesn't that imply that you are delaying your responses by one frame? (Well, by one frame compared to when the screen is drawn. Not compared to when the internal physics update occurs, so if the effect of user input is just to change what data is sent to the physics engine, then I guess this shouldn't matter...but if that's what your input is doing, why can't you just do it directly in Update anyway?)

One alternative might be to check in FixedUpdate whether the key is currently down, store that state in a variable, and check each time if the answer is different from the previous FixedUpdate. (This might not notice if a button is pressed & released so quickly that it happens entirely within a single frame, but that seems unlikely to happen, and I'm actually not sure that KeyDown/Up would notice that anyway.)

Another alternative might be to implement your own pseudo-FixedUpdate, called from inside Update but conditional on the actual amount of time elapsed since your last iteration.

 

Yeah, good point that it would cause reacting to input to be one frame late. That's unacceptable for my game.
Interesting suggestion about the pseudo-FixedUpdate. Might cause issues with built-in stuff like animations and particles though. Guess I could add components to them to manually advance them, will have to look into that.

But I guess the easiest way would be to detect frames that are too fast, and if that happens too frequently, disable vsync (or enable spinlocking). It's a bit hackish, but should do the trick.

I'm kind of bummed that Unity doesn't have a (somewhat) reliable way built in to force 60fps. I realize it can be complex to do that, but that's all the more reason for them to take care of it instead of the users. Browsers cap webgl to 60fps, most emulators have a framerate cap as well, so Unity should be able to do this.

 

I was able to get some data from a player :

His screen has a max refresh rate of 60.
Screen.currentResolution.refreshRate reports correctly as 60
QualitySettings.vSyncCount is set to 1 (logged it to make sure)

And yet somehow this results in Update being called at a rate of over 300 frames per second.

So it seems possible for Unity to fail at vSync'ing? That's the only explanation I can come up with.

Any suggestions?

 

Use Time.captureFramerate or Time.captureFrameDelta:

https://docs.unity3d.com/ScriptReference/Time-captureDeltaTime.html

It locks Unity's Time.deltaTime to whatever value you want, causing the game to slow down or speed up depending on the actual framerate the target system is running the ge at.

 

Vsync in the editor is now a separate setting and ignores QualitySettings, I think.

 

Thanks, but I already use that. This just causes deltaTime to always be the same value, but that doesn’t stop Update from being called too frequently when Unity is failing to vSync correctly.

Thanks, but I’m not talking about the editor.


For now as a quick fix I disabled vsync by default so players at least don’t end up in high speed mode when they launch the game.

 

I really have to thank you for not only going through the trouble of finding a solution, but documenting it here. Like you I have been totally vexxed by this. Many years (uh... don't ask just how many) into the development of my game, I basically made it so I can swap out between a framerate independent/dependent setup. I did this so I can continue developing under the assumption I can eventually find a scenario where I can ship as FPS dependent that can guarantee 60FPS. Well, I'm getting closer to shipping but I still can't find a satisfying solution to this and it's driving me mad!

I'll try to add to this with some experiences of my own and hope maybe somebody, somewhere, can shed some light on an actual solution.

First, like you I need my game to run at 60FPS for a host of technical reasons. To put it simply, it has highly sensitive timing windows for things like weapons, combos and other stuff that totally break under a framerate independent setup. Thankfully, and unlike your situation, I don't think anyone will be speedrunning my game. So at least I don't have to deal with that nightmare, but it's a nightmare no less!

I also want to stress to people who are relatively new to gaming that what we are going for is nothing more than "classic" gaming. 99.99% of all the games ever made before the year 2000 were like this, and people still play these games competitively, and they get rereleased on modern systems all the time so it is demonstrably possible and common enough to be a very real problem!

I want to stress this because so many don't even understand how it can even be such a problem, but it really does wipe out huge genre's of possible games from being made (and in my opinion, hugely important ones), that should otherwise work just fine if fixed very simply by Unity! Anyways, here are some of my findings:

Obviously the real issue is on PC, where the user settings (monitor refresh, GPU settings) are totally unpredictable. Ideally, everyone just plays with Vsync off, and everything is fine. However, Vsync can be set in the GPU settings and that's where the "fun" and guessing games really start.

Let's say a user has a 120hz monitor, I can make a little script something like below to check it and divide in half. Of course for refresh rates that don't divide evenly into 60fps I'll have to put in some conditionals to check for that. It won't be great because it won't render 60fps in these instances (Eg: 144hz would render at either 48fps or 72fps depending on the vsync integer denominator)

But it's a start.

Code (CSharp):

1.         float avgFPS;
2.         void estimateFPSConstant()
3.         {
4.             float refine = 0.015f;
5.             avgFPS += (Time.unscaledDeltaTime - avgFPS) * refine;
6.         }
7.  
8.         void setVSync()
9.         {
10.             float targetFPS = 60;
11.  
12.             float vSync = (1 / avgFPS) / targetFPS;
13.  
14.             Application.targetFrameRate = (int)targetFPS;
15.             QualitySettings.vSyncCount = (int)vSync;
16.         }
17.  

Now, this is assuming vsync is turned on (IE: not set to default, which is zero) in the Unity settings, which you can allow the user to set in an in-game menu. But! This (already marginally acceptable) way of doing things is only respected if the GPU setting on the user end is set to "Use Application Settings."

If the user instead has it set in the GPU to "Vsync: On" then... guess what? That's right. It overrides my careful established Unity settings! So in this case of a 120hz monitor, I would have correctly established an effective 60FPS result by having Vsync=2 (120/2 = 60); But if the GPU overrides this it will simply make it effectively Vsync=1, meaning the game will run 120hz (120/1 = 120)... twice as fast as I would want it even though I've accounted for this scenario correctly!

I haven't even gotten into the spinlocking crazyness that was documented in the op. There's also talk of rolling my own update loop in coroutines, but I will in some cases have thousands of concurrent objects to manage in their own update loops, so... no.

I can only hope I don't have to do any of that. In the end, I am fairly sure I will just have to deal with a lot of anger/confusion/support requests that simply have to inform users how it has to be set up on their end, with a manual disabling of vsync, or changing it "Application controlled" on their end. Which sucks for me, but also for the users when the fix shouldn't be this difficult. I am honestly quite scared given how much work I've put in. It's literally the sum total of my life's work here, hinging on what appears to be an oversight of a simple feature that should be expected.

I wish it was this simple! As other's have noted, managing the input mismatch and potential for lag is an immediate problem. In my game I have so many possible inputs to keep track of that determine everything from spells to combos to... it's a lot... and it all has to be frame perfect, so this is a non-starter.

However, worse than that, FixedUpdate does weird stuff if the engine can't keep up. You can get rubber-banding, time-warping, choppyness and so on.

EDIT: Just to abuse... I mean amuse, myself I tried putting some of my more taxing logic in FixedUpdate. In Update I can get about 2000 instances on a potato PC before FPS dips below expected. In FixedUpdate I get to about 700 before it starts dipping and by about 1000 instances FPS rapidly decends to 3FPS, and a blackhole forms and swallows up my entire game. Which is interesting because the fixed timestep is less frequent (50FPS). Fun!

All the OP and I are going for is the dead-simple old school result of just slowing down the game execution if a system can't keep up. That way everything is still deterministic, and though the end-user will want to fix this as a problem on their end(by, say, upgrading their potato PC), it is a much more playable result especially if there are occasional frame spikes and a minor slowdown occurs. At any rate, using FixedUpdate in this way is an unequivocal hack considering FixedUpdate is meant for calculating physics. And basing the integrity of a totally predictable system on hack is a headache at best and asking for an aneurysm at worst.


I am ever open (desperate) for any helpful suggestions!

 

Yeah, FixedUpdate should only be used for physics.

It is an interesting topic here. I tend to believe by "old school" you mean really oldschool from times when games were entirely single threaded and pretty much built like for a real time capable OS, right?
Times do have changed. Albeit I do have to wonder why would spells etc. need to be frame perfect. Are you sure players would notice? We devs tend to be sensitive to entirely different things than the players are!

Btw. Instead of guessing the framerate and whether the settings have been applied as expected, why not measure them with the delta time method you showed? So you could adjust if the player manipulates the settings externally.

But isn't this exactly what's happening if you never use Time.deltaTime, rely solely on Update() (and not FixedUpdate()) and limit the max frame rate to 60?
Only exception being sound-samples playback (which you surely do not wanna delay) and physics.
Physics you can take full control over with this:
https://docs.unity3d.com/ScriptReference/Physics.Simulate.html

EDIT: Particles are likely working with the delta timer too, but there is also a Simulate() method for them! https://docs.unity3d.com/ScriptReference/ParticleSystem.Simulate.html

 

No. I grew up and learned programming on a Commodore 64 then a 386 w/ MS-DOS. Some games (almost entirely shovelware) used this approach but starting in the early 90s most games didn't rely on the game running at a fixed cycle. You could easily tell which ones did too because they never ran at the correct speed.

Agreed. Centralizing it is a better choice if you need to have everything synchronized on a fixed timing cycle. You will need to catch and store input data between sync states but that's trivial to implement.

Spoiler: Update Manager

Code (CSharp):

1. using UnityEngine;
2. using System;
3.  
4. public class UpdateManager : MonoBehaviour
5. {
6.     public static UpdateManager Instance { get; private set; }
7.  
8.     public float cycleTime = 1f / 60f;
9.  
10.     private float timeSinceLastUpdate;
11.  
12.     public event Action OnUpdate;
13.  
14.     private void Awake()
15.     {
16.         if (Instance == null)
17.         {
18.             Instance = this;
19.             DontDestroyOnLoad(gameObject);
20.         }
21.         else
22.         {
23.             Destroy(gameObject);
24.         }
25.     }
26.  
27.     private void Update()
28.     {
29.         timeSinceLastUpdate += Time.deltaTime;
30.  
31.         if (timeSinceLastUpdate >= cycleTime)
32.         {
33.             OnUpdate?.Invoke();
34.             timeSinceLastUpdate -= cycleTime;
35.         }
36.     }
37. }

Spoiler: Example

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Foo : MonoBehaviour
4. {
5.     private void Start()
6.     {
7.         UpdateManager.Instance.OnUpdate += OnUpdate;
8.     }
9.  
10.     private void OnUpdate()
11.     {
12.  
13.     }
14.  
15.     private void OnDestroy()
16.     {
17.         UpdateManager.Instance.OnUpdate -= OnUpdate;
18.     }
19. }

 

Except... they kind of haven't! If you're developing anything resembling a deterministic game where combos timings are needed, exact gaps between projectiles, rollbacks... etc, etc. Then you need the engine to run deterministically. I say "oldschool" because this frame behaviour was just "gaming" for a major chunk of history.

Today, it's a large sub-section that runs the gamut from fighting games, beat-em-ups, remakes and ports, shmups, rhythm and music... to totally new game styles. My problem isn't that I'm trying to get Unity to do something odd or simply outdated. My problem is I'm trying to get it to do something firmly expected for anyone trying to make one of these very broad game types.

Note: you asked about spell timings. Again, this is just a part of my combo system. I have a lot of tight timings, race conditions and input polling combinations that require frame perfect accuracy. That's not just me being a stickler, it's just how these kinds of games work.

Not sure what you mean. I don't really have to guess anything. The problem occurs when vsync is enabled in the GPU, which I simply don't have access to (that's what I meant by "guessing" though, I'm not even attempting a guess because I can't track it!). What I meant to say is I can't do anything about user changes to vsync because it will override my settings. Actually it can be worse, where in windowed mode my Vsync=2 "fix" works fine and caps to 60FPS, but in fullscreen it gets overwritten to Vsync=0 and runs at 120FPS. There are a lot of possible combinations to track and in the end I don't seem to have a way to do anything about it in at least a handfull of situations like this.

 

We're kind of talking about the same thing but in parallel universes lol. Sure, in the PC world I'm sure you're right. But in arcade and consoles it was totally different. When Street Fighter couldn't keep up to demands, it slowed down. When too many bullets were on screen in a shmup, you'd get massive slowdown. In both cases these actually became important mechanics, and not just side effects and glitches.

The reason most players didn't notice this is because the games often didn't tax the underlying system. Yes, in the case of arcade/console it was a closed system meant to run at a steady rate, that is nothing like PC. But these games eventually got ported to PC and emulation and were capped to 60FPS just fine, and slowed down more or less like they did on their console/arcade ports.

I do understand a lot of gamers simply don't know, play, or realize these genres of technical gameplay. And I think the op has a great example of speedrunning that embodies just how tightly controlled these timings are expected because that's just how determinstic these oldschool games were. I'd argue speedrunning wouldn't even have become a thing if an entire era of games didn't have this property of deterministic gameplay from the getgo.

I'll look at your suggestion which sounds like the coroutine/custom update loop idea but in my experience anything that seems deceptively simple is... deceiving lol.

 

Emulation of old school arcade machines is keeping the game at a constant speed but it's not using the method that was discussed in this thread (ie Application.targetFrameRate). I've taken the time to analyze MAME for the purposes of running an old game within Unity so here's the basic overview:

1. MAME determines the number of cycles that a hardware device is allowed to execute (eg the Z80 for Karate Champ ran at 2.5 MHz).
2. MAME executes instructions for the platform subtracting the cycle count of each instruction from that until it runs out of available cycles.
3. After a period of time has passed MAME adds more cycles to the total cycle count.

My update manager example is essentially the same idea but with the time period directly stopping execution rather than cycle counting.

 

That is very interesting. Yes your suggestion seems promising based on that. And my inputs are being managed and stored separately already so theoretically that shouldn't be a problem.

I guess in the hypothetical scenario of running your internal loop at an effective 60FPS, and the monitor refreshing at 144FPS, there should be an added fractional lag when the refresh loop hasn't yet updated with the current frame information, which can happen right after the refresh. I haven't run the numbers, but let's say it's about a ~2ms average.

But then, if your monitor is set to 60FPS, but actually refreshes at a slightly faster rate than the internal update loop (say ~61FPS), then you can effectively be adding a whole frame of lag because the refresh tends to happen just before the next internal update. So it's basically always about a frame behind.

Now, this scenario in practice is probably actually inverted (pure guess), where the engine runs a bit faster than the monitor. I'm guessing that because I've noticed when using TargetFrameRate = 60, the delta ends up reporting as an average of 61, and this tends to keep the frame information ready for the next refresh?

I'm kind of just thinking this out loud and trying to imagine the results. Hopefully this makes sense.

 

See now you're getting into a realm where in old school games your games were designed for dedicated hardware (you know the exact performance of it), as well as dedicated and/or standardized display devices.

The Sega Genesis in the NTSC market was designed to run on an NTSC display which has a fixed standard refresh rate.

The reason the PC market migrated away from this is because the PC market doesn't have these dedicated hardware nor standardized display devices. This "dead-simple" approach doesn't work so smoothly since the selected platform is no longer "dead-simple".

Of course you could poll the refresh rate and adjust your timings based on that. But of course, while the game will follow your rules on a per user basis... every individuals device will behave differently from one another.

But that's only if you're turning on vsync or any other refresh rate sync in an attempt to clock to that frame rate. Don't do that. Just target your experected framrate (60?) and if the user has a 61hz or a 75hz or whatever display all that will happen is they will get screen tearing. (You can even vscync if and only if they have a display that is a multiple of your target framerate)

And well... that's their problem!

I like old school games... I'm an old man who still has all my consoles from my Colecovision up to my Dreamcast I permanent markered blue. And when I want to pull off some frame perfect gaming I pull out my NTSC CRT to have 0 input lag, and perfect refresh rate.

If I purchased a game with the expectation that it is deterministic by 60hz framerate and then clock it on my 75hz ultra wide screen monitor. I'm not going to be surprised that it doesn't look 100% perfect... I am not going to think it's the developers fault they couldn't account for EVERY display option out there. And I'll maybe even clock in my monitor to the more appropriate refresh rate (it can do 60).

...

With that said, I just don't really even expect it on my PC.

I'm on an LCD display, the latency of my display already screws with me. I don't know your target demographic... but possibly it's the people even more hardcore than me. But there are certain games from the past I just won't play on LCD because well... there's literally nothing in the world a game developer could do to perfectly account for the very non-deterministic fact that my monitor just has lag. It just does. And like I said... if I'm playing one of those games where it truly matters to me, I just don't play it on my PC.

Of course this means really I just don't play any modern versions of these sorts of games because who is developing modern games for modern hardware but to a fixed display standard (except some hardcore indie homebrew stuff... which I dabble in occasionally. But it's still old hardware). So I sort of am just admitting I don't play modern games that way. Which is true... it's why the Dreamcast is literally the last console I own (well that's a fib, I technically have an xbox, xbox360, and ps2... but I never play those).

Today when I'm playing fast paced games where this level of frame perfection is important, I play under new expectations. The entire way I game is different. When I know I need to pull off a move I'm not expecting N frames to pass, I'm expecting N time to pass. Especially since like back in the day... I could frame count by the animation frames of a sprite on screen. Today everything is tweened/lerped... I have no idea how many frames have passed based on animations! And I don't expect the game to let me care about that and instead uses time delays rather than frame delays to allow my input. Because they better! Else the game is literally unplayable since everything from my USB gamepad, my usb KBM, and my DisplayPort LCD panel all have nondeterministic latency that would make that frame perfection all but impossible... unless... I don't know... maybe there's some super dedicated people out there more hardcore than myself. But man... that's a niche market!!!

 

Only on systems that are limited to just VSync. On systems that support FreeSync or G-Sync (support requires a compatible monitor and compatible graphics card) screen tearing shouldn't happen unless you drop to a certain threshold which is typically around 48Hz. Most people on high refresh systems have at least FreeSync.

It's thanks to that threshold that you shouldn't actually use QualitySettings.vSyncCount unless you know that the target device won't have FreeSync or G-Sync as the reduction in frame rate can cause these two technologies to stop functioning.

 

Based on what you've said, you'd be my ideal user. Now, hardcore and/or knowledgeable is the ideal, but the reality is most won't fall into any of these categories. They would probably just be average gamer who thinks the game looks interesting and buy it without much prior experience.

But I also want to respect that user not just for the numbers they represent, but their market expectations. If you take these sorts of games and look at how they run on Steam for example (and there are plenty of examples). It's always exactly how you'd expect. No jankyness. No "you should know better." It just works.

The reply above yours talks about how MAME handled this, and I think he's right. And it probably is how a lot of the other games like this on Steam end up solving the problem as well (or something similar).

I'm right with you, man, but it's scary knowing how mob mentality can just review bomb my game into a lower standing because of something as basic as frame cycles, and ultimately I need to account for that in some way. I really tried to make it work FPS independent (even though that is a highly unusual approach for these types of games), but it breaks so much of precision that is totally necessary.

Combos become laughably easy/near impossible, exact gaps to make death defying escapes from become trivial/hellish. It's just so ridiculous I even tried! But I hear you and I'll have to weigh my options, considering there probably won't be a catch-all fix. I might have to enable a variety of possible options in effort to help the end user, and hopefully avoid it just causing more anger and confusion of the bewildering options.

 

When I started development, Vsync was the standard and these technologies that abolish tearing weren't even around. It is some comfort that the more lazy I get, the more my problem becomes an edge case.

I guess what I'm living in fear of is actually just clueless gamers. I know a few of them. They are legion. Nice people, but these are the people who will slap on Vsync without thinking about consequences. And in fairness to them, the consequence is usually just added unnecessary lag and not a game running at 2x speed.

 

Note, I'm talking in the context of that post.

You responded to that post having a concern about if their refresh rate is 61 or what not.

Don't worry about that.

At worst they get screen tearing if they're off from your target framerate (60?). And, while I was rather vague with it as ryiah didn't pick up it's what I was referring to, in most scenarios you got either vsync or other refresh rate syncing technology (g-sync, free-sync) that'll take care of it to even avoid the screen tearing.

Just target a framerate, and update on your own loop, and you're good.