Blur Busters Forums

RealNC wrote: ↑

02 Apr 2026, 04:59

brownvim wrote: ↑

02 Apr 2026, 03:00

What are the best detailed settings for avoiding VSync while using 60 Hz mode on PC? I’ve tried both Special K and RTSS but I can’t get the tearing line right — I’m definitely doing something wrong.

Your best bet is enabling fast sync in NVCP (or through Special K, see below) when using latent sync (or RTSS scanline sync) at 60Hz. Or in any situation where FPS matches Hz. With fast sync, you should try and have the (now invisible tearline) somewhere in the middle of the screen. At 1440p, targeting scanline 500 or so should do the trick. This provides good latency and avoids motion hiccups. Do that before enabling fast sync so you can actually see the tearline.

Fast sync does a really nice job of preventing tearing without using actual vysnc on the frame presentation of the game, meaning it completely gets rid of vsync backpressure lag.

If you use the "delay bias" setting of latent sync to lower input lag, you can get a lot of hiccups with fast sync when GPU load is low (which can happen easily at 60FPS with fast GPUs.) This is because the GPU clocks down and the delay bias feature doesn't leave the GPU a lot of time to render the frame in very small amount of time. You can enable Reflex boost mode in SK in that case (just "nothing but boost" without actual Reflex will do, unless you do want Reflex as well) to force high GPU clocks at all times. Using delay bias like this can reduce input lag quite drastically at 60FPS. ("Delay bias" in general helps the most at lower refresh rates because the frame times are high so shaving off a percentage of that frame time means a large latency reduction.)

To enable fast sync in SK, right click the "g-sync" or "variable refresh rate" text at the top of SK's UI (where the resolution is shown) and check the fast sync checkbox, which will set it in the game's nvidia driver profile so you won't have to deal with NVCP or profile inspector. Restart the game.

Perfect, thanks so much. What a huge difference, down to 35ms with very smooth frame times.

Discorz wrote: ↑

30 Mar 2026, 02:50

- The poor diffusion of edge-lights raises the minimum MPRT floor. The lower the PW or higher the refresh rate, the more MPRT deviates from intended target. So what used to be a straight forward 25-2.5% duty cycle setting (PW 100-10) is now distorted and no longer scales consistently. This is of course assuming Nvidia here was going for the same 25-2.5% duty cycle as before.

I think I notice this effect now. It seems to explain the slight "milky haze" over motion I would describe this monitor as having compared to Dyac and CRT motion. This could also explain the odd effect I have noticed where the very top and bottom edges are clearer than the center.

If you have a pulsar monitor, check Pursuit camera and slide the ufos in fullscreen mode or use Strobe crosstalk.

Check the top and bottom vs. the center. When I say top and bottom, I really mean the very top and bottom edges. On 120hz ulmb pw10 1920px/sec, the ufo text is legible if it is nearly touching the monitor bezel. Move the ufos to the center, and the text is basically unreadable. Same settings on the strobe crosstalk test, the white rectangles are clearly separated at the very top and bottom, but are smeared together in the middle. It's not a night and day difference, but definitely noticeable.

The GtG vs MPRT test is also really good at showing this effect. Put it in fullscreen and pay attention to the thin lines on the bottom half. They are noticeably sharper where they touch the bezel compared to the center of the screen.

It's like the reverse effect of strobe crosstalk that you'd expect from other strobed LCDs. Normally you'd try to tune for a larger sweetspot in the middle while the top and bottom have the worst crosstalk (due to the panel transition times). What I see with my eyes is the opposite, there is very narrow spots at the very top and bottom where motion is clearer, while the middle is the blurriest. I assume this is because the backlight zones are simply getting diffused and somewhat light up areas that are supposed to be completely off, increasing the persistence. In other words, as the roll gets to one edge of the screen, the opposite edge is the farthest distance to a zone that is on. The middle, however, is only at most 1/2 the distance away from a lit up zone, so the MPRT deviates.

The 60hz mode completely avoids this issue, although I think we are all aware that the 60hz mode is somehow implemented differently from 120+ modes at this point.

Discorz wrote: ↑

24 Mar 2026, 15:18

We also got new ULMB 2 graphs (thank you Simon for providing these).

[viewtopic.php?t=15149&start=650#p123646]

This seems to settle things for the ULMB2 issues, then, does it not? Those 120+Hz graphs are horrific at lower pulse widths, but pristine at 60Hz!

The vast majority of the brightness drop seems to be coming from just lower voltage, rather than actually simply shortening the amount of time the backlight is on.

Tracing the data, the 60Hz PW 10 graph is doing the rising edge 5%-95% transition in ~0.26ms, and the falling edge in ~0.62ms. And it's fully reaching a max voltage of -12V.

How on Earth are the graphs for the higher refreshes so bad?! If both the up and down transitions can be essentially fully complete within 0.9ms, and we assume that's the fastest it can do these transitions, then sure, 360Hz may be bottlenecked. But the 120Hz graphs (and even 240Hz) should look way better than that, no?

Like, the 120Hz PW 10 has the rising and falling "edges" taking a full 2ms each, the voltage not even reaching -6V (much less -12V), with really jagged internal peaks and valleys... What is going on? This has to be a bug, right? I, like many of you, were shocked to see how good the 60Hz mode looked compared to the other modes, and with this data it definitely seems much more likely the backlight performance IMO than it is any sort of limitation on pixel transition times.

Hi everyone,

I wanted to ask a question regarding input lag at 60 Hz, specifically comparing strobe performance across different displays.

I’m currently using a ViewSonic XG2431, which I’ve tuned extensively on PC. Using a Leo Bodnar device, I measured around ~16.4 ms (center of the screen).

For console use (where I can’t apply CRU/QFT), I’m considering one of the newer Asus displays with ULMB2 / Pulsar, since they seem to handle 60 Hz strobing better out-of-the-box.

However, I’m unsure how the input lag really compares.

From what I’ve found:

* RTINGS reports around ~25 ms at 60 Hz
* Some LDAT measurements show ~24.4 ms

At the same time, I understand these methods are not directly comparable to Bodnar measurements.

From what I’ve been researching, RTINGS and LDAT tend to measure a more complete signal chain (including additional processing and scanout), whereas the Bodnar device measures a more limited portion of the pipeline (closer to signal-to-light at a specific screen position).

Because of that, I’ve seen suggestions that Bodnar results can be roughly ~½ frame lower at 60 Hz (around ~8 ms difference) compared to full pipeline measurements. If that approximation is valid, it could imply that the real-world difference between these displays might be smaller than it initially appears.

So my question is:

Is this a reasonable way to interpret the data, or is that approximation too simplistic?
Should I expect the Asus ULMB2 implementation to still have noticeably higher input lag in practice?
Or could it end up being closer to something like the XG2431 than RTINGS/LDAT numbers suggest?

If anyone has measured one of these Asus displays using a Bodnar or a comparable method, I’d really appreciate any real-world data.

Thanks in advance!

Angel Soler wrote: ↑

03 Apr 2026, 00:51

If anyone has measured one of these Asus displays using a Bodnar or a comparable method, I’d really appreciate any real-world data.

Edgintheledge tested it with some device earlier in the thread here:

viewtopic.php?t=15149&start=580#p123483

I would like to know the input lag on the 60hz mode too.

brownvim wrote: ↑

03 Apr 2026, 09:49

Angel Soler wrote: ↑

03 Apr 2026, 00:51

If anyone has measured one of these Asus displays using a Bodnar or a comparable method, I’d really appreciate any real-world data.

Edgintheledge tested it with some device earlier in the thread here:

viewtopic.php?t=15149&start=580#p123483

I would like to know the input lag on the 60hz mode too.

Thanks a lot for sharing that, I really appreciate it.

It does seem that with the current data we still can’t determine precisely what the input lag is at 60 Hz.

Hopefully someone will be able to measure it more directly — I’ll definitely keep an eye on it.

The lag feels really low when playing Super Mario Bros Wonder on the Switch 2 — I don’t notice any delay in the jumps at all.

Edgintheledge’s device looks perfect for measuring this. Hopefully he can test the 60 Hz ULMB2 mode (on and off) and give us some real numbers when he has time.

brownvim wrote: ↑

03 Apr 2026, 12:05

The lag feels really low when playing Super Mario Bros Wonder on the Switch 2 — I don’t notice any delay in the jumps at all.

Edgintheledge’s device looks perfect for measuring this. Hopefully he can test the 60 Hz ULMB2 mode (on and off) and give us some real numbers when he has time.

Thanks a lot for your contribution, I really appreciate it.

With a game like Mario, where jumps are very precise and timing is critical, any input lag would be noticeable immediately — so it’s great to read what you’ve just shared.

Hopefully Edgintheledge will be able to get proper 60 Hz results so we can finally clear up any remaining doubts.

I just seen this: https://youtu.be/OMhM58lK3m4?t=1016

brownvim wrote: ↑

03 Apr 2026, 14:24

I just seen this: https://youtu.be/OMhM58lK3m4?t=1016

Thanks a lot for your contribution and for sharing the video, I really appreciate it.

I’m actually familiar with that video — I’m Spanish as well, so it’s easy for me to follow. As far as I understand, the measurements there were done using Nvidia’s LDAT, and they seem to align closely with the results reported by RTINGS.

My main question is how those results would translate if measured using a Leo Bodnar device.

I’m asking this because I’m trying to compare it with the ViewSonic XG2431. I own this monitor and I have a Leo Bodnar tester, and I measured around ~16.4 ms in strobe mode (center of the screen).

However, I don’t have access to LDAT or the RTINGS methodology to measure the XG2431 under the same conditions, so I can’t make a direct comparison.

I understand that these measurement methods are not directly comparable, but what I’m trying to figure out is this:

If we measured the Asus display with a Leo Bodnar device, would we get a result closer to what I see on the XG2431 (~16 ms), or would it still be closer to the ~25 ms reported by RTINGS?

The reason I’m asking is that, from what I’ve researched, it seems that RTINGS measurements may include roughly an additional ~½ frame at 60 Hz (around ~8 ms) compared to Bodnar-style measurements, since they capture more of the signal chain.

So ideally, it would be great to hear from someone who understands both methodologies well, or from someone who can measure:

* the Asus display using a Bodnar (or similar), or
* the XG2431 using LDAT / RTINGS-style methods

Also, as far as I know, RTINGS didn’t measure the XG2431 in strobe mode — only in its non-strobed configuration — which makes the comparison even more difficult.

Thanks again for sharing the video, it’s very helpful.