QuakeLive 250 FPS with 120 Hz LightBoost?

[JakeNQuake]

Hi!
So, my latest question. QuakeLive released a standalone client now which has a 250 FPS cap (up from 125 FPS). I'm using it with my Asus VG248QE LightBoost enabled (lowest brightness) 120Hz. Is there any disadvantage to running at such a high FPS? It's *very* noticeably smoother looking, but I guess there must be a huge number of "discarded" (or unseen?) frames. Could that be causing an issue?

Should FPS and refresh rate be the same? 120 FPS @ 120Hz?

[Chief Blur Buster]

Hi!
So, my latest question. QuakeLive released a standalone client now which has a 250 FPS cap (up from 125 FPS). I'm using it with my Asus VG248QE LightBoost enabled (lowest brightness) 120Hz. Is there any disadvantage to running at such a high FPS? It's *very* noticeably smoother looking, but I guess there must be a huge number of "discarded" (or unseen?) frames.

Only portions of frames go missing with VSYNC OFF.
During VSYNC OFF, at least some portion of all frames are seen, even at ultra-high framerate on lower-refresh rate displays.

For example at >240fps @ 120Hz, one refresh cycle can contain two or three different frames, with tearlines separating them. The new frame is spliced in mid-frame to the previous frame.

(1) Improvement #1: The visibility of tearing can actually be reduced, since at 250fps, the tearline offsets are only half as much as during 125fps, during the same speed turning/strafing. This is good for VSYNC OFF with strobe backlights (LightBoost), because the motion blur reduciton makes makes tearing easier to see.

(2) Improvement #2: In addition, another advantage of 250fps @ 120Hz is that there's less input lag at 250fps than 125fps, since frames are finished in 1/250sec, rather than in 1/125sec. So mouse/keyboard input is stale by only 1/250sec instead of 1/125sec.

So 250fps VSYNC OFF can look/feel much better than 120fps VSYNC OFF especially if you prefer to play VSYNC OFF during LightBoost use.

[JakeNQuake]

Awesome! Glad to know that it's actually a positive. It *feels* and *looks* very significantly better. Thank you!

[nspnet7]

240fps vs 250fps

which is better for 120hz lightboost?

[Chief Blur Buster]

240fps vs 250fps

which is better for 120hz lightboost?

That's an excellent question. It has a technical answer.
Here, we're assuming VSYNC OFF and Quake Live, so those are now two big reasons to use 250fps instead of 240fps:

(1) The Quake Live engine runs at 125 or 250 frames per second; so that is the ideal framerate to use, to stay in sync with the engine.

(2) Avoiding annoying stationary tear-line effects during VSYNC OFF. At 240 frames per second, you have two tearlines per frame, and both tearlines become stationary since 240 is an multiple of the 120Hz refresh rate (on a 120Hz monitor). This is the same side effect seen when trying to use VSYNC OFF frame-rate locking (fps_max 120) during source engine games -- the tearline can become stationary or slowly moving (if the frame rate is slightly higher or lower than the refresh rate). This is because tearline is reoccuring in the same place (or near) of the next refresh as the previous refresh, so the tearing becomes even more annoying. That's why during VSYNC OFF, it's best to use framerates away from numbers that are harmonics of the refresh rate.

Advanced Geek Note: The position of the tearline is based on the current position of the top-to-bottom scan-out (as seen in high speed videos), which is based on the current display mode's Horizontal Scanrate. This is the raster scanning[google] process. The tearline occurs at the instant a frame is finished, and the existing display refresh scanout is essentially "spliced over to the next frame", which may cause skew effects during horizontal motion (aka tearline). Currently a 1080p display at 120Hz does a horizontal scan rate of 135KHz. (Sometimes this is called the "horizontal refresh rate" aka the number of rows of pixels "painted" by a display per second). The Horizontal Scanrate (at 1080p@120Hz) is ~135KHz which is mathematically calculated from (1080 scan lines + ~45 lines of blanking interval) x 120Hz refresh = ~135,000 horizontal scan rate = 135 kilohertz = 135 KHz. The Horizontal Scan Rate is often a number found in utilities such as PowerStrip, ToastyX CRU, and Custom Resolution Utilities. The name is a carryover from the analog era. At 135KHz horizontal scan rate (typical scan rate for 1920x1080 @ 120Hz), it means one row of pixels get transmitted from GPU to monitor every 1/135,000th of a second). Video signals (VGA, DVI, HDMI, DP) transmit at a finite speed, often at a constant rate. If a GPU rendering is finished during VSYNC OFF, the new frame is immediately transmitted in the same physical position of the existing, uninterrupted refresh scan-out (Creating the tearing side effect). As you may have already figured, above the tearline is an older frame and below the tearline is a newer frame. Regarding the blanking interval, that's small delay between refreshes, and if you've ever owned an analog TV, that's the black bar you see when the picture is rolling (VHOLD misadjustment). That black bar is still there in computer signals, never seen, as a delay between refreshes. The blanking interval in the signal (what we call VSYNC) was originally there to give time for a CRT electron gun to move from the bottom edge of the screen, back to the top edge of the screen, to start a new scan (high speed videos). Now, during VSYNC OFF, the tearline positions depend on how long each frame takes to render. If a frame takes 1/120sec to render, that's going to be 1/120th of 135,000, which means the tearline will be reoccuring same vertical physical position on the screen, since pixel row repaints repeat in the same physical position of the screen every 1/120th of 135,000, since the scanning goes off the bottom of the screen then wraps around back to the top of the screen (as you see in the high speed videos). Now if you do this twice (240fps), you've got two tearlines in two different positions of a refresh, and they'll re-occur in the same location unless the framerate is varying or randomizing. At exact 360fps at exact 120Hz (if your GPU can do it) you've got three tearlines per refresh that can reoccur in the same location. And so on. So people often use fps_max 119 or 121, or odd numbers like fps_max 250 or fps_max 500. This prevents the stationary-tearline side effect (tearlines continually repeating in the same positions of subsequent refreshes).

[aMunster]

Jake,

One caveat. 250 fps causes sound bugs, specifically with footsteps. Once engine bugs like this are fixed, I'm moving to 250fps. The physics are fps-independent, so it should be fine for your purposes.

[Chief Blur Buster]

Jake,

One caveat. 250 fps causes sound bugs, specifically with footsteps. Once engine bugs like this are fixed, I'm moving to 250fps. The physics are fps-independent, so it should be fine for your purposes.

Good points.

At least it's nothing like Sky Rim MAJOR glitching when running at faster than 60fps (or Glitch in the "Wreck-It-Ralph" movie)!

[spacediver]

jakenquake, what name do you use in quakelive? I'm Julios.

[unitedflow]

So with Quake live's max fps of 250 and a gsync monitor with 165hz what setting would give the lowest input delay? 250fps with 165hz and no sync?

[Chief Blur Buster]

Holy thread bump -- this thread dates back to year 2013.

250fps VSYNC OFF is the lowest lag, although if you have a 280Hz+ monitor (280Hz, 300Hz, 360Hz) then VRR creates a delightfully consistent lagfeel with Quake Live's 250fps self-capping feature. The super-solid latency consistency can outweigh the scanout latency, when VRR Hz is beyond the game's natural framerate cap.