RTSS now has new automatic Low-Lag VSYNC ON (raster based)

Everything about displays and monitors. 120Hz, 144Hz, 240Hz, 4K, 1440p, input lag, display shopping, monitor purchase decisions, compare, versus, debate, and more. Questions? Just ask!
andrelip
Posts: 160
Joined: 21 Mar 2014, 17:50

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by andrelip » 10 Dec 2018, 15:04

The mouse feels very fast and that is not a placebo but I seem to play way worse with it and that could be a placebo. I agreed with you about the monitor scaling and this could be the reason. But some thoughts/considerations:

1) How could they buffer something from a higher scanrate to display at a lower one? They just discard the excessive blank interval? They discard the entire frame?

2) 360hz seems to be the limit for me. Even at 640x480 it didn't pass that value. More than that the display just goes black with osd popping the preferred resolution.

3) We should consider the theory that AW2518HF's panel (AU Optronics M250HTN01.0) could achieve more than 1/240hz but since more than that could reach pixel clock limit of dp 1.2 they decided to limit at that rate.

4) I could actually use 1024x768@240hz with 1/360 scanrate but the screen have massive overshoot.

Totally off-topic but since you asked: I read more than a few hundreds different topics about performance tweaks and games with input lag, negative acceleration and micro-stuttering. DCP latency, Timer Resolution and all those bullshits. None of that gave me any real advantage and the game was always inconsistent with good and bad days even with high fps and relative good pc spec. After I discovered RTSS I skyrocket in the current league that I play here in Brazil for CSGO. I'm Global but that something easy to achieve in my region but in this league I was 16 of total 20 and my k/d for the year fluctuated between 0.8 and 1.1. Now I have 1.48 and I'm 19 of 20 with more than 30 games on record playing with 160hz @ 160fps. I'm not sure if I prefer to cap the fps for perfect stability or set to scanrate of 350 but the game feels way faster with perfect recoil and mouse control. It could also be software related since the calculations and interpolation are better with a perfect frametime.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 10 Dec 2018, 19:24

andrelip wrote:The mouse feels very fast and that is not a placebo but I seem to play way worse with it and that could be a placebo.
It's very system dependant and person dependant on how you perform.

Could be unknown lag or playfeel factors
There are unknown lag factors such as scaling (might not be it..) I can't tell, or you might be trained to play with slightly more lag than you currently have. Also, strange interactions with mouse pollrate may occur, or RTSS may be adding some extra lag that cancels-out the lag savings. We'd have to use a button-to-pixels high speed video of the game, to figure what goes on -- though that is time/labour intensive

Could be lag re-training effect
Lag changes (sudden decrease or sudden increase) can affect your game. Remember that aiming at something while panning 4000 pixels/sec (mid-mouse-turn), a 1ms change to lag means a 4 pixel overshoot/undershoot (4000pps / 1000ms) = 4 pixels per millisecond. So a 5ms change to lag, even a sudden 5ms increase or 5ms decrase, means 20 pixel overshoot/undershoot in this situation. This goes pretty much with any display change, your game may be briefly affected until you're used to the new lagfeel. Especially when aiming at fast-moving targets or aiming without stopping turns, etc.
andrelip wrote:1) How could they buffer something from a higher scanrate to display at a lower one? They just discard the excessive blank interval? They discard the entire frame?
No, no, no.

Metaphorically, imagine a big pipe between GPU and monitor motherboard. And a tiny pipe between monitor motherboard and panel. If the pixels are arriving faster than the pixels can be refreshed onto the screen, the "tank" (buffer) fills up. The monitor is still refreshing at its maximum velocity, but that maximum bitrate to the panel (from monitor motherboard to monitor panel) may be less than the cable delivery bitrate (from the GPU to the monitor motherboard). The buffer is simply a temporary "holding tank".

A different metaphor is like Netflix streaming. If your Internet connection is too slow to stream in realtime, Netflix has to buffer before displaying video. The GPU-to-monitor-motherboard is like that "internet connection" and the "monitor-motherboard-to-monitor-panel" is like the video playback beginning.

The buffer may be only up to 1/240sec (per refresh cycle) so the buffer is so brief and imperceptible to human eye. It just a few milliseconds of lag per refresh cycle. But all that's happening is 1/360sec delivery is lagged-down to 1/240sec delivery, so 1/360sec and 1/240sec should be equal on a panel that scansout a whole refresh cycle in 1/240sec. So QFT faster than a panel's scanout velocity, doesn't necessarily worsen things. In fact, in one situation, a display that requires the whole refresh cycle to be transmitted BEFORE beginning scanout -- then a faster delivery can cause a refresh cycle to begin scanning out (from the monitor motherboard's buffer) sooner. But most gaming monitors begin scanout even before the refresh cycle has been fully delivered. So it's just a rolling-window line buffer, that may predict when the scanout completes, and begin refreshing at that moment.

A buffer is simply the only way to convert a slow-delivery (transmission of pixels over cable) into a fast-scanout (playback of pixels onto panel). Fortunately, the way it works is that once enough buffer has been built up, it can begin refreshing the top part of the display even while waiting for the bottom part of the display to finish delivering over the video cable.

[Questions on this is somewhat offtopic, please post future questions about display engineering in the Area 51 Display Engineering Forum]
2) 360hz seems to be the limit for me. Even at 640x480 it didn't pass that value. More than that the display just goes black with osd popping the preferred resolution.
Interesting. That said, I assume you're referring to 1/360sec frame delivery (a lower Hz but frames delivered in 1/360sec), rather than "360Hz" (360 refresh cycles per second). Can you post a screenshot of the best 1/360 mode you created?
3) We should consider the theory that AW2518HF's panel (AU Optronics M250HTN01.0) could achieve more than 1/240hz but since more than that could reach pixel clock limit of dp 1.2 they decided to limit at that rate.
From a cable perspective, that might very well be right. All of these are undocumented quirks since the monitors are typically not designed for faster than 1/240sec -- we're essentially using out-of-spec video signals when we're forcing a quick frame transport via a custom resolution.
4) I could actually use 1024x768@240hz with 1/360 scanrate but the screen have massive overshoot.
So maybe you're not having a buffered refresh cycle after all... (not 100% sure, but...)

Major ghosting worsenings is possible evidence the panel is actually scanning out in 1/360sec! If you're seeing massive ghosting. Massive ghosting, however, can actually worsen reaction time in games -- the ~1ms time savings of 1/360sec versus 1/240sec is massively outweighed by a "more than 1ms slower LCD GtG". LCD pixels can't refresh completely when refreshed too briefly, so pixel response (GtG) slows down. Not enough time sending voltage to pixels. So LCD GtG pixel response suffers during this overclocked scanrate. So you get more lag because of slower pixel response. Trying to get 1ms less lag from 1/360sec QFT, and then finding you're getting more lag from slower LCD GtG. Ha.

Also, remember QFT tricks (large Vertical Totals) don't work with unsynchronized VSYNC OFF -- it only reveals benefits when used with top-edge-of-visible-refresh-cycle framebuffer flipping (rather than Microsoft's usual method of bottom-edge-of-visible-refresh framebuffer flipping)

(I've seen this behaviour before in monitor overclocking -- pixel response can often suffer)
Totally off-topic but since you asked: I read more than a few hundreds different topics about performance tweaks and games with input lag, negative acceleration and micro-stuttering. DCP latency, Timer Resolution and all those bullshits. None of that gave me any real advantage and the game was always inconsistent with good and bad days even with high fps and relative good pc spec. After I discovered RTSS I skyrocket in the current league that I play here in Brazil for CSGO.
Excellent to know! RTSS is a very valuable tool when used correctly.
I'm Global but that something easy to achieve in my region but in this league I was 16 of total 20 and my k/d for the year fluctuated between 0.8 and 1.1. Now I have 1.48 and I'm 19 of 20 with more than 30 games on record playing with 160hz @ 160fps. I'm not sure if I prefer to cap the fps for perfect stability or set to scanrate of 350 but the game feels way faster with perfect recoil and mouse control. It could also be software related since the calculations and interpolation are better with a perfect frametime.
It's tough to get even further, because we've got a complex soup of unknown interactions that is hard to test for:
--> RTSS latency overheads
--> Panel scaling latency (sometimes doesn't exist, as scaling can be made lagless, albiet not always)
--> LCD GtG response speed changes from overclocked scanrates (from QFT)
--> Tradeoffs made (e.g. trading VSYNC OFF with RTSS-capped tearingless VSYNC OFF)
--> Mouse poll beatfrequencying / harmonic effects against the refresh rate / framerate.
--> Game design interacting. (Too high/too low caps can go wonky, aimfeel can go strange at 1000fps CS:GO)

My recommendations is to back off QFT margins a little bit and aim at 1/240sec QFT of any low-Hz. For example 1/240sec delivery of 160Hz or 200Hz. (Btw, calculating the frame delivery time is done by (Active Vertical Resolution) / (Horizontal Scan Rate) .... That's your frame delivery time). If your overdrive problems disappears, then that solves your problem, see if your aimfeel is better.

Also one possible issue is that a monitor may have bugs in its overdrive processing, using the wrong overdrive formula - Quick Frame Transport signals require overdrive to be done differently, e.g. 160Hz with 1/240sec QFT should use a 240Hz overdrive formula, not a 160Hz overdrive formula. So ghosting can still look worse and this can be frustrating if the overdrive adjustments (e.g. "OD GAIN") is not adjustable.

No guarantees obviously, but aren't we the etxreme of bleeding edge tweaking on Blur Busters? ;) We essentially implemented mainstream prosumer-tweakable Quick Frame Transport before HDMI Forum did (there's no shipping HDMI 2.1 consoles or computers that officially use Quick Frame Transport in an easy user-friendly manner -- yet it's part of HDMI 2.1 specification waiting for vendors to implement it fully, including properly into Windows drivers / Microsoft Windows). Pushing the limits of our monitors...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

MTSJ
Posts: 3
Joined: 11 Jun 2018, 18:21

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by MTSJ » 17 Dec 2018, 05:30

Is there any advantage in using Frametime limit over Framerate limit? I'm just wondering if there's a difference between like 20000 frametime limit vs 50 Framerate limit, or is it just same thing "backwards"?

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by RealNC » 17 Dec 2018, 07:03

MTSJ wrote:Is there any advantage in using Frametime limit over Framerate limit? I'm just wondering if there's a difference between like 20000 frametime limit vs 50 Framerate limit, or is it just same thing "backwards"?
It's the exact same. When you enter an FPS value, RTSS converts it to a frametime value. Recent RTSS versions simply expose a way to enter the frametime directly.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

amon.akira
Posts: 3
Joined: 30 Dec 2018, 17:03

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by amon.akira » 30 Dec 2018, 17:07

hi, dunno if someone can help me, but i got a problem with scanline sync, if i use it with a custom resolution, the game start with 30fps cap, to fix it i need to select first 1080p (native res) and then custom resolution, but is annoying do it each time.

any workaround ?

Notty_PT
Posts: 551
Joined: 09 Aug 2017, 02:50

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Notty_PT » 31 Dec 2018, 06:17

I don´t know about you, but I struggle capping framerates. After a short discussion/debate with RealNC about the subject, I decided to start capping framerate on my games. I did it on a 144hz monitor (because I think framerate cap is useless on 240hz). I will tell you about my experiences doing so. Be aware all testes were done without any GPU bottleneck, my gpu was used 50% at best.

- Black Ops 4

Capped in game to 144fps, and framerate is jumping from 150 to 160 all the time. Thought it would be an engine error, so I capped to 143, 142, 141, 140, up to 135, always same problem, framerate always between 140 and 160. Once I cap to 130fps it sticks between 120 and 130 and I´m wasting Hz on the monitor.

Tried to cap with RTSS and yes, I could finally keep the game at 144fps, but I ended up with an horizontal tearing line on the screen, wich is even more annoying. Also the input lag increased enough for me to notice it.

Also any kind of capping on this game added considerable input lag. Even at the same framerate, uncapped, it had less input lag than capped. Maybe engine specific?

- Quake Champions

Capped in game to 144fps, fps were around 141 to 144, so a pretty good cap, but got a MASSIVE input lag

Capped with RTSS to 144fps, most of the input lag was gone, but ended up with the usual horizontal tear line in the screen. Wich again, is awful, specially on fast flicks.


- Battlefield V

Capped in game to 144fps and it worked well, but I rarely have 144fps in that game anyway, even with 50% GPU usage, because CPU is more impotant and not even an overclocked i7 9700k can sustain constant 144fps in any situation on this game.

Also I noticed that if I uncap it, I have less input lag again, and has nothing to do with having higher framerate than 144. It simply adds input lag if I cap frames. Similar experience to Black Ops 4.

Overwatch

Capped in game to 144fps and it worked well, didn´t move from 144fps at all and no stutter, no tear. But... input lag.

RTSS Capping - same input lag, horizontal tear line, as usual.

Shadow of the Tomb Raider

Easy capping, and it worked well, But who cares? I play this game with a controller and I can even live with a 60hz Vsync on this type of games!

Batman AK, GTA V, Darksiders III, and other single player games

Same as Tomb Raider.

So in conclusion, for the games I play, mostly online shooters, I found no advantage in capping framerate, only disadvantages. Also I found that RTSS framerate cap is very bad due to the horizontal line. I even tried to cap to lower values, like 141, 140, 139, always ended up with the same result, the annoying line doesn´t go away and is terrible on mouse flicks.

On single player games the capping was nice, but I can live with vsync on those anyway. I don´t need ultra low input lag while looking to landscapes or climbing walls, and I defo don´t need more than 100fps on that type of games anyway, specially with a controller.

Now can someone explain me what´s the deal about capping framerates? Seriously my experience was awful! Need help! Thanks

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by jorimt » 31 Dec 2018, 10:21

Notty_PT wrote:Now can someone explain me what´s the deal about capping framerates? Seriously my experience was awful! Need help! Thanks
Were most of these tests done with no sync (V-SYNC off)? If so, you don't really need an FPS limit to reduce input lag in that scenario. FPS limiters are primarily for use with syncing methods enabled (double buffer V-SYNC, FreeSync, G-SYNC).

If you're playing with V-SYNC/FreeSync/G-SYNC completely off, you typically want no FPS limit (uncapped FPS) and the highest FPS possible for the lowest input lag.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

Notty_PT
Posts: 551
Joined: 09 Aug 2017, 02:50

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Notty_PT » 31 Dec 2018, 10:37

jorimt wrote:
Notty_PT wrote:Now can someone explain me what´s the deal about capping framerates? Seriously my experience was awful! Need help! Thanks
Were most of these tests done with no sync (V-SYNC off)? If so, you don't really need an FPS limit to reduce input lag in that scenario. FPS limiters are primarily for use with syncing methods enabled (double buffer V-SYNC, FreeSync, G-SYNC).

If you're playing with V-SYNC/FreeSync/G-SYNC completely off, you typically want no FPS limit (uncapped FPS) and the highest FPS possible for the lowest input lag.
Thank you very much for your reply! I only have FreeSync monitors and nvidia GPU! So you mean, V-Sync settings on the nvidia control panel? The one that shows Adaptive, Fast, etc? Should I use that + RTSS cap for max smoothness?

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by jorimt » 31 Dec 2018, 10:50

@Notty_PT

You only need an FPS cap to reduced input lag when you have V-SYNC enabled. If you have V-SYNC disabled, an FPS cap will typically not reduce input lag.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 31 Dec 2018, 12:51

Correct.

The Right Tool for The Right Job.

Frame rate cappinng is mainly useful for:

- Reduced lag with G-SYNC
- Resuced lag with FreeSync
- Reduced lag with VSYNC ON

Also:
- For game engine issues where game engine malfunctions at 1000fps, capping to 300 can be helpful with tha
- For tearline management, it can help you get tearingless VSYNC OFF if you correctly calibrate the tearline location (there's a way with Scanline capping to adjust the location of the tearline), but you have to follow the scanline instructions very closely. I can tell that you didn't adjust tearline location with custom Scanline settings. This tearingless VSYNC OFF mode can have less lag than VSYNC ON and look exactly the same (most of the time).

Capping is not going to reduce input lag of VSYNC OFF.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply