[HOWTO!] 360hz in a 250FPS locked game

[chandler]

EDIT: I meant what resolution do I choose while going through the steps if Im playing non-native in game (1024x768 to be exact) thats the thing I am a bit confused about... because everytime I did large VT on older monitors I did choose native (even when playing 4:3 resolutions) but now it seems not so right

Combining QFT with non-native resolutions is kind of tricky. Easiest to stick to native resolution, as it's much simpler, and native resolution actually isn't laggier than lower resolution, when properly configured. At a locked 250fps, your GPU utilization practically disappears in those games that render frames in just a millisecond, ending up with no lag difference between 1024x768 or 1920x1080.

Start with that FIRST, before trying to go non-native which can sometimes wreck QFT compatibility (unless you understand what a "Back Porch" means in a video signal).

So youre saying that :

1) 1024x768 isnt smoother than native on older games? because whenever I play native I feel in my gameplay that the input lag is higher...kind of like I am playing on "less hertz" that I actually am, like 120 at 1024 is still faster than native.. every competitive FPS felt that way.

AND

2) whenever I configured a 1920x1080@180hz resolution, and then got into ny game which I played on 1024*768, the crosstalk wasnt actually like on the UFO tests? ( = 80% of the screen ghosting free?) The lowered resolution cancelled that?

[Chief Blur Buster]

2) whenever I configured a 1920x1080@180hz resolution, and then got into ny game which I played on 1024*768, the crosstalk wasnt actually like on the UFO tests? ( = 80% of the screen ghosting free?) The lowered resolution cancelled that?

No, it's the lowered refresh rate that cancelled that. Refresh rate headroom is what reduces strobe crosstalk.

[Chief Blur Buster]

1) 1024x768 isnt smoother than native on older games? because whenever I play native I feel in my gameplay that the input lag is higher...kind of like I am playing on "less hertz" that I actually am, like 120 at 1024 is still faster than native.. every competitive FPS felt that way.

There can be many mudane explanations (perceptual and/or display and/or real-vs-placebo), but the ROI of diving into this rabbit hole is not worth it; go with what feels best. However you may lose QFT opportunity. Have you ever tried native-resolution QFT before, and compared to 1024x768 at least?

The biggest reason may be you're using an older GPU? Or using settings that create a rendering latency between 1024x768 versus 1920x1080. Rendertime lag on older GPUs can still be high even in framerate capped game. A GPU that takes 1/300sec to render a frame at 250fps at native, may take 1/1000sec to render a frame at 250fps at native. The lag differential of 1/300sec and 1/1000sec is more than 2ms. But things change when you Quake Live on an RTX GPU, both take less than 1ms to render a frame even at 250fps cap, and DIFFERENCE(native,scaled) = more identical on newer GPUs.

Just because you are capped at 250fps, does not mean a faster GPU won't help; it eliminates the native-rez penalty, zeroing out the GPU utilization % between native-vs-scaled.

There are about 10+ other reasons, but this is the most common reason for a (non-placebo) latency between native-vs-low at identical capped frame rates: "Using an older GPU".

What GPU are you doing, and what is your GPU utilization at low-vs-native?

[chandler]

1) 1024x768 isnt smoother than native on older games? because whenever I play native I feel in my gameplay that the input lag is higher...kind of like I am playing on "less hertz" that I actually am, like 120 at 1024 is still faster than native.. every competitive FPS felt that way.

There can be many mudane explanations (perceptual and/or display and/or real-vs-placebo), but the ROI of diving into this rabbit hole is not worth it; go with what feels best. However you may lose QFT opportunity. Have you ever tried native-resolution QFT before, and compared to 1024x768 at least?

The biggest reason may be you're using an older GPU, or using settings that create a rendering latency between 1024x768 versus 1920x1080. Rendertime lag on older GPUs can still be high even in framerate capped game. A GPU that takes 1/300sec to render a frame at 250fps at native, may take 1/1000sec to render a frame at 250fps at native. But things change when you Quake Live on an RTX GPU, both take less than 1ms to render a frame even at 250fps cap, and DIFFERENCE(native,scaled) = more identical on newer GPUs.

Just because you are capped at 250fps, does not mean a faster GPU won't help; it eliminates the native-rez penalty.

Well CoD4 specifically I played on PCs with GTX 970 and 980. (With i7 4790k)
Havent installed it on my newest one with RTX 4070 and 12700KF

[Chief Blur Buster]

Well CoD4 specifically I played on PCs with GTX 970 and 980. (With i7 4790k)
Havent installed it on my newest one with RTX 4070 and 12700KF

There's your problem. You have a native resolution penalty simply due to old GPU

You can zero-out your scaled-vs-native lag penalty by using a faster GPU, even if your framerate is unchanged!

[chandler]

Well CoD4 specifically I played on PCs with GTX 970 and 980. (With i7 4790k)
Havent installed it on my newest one with RTX 4070 and 12700KF

There's your problem. You have a native resolution penalty simply due to old GPU

You can zero-out your scaled-vs-native lag penalty by using a faster GPU, even if your framerate is unchanged!

I see. Well Ill install the game on my main PC and try making the 250hz custom res to test it with NATIVE EXCLUSIVELY. And then Ill compare it to 1024*768.

By the way, any idea if Q3 Engine games work properly with higher than 1000Hz polling mice?

[Chief Blur Buster]

By the way, any idea if Q3 Engine games work properly with higher than 1000Hz polling mice?

Not sure, old engines do sometimes degrade at a higher poll, but you will need to test out.

The synchronousness of the polling more than outweighs the brute pollrate most of the time, so you can test 250 vs 500 vs 1000 vs 2000 and see what is lower lag, in a pollinterval-versus-CPU-utilization tradeoff. Higher poll has lower lag in theory, but the higher poll also thrashes the CPU in the game engine. There's a sweet spot crossover point that varies from game to game.

However, if you framerate-lock Quake 3 to your refresh rate, you can just use a motionsync-compatible mouse (the Razer 8Khz can do it at any pollrate 4KHz or below), use a screen Hz multiple (250Hz or 500Hz), set mouse to 1000Hz and call it a day. Assuming of course, Quake 3 is not using an odd tickrate.

Games with non-divisible tickrates 64/128Hz is pretty oddball compared to mouse pollrates 250/500/1000, so you got less motionsync optimization opportunities and just need brute framerate and pollrate to work around it all. Best for games adopt a tick rate that's a comfortable divisor of a mouse pollrate, for more motionsyncing opportunities.

There are games that clearly DO benefit from 2000Hz+ (especially if you use strobed + high DPI + odd Hz or varying Hz or varying framerate). The brute poll rate oversamples the erraticness to smooth things out (even if not quite as smooth as quad sync optimization). My "quad sync" tweak suggestion is one of the situations where you can back off on pollrate and rely on the nice motion sync instead.

[chandler]

By the way, any idea if Q3 Engine games work properly with higher than 1000Hz polling mice?

Not sure, old engines do sometimes degrade at a higher poll, but you will need to test out.

The synchronousness of the polling more than outweighs the brute pollrate most of the time, so you can test 250 vs 500 vs 1000 vs 2000 and see what is lower lag, in a pollinterval-versus-CPU-utilization tradeoff. Higher poll has lower lag in theory, but the higher poll also thrashes the CPU in the game engine. There's a sweet spot crossover point that varies from game to game.

However, if you framerate-lock Quake 3 to your refresh rate, you can just use a motionsync-compatible mouse (the Razer 8Khz can do it at any pollrate 4KHz or below), use a screen Hz multiple (250Hz or 500Hz), set mouse to 1000Hz and call it a day. Assuming of course, Quake 3 is not using an odd tickrate.

Games with non-divisible tickrates 64/128Hz is pretty oddball compared to mouse pollrates 250/500/1000, so you got less motionsync optimization opportunities and just need brute framerate and pollrate to work around it all. Best for games adopt a tick rate that's a comfortable divisor of a mouse pollrate, for more motionsyncing opportunities.

There are games that clearly DO benefit from 2000Hz+ (especially if you use strobed + high DPI + odd Hz or varying Hz or varying framerate). The brute poll rate oversamples the erraticness to smooth things out (even if not quite as smooth as quad sync optimization). My "quad sync" tweak suggestion is one of the situations where you can back off on pollrate and rely on the nice motion sync instead.

I understand. Thank you very much for the time you've put into explaining everything

[Caronizeeee]

can someone here post good VT values for 240hz on the XL2566K please? I understand that on 240hz u can make like 85-90% of the screen ghosting-free, and that the 66k's panel is in fact much better at 240hz than older 240hz benq screens like 2540 and even 2546k

For XL2566K with Quake Live, if you want to "sync" better;

For Quake Live, I strongly recommend using custom 250Hz instead of standard 240Hz.

Strobed Quake Live looks MUCH more CRT-like that way

XL2566K can do any custom refresh rate, you can create 213.5235Hz and 303.666Hz, so why 240Hz for Quake Live? Why not sync to Quake Live!

You should try sync your framerate / pollrate / refreshrate multiples as much as you can, when it comes to Quake Live. It's such a game that benefits significantly from syncing it all up.

Also, Quake Live works wonderfully with RTSS Scanline Sync (tearingless VSYNC OFF), especially with its low GPU utilization + QFT-based 250Hz where the VBI is so large you can easily "raster steer" (via RTSS Scanline) a tearline offscreen between refresh cycles. Things looks TestUFO-smooooooooth in Quake Live that way (silky), like VSYNC ON but without the lag of VSYNC ON. You get refresh-rate locked motion, at ultra low latency, without the tearing, and zero microstutters and zero tearing.

Generally, XL2566K has a "continuum" of better-and-better for every 1Hz you go closer to framerate=Hz, so the 10Hz makes a quite noticeably big difference with Quake Live. The 10 microstutters/sec completely disappear (beat frequency of 240 versus 250)!

And to get 250Hz with the same low lag of 360Hz, yes, you need to use large VT via ToastyX CRU.

________________

Now to do large VT's:

Use the ToastyX Vertical Total Calculator to do automatic VT values; the new version is much easier to create large-VT's on XL2566K.
1. Load the 360Hz resolution in Extension Block in ToastyX CRU.
2. Change calculation to "Vertical total calculator"
3. Edit "360" to "250".
4. It automatically calculates your Vertical Total.

Now you've got a 250Hz custom mode that transmits refresh cycles over the video cable in 1/360sec apiece.

Once you set up RTSS Scanline Sync, this best-kept-secret XL2566K Quake Live trick blows away both 240 and 360 modes.

Does this tool work for other monitors and games? I have an Acer 390hz, I am currently using it at 360hz with strobing activated. However, I'm playing Fortnite where I'm limited to 360fps in the game, but I get 220/360 fps during the game, depending on the location, most of the time an average of 300. I'm thinking about using 240hz to use strobing more effectively. What do you recommend?

[Chief Blur Buster]

Does this tool work for other monitors and games?

It works with most modern displays, yes.

Fixed-Hz QFT works on most FreeSync-compatible panels, since their panel/scaler/TCON was already optimized for the QFT component of VRR. (VRR=QFT). Fixed-Hz non-VRR QFT is simply a side-effect undocumented feature of VRR panels, where you can create custom fixed-Hz non-VRR QFT modes that has the low lag of MaxHz.

The existence of VRR simply means the hardware is generally more capable of accepting a custom QFT signal.

I have an Acer 390hz, I am currently using it at 360hz with strobing activated. However, I'm playing Fortnite where I'm limited to 360fps in the game, but I get 220/360 fps during the game, depending on the location, most of the time an average of 300. I'm thinking about using 240hz to use strobing more effectively. What do you recommend?

Depends. There's a risk of lowering your frame rate and Hz of Fortnite, as 250fps is laggier than 300fps.

If you want the framerate=Hz experience in Fornite, it's MUCH harder to optimize framerate=Hz strobed without adding latency, due to the high GPU utilization of that framerate in that game. You're not going to easily get below 50% GPU utilization at 300fps in Fortnite.

My recommendation of using a lower Hz for improving strobing has less latency-tradeoffs for 250fps-permanently-framerate-locked game. But Fortnite is not framerate locked in the first place, and adding a framerate lock can accidentalldd input lag.

There are a few approaches;
1. Brute it with VSYNC OFF and uncapped or high-capped framerate; or
2. Create a custom Hz that matches your 0.1% or 1% lowest framerate (if that's 275fps, create 275Hz) and test-lock your framerate to that (NULL + VSYNC ON). It's a bit laggier than RTSS, and a bit laggier than VSYNC OFF, but you get that perfect framerate=Hz strobed experience of TestUFO smoothness.
3. Do like #2, but create a custom Hz that enables you to do a quad sync, do 250Hz to sync up your pollrate too.

You have many pick-poisons, that might create compromises that simply don't exist with a perma-locked game like 250fps QL or CoD4, the game has a built-in cap that you conveniently can sync to, without having to ADD a cap (that might add lag to Fortnite).

So pick-poison right out of gate, right there. But quad sync benefits might outweigh the drawbacks for CERTAIN types of Fortnite techniques. Try it. But it won't have as much ROI as for QL or CoD4.

Give it a try! It will look beautiful motion (supersmooth) for eye-tracking while flying. Strobing really benefits trying to aim at ground objects while flying airplanes at low altitudes in Fornite, or those kind of things that strobing really helps (you have to move eyes around away from the crosshairs, just to identify enemies in the camoflaged land below, strobing kills the blur that hides those camoflaged enemies). So flyby attack techniques benefit fairly well from the "quad sync" technique.

But if you're a traditional indoors flick-shooter or stationary camping sniper that locks eyes on crosshairs, strobing and the "quad sync" has less benefit. And if you're a good precise builder, the strobing may actually help you aim your next build step faster and build faster. Who knows? The motion blur reduction lets you see a scrolling/panning/turning screen better whenever your eyes are away from stationary-stare crosshairs.

But even brute VSYNC OFF + strobing still is fairly clear, at those stratospheric frame rates, and tolerating the tearing is what many do, as it's more faint at those frame rates.

But... give quad sync tricks it a try for your playstyle, and see if play improves.

Ditto for RTS games (where you use mouse to pan). If you can get your RTS game to lock at 250fps, then the benefit if a bit higher than normal due to eye-tracking all the rapid panning you do, and aiming your pans faster/better. The 250fps and framerate=Hz locking, allows strobing becomes jitter-free and RTS pans as smooth as www.testufo.com/map since the strobe jitters disappears (no mouse jitters, no framerate jitters).

So a lot more experimentation is welcome. It just a much better ROI for those already-250fps-locked games, because you're already locked to begin with, and you're not adding compromises (like adding a cap that might sometimes add lag).

Related: HOWTO: Using ULMB Beautifully or Competitively for the pick-poison compromises of strobing in esports.