Why do some games perform better at 60 FPS (60 refresh rate) than 90 or 120?

[Iggy Wolf]

My monitor's 1080P 60 hertz display. For some games, I can do a consistent 90 FPS, only capping it there to keep it closer to my refresh rate and so just in case frames dip below, to prevent stuttering.

But I noticed that in some FPS games, especially old ones like Duke Nukem 3D or Doom, capping it to 62 (not 60 so as to avoid tearing) yields smoother results and actually has LESS latency. Is the frame rate being closer to the refresh rate always ideal, or is it game dependent?

[fluxtorrent]

some games and engines tie other programming aspects to framerate. Higher framerates cause these things to break.This also works in reverse too, sometimes the frame rate is tied to how fast everything else is processing.

Simply put everything in the game is designed to run at the same "speed". The game running at a higher speed breaks it.

[Ogami]

Originally posted by fluxtorrent:

Simply put everything in the game is designed to run at the same "speed". The game running at a higher speed breaks it.

Famous example would be classic Skyrim where everything above 60 FPS can lead to hilarious physic bugs like horses launching themselves into the sky, flying carts or dragons rotating into a mountain.

Other example that comes to mind the first Dead Space where many of the time freeze power puzzles bug out completely if you are above 60 FPS.

Fun stuff like that.

[Satoru]

I mean other than maybe GTAV which has a known bug of where the engine goes bonkers after 160fps and stutters like a hello kitty massage wand, it sort of depends on what you're doing

Unless you have like G-sync or FreeSync, and you have vsync on, dips below the 30/60/90/120 thresholds cause the vsync to cap at the lower teir to maintain sync.

Some games tie the physics to a particular refresh rate as well. While this sounds like 'lazy devs' you have ot realize that physics is extremely computationally expensive and having the physics tied to the framerate can result in all sorts of wierdness if the framerater varies dramatically and how you would compensate for various physics based on this variable framerate.

With older games a lot of times the game is synced to the cpu clock, so often times you have to slow down the system or the game goes a bit haywire as its not really intended to be played at such high frequencies. Its possible to run into very quirky situations with older games. Generally emulators like DOSBOX take those into account though.

[Iggy Wolf]

Originally posted by Satoru:

I mean other than maybe GTAV which has a known bug of where the engine goes bonkers after 160fps and stutters like a hello kitty massage wand, it sort of depends on what you're doing

Unless you have like G-sync or FreeSync, and you have vsync on, dips below the 30/60/90/120 thresholds cause the vsync to cap at the lower teir to maintain sync.

Some games tie the physics to a particular refresh rate as well. While this sounds like 'lazy devs' you have ot realize that physics is extremely computationally expensive and having the physics tied to the framerate can result in all sorts of wierdness if the framerater varies dramatically and how you would compensate for various physics based on this variable framerate.

With older games a lot of times the game is synced to the cpu clock, so often times you have to slow down the system or the game goes a bit haywire as its not really intended to be played at such high frequencies. Its possible to run into very quirky situations with older games. Generally emulators like DOSBOX take those into account though.

The physics thing I'm aware of as well. I know Doom 3 on PC has the physics go crazy and things move too fast after 60 FPS, which is why the game has an in-game cap of 63. I think Duke Nukem's objects also move quicker past 60 FPS. I don't use vsync. I use MSI Afterburner to cap it, and will sometimes use the "Ultra Low Latency" option in the Nvidia settings if the game is microstuttering or there's input lag/latency at my FPS cap. I noticed it's only really smooth if the FPS NEVER goes below my cap. If the game ever struggles to actually maintain the FPS at my cap, then there'll be a hitch/stutter or immediate lag, which is why I lower it to 60 sometimes.

[RiO]

Originally posted by Iggy Wolf:

My monitor's 1080P 60 hertz display. For some games, I can do a consistent 90 FPS, only capping it there to keep it closer to my refresh rate and so just in case frames dip below, to prevent stuttering.

But I noticed that in some FPS games, especially old ones like Duke Nukem 3D or Doom, capping it to 62 (not 60 so as to avoid tearing) yields smoother results and actually has LESS latency. Is the frame rate being closer to the refresh rate always ideal, or is it game dependent?

Older games like the two you mentioned, run everything single-threaded and don't use rendered-ahead frames. (Heck; the two you mentioned specifically don't even use any hardware accelerated rendering whatsoever. They're so old they're still software-rendered on the CPU.)

They typically operate on a fixed cycle:

1. Monitor and process input
   
2. Look at CPU clock time, compare to previous frame time to establish time delta and have proper movement speed of entities in the game state
   
3. Compute updated game state
   
4. Render frame into intermediate buffer and push more audio into device buffers
   
5. Wait for vsync
   
6. Render frame
   
7. Back to step 1

To keep those games working well in situations where vsync is disabled, or to keep the simulation from bugging out due to delta-times that are too small (floating point stability errors) they also cap frame time based on a minimal amount of clock time needing to have accumulated before advancing.

Usually that cap will be at slightly below 16.66ms, i.e. slightly below 1/60th of a second. Therefore the net result of using a vsync at 90 Hz is that 'half the time' you will want to vsync for a new frame at a frequency that is midway between two frames where the game wants to cap with that internal clock. And the result of that is you end up in an awkward spot where the next frame has only half the time to compute. And thus you can run short and actually get a long frame, and get stutter.

Sticking closer to 60 Hz keeps that drift between ideal frame times away from the pessimistic midpoint.

Some games used to offer a technique called triple-buffering to alleviate this issue.
The game would render its frames into one buffer and would then swap to another second buffer to render the next frame. Essentially allowing the game to just continue on operating the above loop on its ideal 60 Hz / 16ms frame time for the game engine, while the first completed frame could be kept around to copy to the screen output on vsync. The game would only have to stall and wait, if both buffers contained fully rendered frames - which at the time was a very unlikely event, given the hardware power of the era.

Modern games use the generalized principle of that: render ahead frames. Where you can keep an, in principle arbitrary sized, queue of frames ready to output. But of course; you don't want that queue to be too long, because then you get output latency...