One thing I’ve noticed pretty consistently is that many Unity games feel extremely sluggish when they hit framerate drops, especially dipping under 30fps. I’m not talking about low budget indie games. I’m recently playing Pathfinder: Wrath of the Righteous, a very well made AA game. In more demanding views (particularly w/ heavy particle/fog) when performance drops, control gets very sluggish.
This is a common feature I’ve noticed in many Unity games. If CPU usage spikes especially, control really suffers, far more so than you generally see from Unreal or custom engine games.
I can’t be much more specific than “feels very bad at low FPS” - have others noticed this kind of thing? Not all Unity games that suffer, but an unusual number compared to most other engines. Again, I’m not talking about low budget indies, these are professionally made AA+ games.
Am I crazy or have others also noticed this?
Is this a code design decision that just tends to be more common in Unity games?
If a game is relying on Unity’s physics and FixedUpdate for gameplay, it will essentially perform “frame skipping” if the framerate becomes lower than the fixed time step. If the game also samples input in Update, you’ll get one additional frame of input lag since the input will only be used in the next FixedUpdate, after the current frame was rendered.
For example, if the game is running at 20fps and has a fixed time step of 0.02 (50 fixed updates per second), this is the approximate sequence of events:
Player sees frame 0
Player presses button
Game runs two fixed updates and physics updates
Game runs Update for frame 1, reads player input
Game draws frame 1
Player sees frame 1, but game didn’t react to input yet
Game runs three fixed updates and physics updates using the player input read in frame 1
Game runs Update for frame 2, reads player input
Game draws frame 2
Player sees frame 2, finally seeing the game react to their input.
In this example the game will only display the result of the player actions 100 milliseconds after they first pressed the button, and the game logic will run two or three times before considering their input.
There are ways to make a game more responsive at lower than 30 fps, but it’s not obvious nor straightforward. For example, sampling input after rendering but before fixed update would cut down the latency in half.
AFAIK Unity always felt like it had higher than average input latency. I’m saying “felt” because it has been discussed many times over the years on the forums, but we’ve never been able to quantify if there is extra frames of input latency.
Then the new input system came, and it definitely had more input latency on certain platforms ( source : Understanding, Measuring, and Reducing Input Lag in Unity? ). Not sure what the state is now because we gave up on it a while back because in our eyes, they obviously had wrong priorities if reducing input lag wasn’t in their top goals.
Personally, it is my belief that Unity’s input has a frame or two more latency than it should and at low frame-rate it becomes even more apparent.
Combine that with the generally unstable delta time, which makes every thing feel jittery and weird (which I guess is partially addressed for some platforms now) and that makes Unity 30fps feel extra bad.
Combine all the above with the fact that 30fps needs a bit of care on how you design your game, and most indies don’t have that expertise. 3rd person forward movement can look fine, but side-scroller-like horizontal scrolling can look extra bad and stuttery. You generally need high quality motion blur to mask a bit of this, but again that’s an area where Unity is lacking.
Usually controlling things under heavy framerate drop is not going to be fun, regardless of the engine.
By default at least some tutorials used to use Input.GetAxis. Here’s the thing. GetAxis has inertia built in and does not respond to controls immedeately. The ones that are immediate are GetAxisRaw. When I was porting unity code to unreal, this kind of discrepancy came out as a surprise.
Yeah AAA just have better timing, optional triple buffering, loops, motion vectors, motion blur, input etc. They solved it all long ago while Unity didn’t recognise any of it as a problem. Hard to if you’re not making console games yourself.
I remember talking about this subject on Sony’s internal dev net forum many years ago (the Unity part). It was my post, but I can’t share any of the answers from it.
I think today’s Unity is capable of AAA quality stepping, timing, movement but absolutely definitely not out of the box. A lot of work, and scouring GDC archives will be needed. All the little tricks like scaling your motion vectors differently for framerate vs continual motion and so on would be a great start.
None of that is provided by Unity out of the box. It’s just basic motion vector data that doesn’t really compensate for framerate differences. You could probably make a formula to tweak the post effect settings but it would still need a lot of tuning.
Then input buffering / timimg, physics etc…
So yeah, I very much have noticed a big difference between Unity and AAA titles when frames drop and both have motion blur. For me, because I rely on sight so much, it’s a pronounced difference. For others, possibly not. It was enough for me to research, at least.
If anyone’s doing research and tests, I’m really interested in the findings.
Unity doesn’t support triple buffering AFAIK, unless in platforms where it’s enforced by the OS like Switch and mobile.
To make matters worse, on certain consoles setting target framerate does nothing, so your options are either see your game drop straight to 20fps if it dips bellow 30fps or unlock the framerate and live with screen tearing.
When you say triple buffering, what exactly are you talking about? Traditionally, that meant having 3 rendering buffers where one is displayed, one is queued to be displayed and the last one is being rendered to. This doesn’t map to all graphics APIs the same way, but Unity should behave that way in most cases.
Dropping straight to 20 fps if you dip below 30 fps sounds like a bug, tbh. Unfortunately, these things tend to be very platform specific and sometimes slip through on some platforms. I know for certain that it shouldn’t be the case on Windows Standalone.
In all the time I’ve spent playing on PC, I’ve never seen triple buffering have any noticeable effect.
Basically, traditionally it meant that instead of 2 buffers (front and back) there were three. The benefits of that were very dubious. If you’re spending too much time painting with two buffers you’ll be spending too much time painting with three. Especially when you do not necessarily blit, but swap.
Technically the “triple buffering” option used to be popular in the time when there were tons of WWII games on Quake 3 engine. At some point it stopped appearing as an option. Like W-buffer.
It’s on PS4 where vsync in Unity works much like it did in the old days of PC gaming where vsync with plain double buffering would cause the game to wait for the next vsync if it doesn’t finish the current frame in time. So if you set vsync count to 1 but your frame takes even 1ms longer than 16ms to complete, Unity will sit and wait for the next vsync, dropping the effective framerate from 60 to 30.
The compositor on Windows and other platforms like mobile and Switch offers “free” triple buffering, so this isn’t a problem on those. But on platforms like PS4 the games are supposed to implement their own sync strategies if they want anything fancier than plain old vsynced double buffering, AFAIK, which Unity doesn’t do.
It stopped appearing because OS compositor provide the same effect without games having to manage it: The third buffer is the copy used by the compositor for displaying.
With double buffering and vsync on a 60hz display you can only run at 60fps, 30fps, 20fps, 15fps, and so on. If the game takes 18ms to render a frame, it will miss every other vblank and run at 30fps. But with a longer swap chain, it will be able to queue two frames instead of one, which can be displayed consecutively.
Of course, eventually it will run out of queued frames and will miss a vblank again, causing the infamous “juddering” because every few frames a frame will persist so the GPU can catch up, but the industry seems to much prefer that over screen tearing, considering it’s now ubiquitous on console games.
On PC, if you always had hardware to keep games well above 60fps of course triple buffering had no effect.
Developers can make games that performance well or poorly with any game engine. I have personally built games in Unity that can run 300 FPS with 30ms button to pixel latency. As a reference, CSGO has a button to pixel latency of 71ms on the same hardware.
If it seems like an unusually high number of Unity games have problems, then I can only guess that it is because Unity is very accessible for a lot of new developers.
The OP is not talking about performance, but how games behave when their framerate go below 30fps, something that is getting more common as games using HDRP (which has very limited scalability options and doesn’t run well on integrated GPUs) are hitting the market.
Most of the top popular PC games go out of their way to offer scalability options that run reasonably on integrated graphics. If you’re going for mass appeal on PC, it’s a must.