andrelip wrote:Thanks for the suggestion. This feature is amazing!
1) I'm, putting the scanline at a given height above the aim. Do that mean that I'm receiving the lowest input lag possible in that region due to the scanline gradient?
<Expert User Tweaking Only>
Yes, frameslices are a latency gradient with the lowest lag at the top edge of frameslice (right above all tearlines). So you made an excellent call putting the crosshairs near the top edge of your frameslice.
If you have enough framerate overhead, try double framerate with both SyncScanline0 and SyncScanline1 .... One of them aligned between refresh cycles and the other one of them right above your crosshairs.
andrelip wrote:Do that region have a lower latency probability at a moderate frequency (180hz por example) than if I had unlocked fps at my 240hz display (reaching 250~300 fps)? My theory is that having the scanline perfectly placed at a slightly lower frequency should win most of the times against the random gradient of a higher rate in the specific region.
There's a small frame-capping overhead inherent in RTSS. So it may be lag-neutral compared to VSYNC OFF in the best case scenario. I think it approximately cancels each other out. However, the improved fluidity can improve aiming anyway. You have to give it a try and see if it helps!
Simply using framerate-capped FreeSync (e.g. ~237fps at 240Hz) is a lot easier than using RTSS scanline sync, but give both a try and see how the latency-feel works for you.
andrelip wrote:2) On my Alienware AW2518HF (240 hz) I could set my 1280x960@200hz to use a total height based on 360hz pixel clock. It has no frameskip but in another post you said that most of the 240hz monitors use buffers to send at 240hz speed. How can I know if that is the case here?
It is very model-dependent. But if you worry about this, you can simply use large vertical totals (large blanking intervals) to deliver your 200Hz refresh cycles in 1/240sec. If you transmit your scanlines at max pixel clock (max scanrate) the 240Hz FreeSync monitors tends to skips pre-buffering pixel rows. The buffering necessarily occurs only if pixel rows are raster-scanned-out over the video cable (DisplayPort, HDMI, whatever) slower than the monitor's motherboard is refreshing-out to the LCD. So it has to pre-buffer enough pixel rows before it flushes out to a full-240Hz-velocity scanout of the panel. (That's why most 2017-era and 2018-era 240Hz monitors are bad for 60Hz console gaming at the moment) All gaming LCD displays use a top-to-bottom refreshing sequence (as seen high speed videos on Blur Busters). So if your video cable scanout velocity (Horizontal Scanrate in Custom Resolution) is the same as 240Hz, then it's pretty much in sync with the LCD panel scanout.
Just max-out your pixel clock and use the same Horizontal Scanrate of your 240Hz mode, and any lower-Hz PC mode (with Large Vertical Total) just behaves as a "Quick Frame Transport" mode. All refresh cycles would scanout in 1/240sec (4.16ms).
Remember when doing Custom Resolution tweaking (NVIDIA Custom Resolution)
1. Display your 240Hz mode
2. Write down all Horizontal numbers (Front Porch, Sync, Back Porch, Total, Scanrate)
3. Write down all Vertical numbers
4. Write down your Pixel Clock number.
Now, when creating a new lower-Hz custom resolution that becomes a Quick Frame Transport mode (Might not be better than 240Hz frame-capped FreeSync, but you can give it a spin), you have to:
1. Use "Manual" for custom resolution
2. Preserve all horizontal numbers _exactly_
3. Preserve all your vertical numbers except Back Porch and Vertical Total (if you don't have a Back Porch number, don't worry -- it's embedded in Vertical Total)
4. Preserve your dotclock
5. As you lower your refresh rate, increase your Vertical Total.
For example, if you're using VT1152 at 240Hz, then you need to exactly double the VT for exactly half Hz -- VT2304 for 120Hz (for 2x QFT acceleration factor). Or exactly quadruple, VT4608 for exactly one-quarter Hz, ala 60Hz (4x QFT acceleration factor).
Remember...get exactly the same Horizontal Total, same Horizontal Scanrate, and Same Pixel Clock -- the number must be exactly the same as a FreeSync-enabled 240Hz mode even if you are disabling FreeSync. FreeSync works via variable-size vertical totals to space out refresh intervals, so you're piggybacking on that native capability to achieve fixed-hz Quick Frame Transport (QFT) for lower refresh rates, for the use cases that you don't want VRR for.
If your monitor supports large vertical totals at 240Hz, you might get up to a 5x QFT acceleration factor for 60Hz (60Hz refresh cycles transmitting over the cable in only 3.5 milliseconds!) before you start hitting DisplayPort speed limitations.
</Expert User Tweaking Only>
If you do any of the above and get any significant improvements in lagfeel, please post. I'm interested in your experiences.