Why More FPS Made My UE5 Game Feel Worse

4 June 2026 · Devlog

I packaged my city builder and it ran at 200+ frames per second. It also felt terrible: stuttery, jolty, and every camera pan made me wince. The fix turned out to be a few lines in an ini file. In this article I walk through how I diagnosed it with stat unit and stat unitgraph, why the same spike feels far worse at 200 fps than at 60, the DefaultEngine.ini changes that fixed it, and what the cap does not fix.

The Shipping build felt worse than the editor

The project is CityGen V0.6, a UE5.4 city builder. I packaged a Shipping build and ran the .exe on a modern PC with plenty of headroom.

Project:  UE5.4 city builder (CityGen V0.6)
Build:    Shipping, packaged .exe
Hardware: Modern PC, plenty of headroom

Editor PIE  →  silky smooth
Shipping    →  noticeable hitches when moving the camera

Identical world. Identical code. Different feel.

Same map, same content, same player input. The editor felt fine; the packaged build hitched on movement. That’s the puzzle, because the Shipping build is supposed to be the faster one. So what was actually going on?

Reading the numbers with stat unit

stat unit is the four-line readout every UE dev should know. Open the console with the backtick key and type stat unit:

  Press  `  to open console
  Type:  stat unit

  Frame:   5.0 ms   ← total wall-clock per frame
  Game:    2.1 ms   ← game thread (CPU)
  Draw:    1.8 ms   ← render thread (CPU)
  GPU:     3.6 ms   ← graphics card

Frame is the headline number. Game, Draw and GPU tell you where the time goes: the game thread, the render thread and the graphics card. With 5 ms per frame I was running at 200 fps. So where was the problem?

stat unitgraph shows the spikes

stat unitgraph plots frame time over the last few seconds, and that’s where the problem showed up:

   ms
   ▲
40 │              ▲                          ▲
30 │              █                          █     ← 30 ms spike
20 │              █                          █
10 │              █                          █
 5 │ ──────────────█──────────────────────────█──   ← 5 ms baseline
 0 └────────────────────────────────────────────►  time

The baseline was a flat 5 ms. But every couple of seconds, when I moved the camera, frame time spiked to 30 ms or more. Isolated, sharp, then back to flat. That’s what was killing the feel.

Why the spike felt so bad

Here’s the key insight: the spike itself doesn’t change. The underlying work is identical whether the frame rate is capped or not. What changes is how big the spike feels relative to the baseline.

   No cap, 200 fps baseline:
     5 ms baseline  →  30 ms spike  =  6 × jolt
     One frame stretches from 5 ms to 30 ms.
     Your eyes track the SUDDEN CHANGE, not the absolute time.

   Capped to 60 fps, 16.7 ms budget:
     16.7 ms baseline →  30 ms spike  =  1.8 × jolt
     Same spike. Now it's a single missed frame.
     Reads as "one dropped frame", not "the world froze".

At 200 fps the baseline is 5 ms, so a 30 ms spike is six times the steady frame. Your visual system is wired to notice changes, not absolutes, so that 6× jump reads as a violent hitch. Cap to 60 and the baseline becomes 16.7 ms. The same 30 ms spike is now 1.8× the baseline and reads as a single dropped frame. Same work, different feel.

Variance beats raw rate

   ╔═══════════════════════════════════════════════╗
   ║                                               ║
   ║   Perceived smoothness  ≠  peak FPS           ║
   ║                                               ║
   ║   A consistent 60                             ║
   ║   beats a swingy 200                          ║
   ║   every time.                                 ║
   ║                                               ║
   ╚═══════════════════════════════════════════════╝

This is the headline lesson. Frame variance dominates perceived smoothness, not frame rate. A locked 60 with low variance reads as smoother than an uncapped 200 with high variance. The industry already knows this, which is why almost every console release ships with a frame cap and VSync on by default. On PC, we’re the ones who keep forgetting.

The fix in DefaultEngine.ini

Add these settings to Config/DefaultEngine.ini. It’s four settings across two sections:

[/Script/Engine.Engine]
bSmoothFrameRate=True
MinSmoothedFrameRate=22
MaxSmoothedFrameRate=60

[/Script/Engine.RendererSettings]
r.VSync=1

bSmoothFrameRate=True enables UE’s frame pacing system.
MaxSmoothedFrameRate=60 is the hard cap.
MinSmoothedFrameRate=22 smooths the floor if you ever do drop.
r.VSync=1 syncs presents to the monitor refresh, so you get no tearing on top of the cap.

Repackage, and you’re done.

Does VSync hurt anything?

VSync isn’t free. Here’s the trade-off:

   COST                            BENEFIT
   ────                            ───────
   +1 frame of input lag           No tearing
   (~16.7 ms at 60 Hz)             Predictable cadence
                                   Lower GPU temps
   If you miss vblank,             Frame pacing aligned
   drops to 30 fps that frame      to monitor refresh
   (UE5 mitigates via triple buf)


   FOR A CITY BUILDER / RTS:  worth it, easily.
   FOR A TWITCH FPS / FIGHTER:  probably not.

The cost you’ll notice is one frame of input lag. In a Cities: Skylines-style game, where you’re clicking buttons and panning a camera, that’s invisible. In a Counter-Strike clone, where mouse-aim latency matters, it’s a deal-breaker. Match the choice to the genre. For my slow-paced strategy game it was an easy win.

The cap hides the real bug

To be honest about it: capping the frame rate did not fix the chunk-upload spike. The spike didn’t go away; I just changed the denominator.

   Capping fps DID NOT fix the chunk-upload spike.
   It just made it smaller in proportion.

   The real cost is still there. To actually fix it:

     →  PSO precaching      (shader compile stalls)
     →  MaxBuildsPerFrame 1 (chunk upload throttle)
     →  Lower foliage density
     →  Larger texture pool

   That's a separate video.
   For now, the cap is enough.

The chunk-upload work still happens, and on a high-refresh display or in VR those frames will still hurt. The right long-term fix is PSO precaching to deal with shader compile stalls, lowering MaxBuildsPerFrame to throttle chunk uploads, watching foliage density and giving the texture pool more room. I’ll cover that in a future video. For a demo at 60 fps, the cap is a config-only change that ships today.

Don’t optimize for the wrong number

   Before:    200 fps,  high variance,  feels bad
   After:     60 fps,   low variance,   feels great

   Same code. Same machine. Same frame.
   Different number on the FPS counter.

   The number that mattered wasn't the one I was watching.

The lesson applies well beyond frame rate. Whenever you’re chasing a metric, ask whether it actually correlates with what the player experiences. FPS is easy to measure and easy to brag about, but it’s only loosely connected to perceived smoothness. Frame variance and consistency win every time. Don’t optimize for the leaderboard number; optimize for the experience.

Build

Learn

Community

© 2026 CodeLikeMe · Thilina Premasiri