Calamity wrote:With regards to Defender, I think I tried it with beam raced GroovyMAME and I couldn't make it react any sooner than without it. Maybe the emulation still can't reflect the original behaviour or it actually didn't behave that way.
Strobed (blur resuction) or non-strobed?
Beam racing doesn't help strobed modes much due to the all-at-once flash. Pixel visibility is delayed until scabout hits bottom edge (in total darkness) before backlight gets flashed.
Calamity wrote:So if I understood right, for NVidia-free systems, is BenQ/Zowie the only option for 60 Hz strobing? Are any of those monitors Freesync capable? Or more directly: is AMD Freesync + 60 Hz strobing possible? Sorry if it's a lame question.
No.
But one can instead beam-race the VBI in 1-frameslice beamracing (kind of an inputdelay + VRR) to minimize strobe lag. One can also use 240Hz BenQ (XL2546) + Large VBI + software BFI + 180Hz custom rez. This produces an okay 60Hz strobe, by blacking out 2 out of 3 hardware strobes, and avoids the burnin/color-degrade effect of usual software BFI. The even number (60fps@120Hz) plays havoc with LCD inversion circuit (the alternating positive/negative voltages every refresh) causing image retention. And plays havoc with 6-bit FRC causin color depth loss during 60fps@120Hz software BFI. This problem does not happen at 60fps@180Hz BFI using 2:1 Software BFI ratio. Which can be combined with hardware strobing to get effective low-lag 60Hz strobing with slightly better quality than 60fps@120Hz software BFI. And the bonus of 180Hz allows a slight Large Vertical Total, which, when used properly, provides a slight "Quick Frame Transport" effect, while also reducing strobe crosstalk further. So software BFI provides workaround for not having a low-enough hardware strobe frequency.
In other words, you do not necessarily need FreeSync to reduce input lag if you understand how to time the frame delivery in a correct input-delayed fashion + Large Vertical Total for the QFT (Quick Frame Transport) effect of faster scanouts + longer VBI.
Present() usually annoyingly flips at beginning of VBI so need RasterStatus.ScanLine to flip late in VBI to get low lag from a "Quick Frame Transport" effect. Basically, 1-frameslice beamracing (aka racing the end of VSYNC before scanline #1). VRR makes it super dirt easy (Present() API immediately begins scanning out, raster line starts incrementing instantly) ..... but you can do it without VRR by jumping through the correct hoops and timing Present() right at the end of a long VBI before raster begins incrementing.
Anyway, VRR-free quick frame transport (QFT) tricks, often require ToastyX tinkering or other Custom Resolution Utility, combined with developer programming to input-delay, render at last minute, and flip roght at the end of a long VBI.
Fastest QFT acceleration I have done is a VBI 3x the size of Active, transmitting a fixed 60Hz signal in a mere 1/240sec. But you can just do the 180Hz trick (for improved software BFI + hardware strobing) to get blur reduction with a hell lot less input lag, if willing to modify emulator source code for this.
This can get confusing. for a layperson, but not for CRU experts. (As long as the emulator has support for 60@180 BFI....not sure if GroovyMame supports odd BFI ratios). I know xash3d author successfully did it, see Area51 forum.
Again, VRR is easy way to reduce lag, but you can get same low lag as VRR with some advanced timing tweaks + extra programming + consistent frametimes + input delaying + last minute rendering + last minute framebuffer flipping.
Can be done. Just lots of hoops. That's what I am saying. Bonus is low lag
AND strobing if you are willing to expend the programming effort.
If not willing to expend programming effort to adapt an emulator for lowest possible "blurfree" lag (60fps@180Hz or 60fps@240fps via hardware strobing + software BFI), then just buy a VRR display. At least gives you the choice of VRR or strobing.
Other option is switch to NVIDIA and use the ULMB+GSYNC Hack. Must absolutely use microsecond accurate framepacing however, Present() at exact intervals, even 0.1ms deviations in framepacing cause noticeable flicker in VRR strobe hack. (0.1ms delay in 10ms frametime = 1% decrease in average total photons hitting human eyeballs with fixed length strobe pulses on a varying interval fashion) -- it is amazing how flickery the GSYNC+ULMB simultaneous Hack can be. Future VRR strobing needs AI to intelligently average out the average number of photons hitting eyeballs for any random human-timescale intervals. If you dare use simultaneous ULMB+GSYNC Hack, it can be amazing...it will be low lag but use an emulator with microsecond accurate frame pacing.
VRR = Super Easy Quick Frame Transport (QFT)
But you can do it without VRR if you are a programmer (large VT + inputdelay + late render + late VBI flip)
Anyway:
If cost is no budget and programmig time is no budget, here are your options:
Conclusion
Time-And-Cost No Object Possibilities
For Absolute Lowest Possible Strobed LCD Input Lag For Emulators
1. BenQ XL2546 DyAc (brighter than XL2540 and XL2740)
- Works on AMD and NVIDIA
- Can strobe at 180Hz and 240Hz too
- Can use software BFI to create 60Hz strobing in abscence of single-strobe
- Supports Large Vertical Totals for refresh rates under 240
- Worse colors than 60Hz hardware single strobe but 60@180 is better colors than 60@120
Alternate Monitors
- Can also use LG 27GK750 instead (does 240Hz strobe, not 180Hz strobe)
- Can also use Zowie XL2540 or XL2740 (same as XL2546, just dimmer)
Programming Considerations:
- Program emulator to support these software BFI ratios
- Program late-VBI Present() to utilize Large Vertical Totals as a lag-reducton mechanism (Quick Frame Transport)
Input Lag Savings
- 1/240sec QFT scanout + GtG time before strobe flash
- Extra unwanted hardware strobes blacked out via software BFI to limit to 60 strobes per second.
Motion Blur: Over 90% less motion blur than non-strobed 60fps@60Hz. CRT clarity!
Difficulty Rating: 9/10 because programmer needed
2. Any 240Hz GSYNC monitor
- Works on NVIDIA only
- Requires manual ULMB+GSYNC hack (lowest strobe lag) or ULMB 60Hz hack (higher lag)
- All 240Hz TN GSYNC monitors support the simultaneous ULMB+GSYNC hack and the ULMB 60Hz hack.
- Timing tweaks allow as short as 1/155sec scanout without disabling ULMB
Alternate Monitors
- Can also use overclockable 180Hz TN GSYNC or overclockable 165Hz IPS GSYNC (slightly slower QFT though)
Programming Considerations:
- Only requires a VRR-friendly emulator with microsecond accurate framepacing. (GroovyMAME already does, I think?)
- Much, much better color quality than using software BFI
Input Lag Savings
- 1/155sec QFT scanout + GtG time before strobe flash.
- True single strobe 60Hz at 1/155sec scanouts
Motion Blur: Over 90% less motion blur than non-strobed 60fps@60Hz. CRT clarity!
Difficulty Rating: 4/10, only requires switch to GSYNC