240hz on 60FPS games

[RealNC]

A 60FPS game is obviously using its own frame limiter. You would only use RTSS if you wanted to set a limit lower than 60FPS.

For other games, a frame limiter can reduce input lag (even with vsync off.) For example, if your average FPS in a game is 134FPS and you set the frame limiter to 133FPS, you get an input lag reduction. Basically, whenever the FPS limit you set is reached (meaning the limiter becomes active), you get about 1 frame of latency reduction (RTSS) or 1-2 frames (in-game limiter,) depending on the game. This mostly affects GPU-limited games.

[crossjeremiah]

I see, would using CRU lessen the VSYNC LAG, because RTSS can't be used(what about nvinspector) . Or does the ingame frame limiter override that as well?

[Chief Blur Buster]

RTSS can be carefully tweaked for low-lag VSYNC ON if you follow instructions carefully,

See this:
HOWTO: Low-Lag VSYNC ON

[crossjeremiah]

Yes, I know. Thank you again for your quick response. I was just going off what RealNC was saying. Because he said it was useless to do at 60fps. But I do know people who have disgusting tear lines when they dont have vsync, and they dislike vsync because of input lag. I just want to help some friends out and the community. Also can this frame limiting technique reduce input lag in triple buffering too ( I know its exclusively for OpenGL, but I've read you can use it with DirectX within NvInspector, but correct me if I'm wrong)

This is how I have it set now
https://imgur.com/a/OsVS7

(overlay works fine, had to make sure I use MSI Burner ver.)

144hz because of the low input lag of 6.94 instead of 120hz at 8.33.

I'm sorry if asking these things seem repetitive. I've read through so many forum posts, and they are all about modern games, like Far Cry, Witcher, and Overwatch. Emulators are not really a topic, and since a team released a low-lag version of Dolphin for netplay just for the community. My interest for input lag sky-rocketed. Their members understand input lag in a console standpoint, but some of them dont understand lag reduction techniques for vsync like the one you listed above. Actions and reactions are literally frame by frame in this game, its 100 apm gameplay at 60fps. https://www.youtube.com/watch?v=8vyBV94K4SE

[RealNC]

With vsync off, triple buffering is useless.

With vsync on, triple buffering will increase input lag by 1 frame. Many games actually offer a choice between "double buffered vsync" and "triple buffered vsync." Games that don't offer the choice might be using double or tripple buffer and there's no way to actually know what they actually use.

In any event, the effect of frame capping with tripple buffering is not clear. I don't think anyone tested this.

[crossjeremiah]

Ya frame capping is not a thing the community uses. So I have RTSS configured and disabled vsync, and ran the game. The input feels identical to console. But that might be a placebo because I want this method to work. With RTSS it feels a good, without RTSS it feels off, but that might be just me.


Thank you again.

[Chief Blur Buster]

The Melee community is filled with people who are sensitive to input lag, I literally feel like I'm not hitting my timings, and such so I have either increase the input lag or decrease it.
This is how input lag in melee basically works.
http://kadano.net/SSBM/inputlag/

That's some fantastic testing and research there.

Lag of displays are extremely complicated. The lag mechanics of everything (scanout lag, VSYNC ON lag behavior, VSYNC OFF lag behavior, lag just above/below tearlines, framebuffer queue, monitors capable of line-buffered output, asymmetry or symmetry between cable scanout and display panel scanout, etc.

That's where BlurBusters comes in -- we're the experts in knowing display lag mechanics.

Certain monitors may have a little bit more top-edge lag (than a different monitor), but a lot less bottom-edge lag (than a dfferent monitor). There is a vertical lag gradient corresponding to scanout. And the vertical gradient can be stretched/compressed (different escalatingness of lag along Y-axis) and/or with added/removed absolute lag offsets (global offset) for all pixels. but there's also a simultaneous absolute-lag offset occuring. Those two behaviors can be independent and a different display may tip-the-scales in behaviour. Even the (X,Y) position of a pixel is not an apples-versus-apples latency comparision to the same pixel on a different display!

VSYNC OFF is scanout following so theoretically lagless for all pixels (for infinite-framerate VSYNC OFF situation), with top/bottom exactly equal. But only if cable scanout velocity exactly matches panel scanout velocity! When these diverge....interesting lag mathematics happen.

For example, another major complication I found (which partially explains why 240Hz monitors aren't good for non-VRR fixed-Hz 60Hz operation yet). For example, during VSYNC ON, I've recently discovered that the 240Hz panels have to stay at full scanout velocity -- they scanout at 1/240sec even during 60Hz. So they partially buffer a 60Hz refresh cycle and scan out at 4x the velocity. So about 3/4ths of a frame delay (12ms) for top edge and no frame delay for bottom edge. And the scanouts meet when bottom edge is finally scanned out. So lag of 60Hz is [+12ms, +6ms, +0ms] offsets for TOP/CENTER/BOTTOM. This is a scanout asymmetry effect between cable scanout and panel scanout, since the 240Hz panels don't seem to be able to be slowscanned (like some other panels are). This is not an issue for 60fps VRR -- because there's no delay for top-edge during that situation -- but 60Hz fixed-Hz is a slow-scanning video signal on a cable (top-to-bottom calender-style pixel-by-pixel delivery over the cable, in 1/60sec), and the monitor can't begin scanning until it has enough image data to do a full-velocity 1/240sec top-to-bottom panel-refresh scanout. Some panels have a native scanning velocity, so a monitor is forced to buffer more rather than run virtually lagless line-buffer (e.g. true 240Hz mode).

So, you see, display lag can get really complicated!!

[lexlazootin]

It's just anecdotal but my bother is big into the smash scene, he got a CRT that he plays on and plays competitively or whatever. I gave him my old G-Sync monitor and set him up and he said it felt lower latency then console.

I remember i did some latency testing but i can't find my results. Ideally G-Sync would be the best setup, Low latency, no tearing.

[crossjeremiah]

The latency will feel lower than console according to what buffer you use on netplay. The build is has the lowest latency pipeline, so if you run Melee without a buffer (which you edit in the netplay window) it will be definitely faster than crt, that leads to inconsistency in certain tech.
One of the creators in the faster melee scene absolutely despises GSYNC, but maybe he assumed that if the monitor refresh rate attaches to the fps then it would higher input lag in general. All this information, renews my faith in gsync.

Honestly I've been playing this game on 144hz no vsync and I dont notice the tearing, im sure there is some.

[Chief Blur Buster]

It's just anecdotal but my bother is big into the smash scene, he got a CRT that he plays on and plays competitively or whatever. I gave him my old G-Sync monitor and set him up and he said it felt lower latency then console.

Yes, not surprising that VRR LCD+PC feels lower lag than console (even CRT+console too! Or anything 60Hz VSYNC ON).

This is because even with LCD delay (+1-2ms GtG) it is more than made up by the super-fast scan velocity (1/144sec = 6.9ms instead of 1/60sec = 16.7ms).

So PC gaming on a good line-buffered gaming LCD feels lower lag than console gaming on a CRT, since the sheer improved scanout velocity (and greatly higher framerate) often more than makes up for the LCD lag.

And since console games are VSYNC ON, you're essentially bypassing VSYNC ON input lag by using a variable refresh rate display. There's no waiting intermediate buffers needed for GSYNC or FreeSync. Once the buffer goes front buffer instead of back buffer, that's the immediate begin of a refresh cycle. Your software just triggered a brand new refresh cycle immediately, and since NVIDIA was able to make GSYNC monitors are scanline-buffered-processing -- you've often got only ~3ms of lag between what's in the GPU framebuffer, and the first pixels beginning to appear at the top edge of the screen.

With a native 240Hz-scanout LCD panel, 60fps at 240Hz is extremely low lag -- far snappier than 60Hz VSYNC ON console gaming -- which is why PC+LCD feels a lot less laggier than console+CRT! Your bypassing of the VSYNC ON framebuffering combined with the fast scanout velocity of 60fps @ 240Hz VRR display.

CRTs cannot bypass scanout lag (e.g. slow-scanning 60Hz video signal).

While their absolute lag is practically zero, there's a mandatory cable scanout lag.

A CRT cannot speed up the video cable!

Still has to wait for the cable to finish scanning out, taking 1/60sec to deliver the pixels from top-to-bottom. (BTW, educational animation on scan skewing: http://www.testufo.com/scanskew -- view this on an old 60 Hz LCD or on an old 60 Hz CRT! The slow scan causes a big skew. Don't view this on a 240Hz monitor at 60Hz, since it does buffer-and-delay during 60Hz scan-convert to fast-scan -- that's why many current 240Hz monitors are terrible at fixed-Hz console 60Hz as the current panels seem to only fast-scan -- unlike some LCD panels that have variable-speed scan)

VRR has no such restriction. 60fps at 240Hz VRR is super-low-lag. 60Hz refresh cycles are displayed to your eyeballs 4x faster, top-to-bottom scan in 1/240sec. The huge lag savings often completely obliterates the LCD pixel-response penalty over CRT (except for motion blur -- which can be a problem for some games). So 240Hz VRR is also an emulator-user's lag dream for button-mash games, even if you're pushing out only 60fps out of that 240Hz monitor.

Lexlazootin is right.