Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Is groovymame with 120fps BFI still a good option ?

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!

Re: Is groovymame with 120fps BFI still a good option ?

Postby Calamity » 15 May 2018, 15:39

Jimmer is an old member of BYOAC, we know each other.

Well yes, the idea is that run ahead is effective for games that have internal lag.

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.

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.
Calamity
 
Posts: 24
Joined: 17 Mar 2018, 10:36

Re: Is groovymame with 120fps BFI still a good option ?

Postby jimmer » 15 May 2018, 17:44

I'm committed to LCD.

For my ultimate Defender emulation I'm pretty sure now that I need to emulate the real behaviour and poll inputs every 8ms. And maybe I need this raster position info /buffer swapping technique so I can write to the bottom half of the screen while the top half is being drawn.

Then I think the emulator+LCD can match ArcadePCB+CRT response. Because roughly groovymame framedelay gains about 5ms of input response which makes up for the 5ms of display lag.
jimmer
 
Posts: 9
Joined: 14 May 2018, 06:48

Re: Is groovymame with 120fps BFI still a good option ?

Postby jimmer » 15 May 2018, 17:52

But I'm still hoping there is a simple way (eg using 120fps monitor) to get the 60fps images being produced to display in less than 16ms. We just need to break the connection between the frame rate and transmission duration.

I suppose it still needs a rewrite of something (maybe a display driver?). We've got displayPort that could squirt the signal in less than 1ms, and we've got 240fps monitors that could get the whole screen drawn in 4ms (plus a bit of display lag) I just need those to work with the 60fps images being produced.
jimmer
 
Posts: 9
Joined: 14 May 2018, 06:48

Re: Is groovymame with 120fps BFI still a good option ?

Postby Chief Blur Buster » 15 May 2018, 18:36

Yes, 240Hz VRR + 60fps cap is the lowest emulator lag you can get today on LCD without RunAhead and without tearing.

That said, same amount of motion blur as 60fps at 60Hz.

For top edge on some of my displays (begin of display scanout), I certainly can get API to photons in 3ms. That's mostly cable transmission lag + GtG lag.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4695
Joined: 05 Dec 2013, 15:44

Re: Is groovymame with 120fps BFI still a good option ?

Postby Chief Blur Buster » 15 May 2018, 18:47

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
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4695
Joined: 05 Dec 2013, 15:44

Re: Is groovymame with 120fps BFI still a good option ?

Postby jimmer » 16 May 2018, 09:28

Chief Blur Buster wrote:For top edge on some of my displays (begin of display scanout), I certainly can get API to photons in 3ms. That's mostly cable transmission lag + GtG lag.

Oh God, don't say things like that, you'll wake the audiophiles up.
jimmer
 
Posts: 9
Joined: 14 May 2018, 06:48

Re: Is groovymame with 120fps BFI still a good option ?

Postby jimmer » 16 May 2018, 09:37

Chief Blur Buster wrote:Yes, 240Hz VRR + 60fps cap is the lowest emulator lag you can get today on LCD without RunAhead and without tearing.

That said, same amount of motion blur as 60fps at 60Hz.


ah yes, I forgot to say that no tearing is an absolute requirement for me.

Also I'm more interested in average or worst case performance than the headline best case. And that's only partly because Defender action takes place at the bottom pf the screen.

So is "240Hz VRR + 60fps cap " something I can do now with current groovymame and the right interconnect standard and monitor? what I mean is does it produce a complete lit screen in less than eg 10ms rather than the 20ms I'm used to ?

Here's a diagram showing how I understand things and what I'm hoping for. I've incorporated some new to me terminology eg scan out, hopefully correctly.

LAG3_fastscanout.png
LAG3_fastscanout.png (67.97 KiB) Viewed 105 times


Hopefully the fact that the performance is better than CRT (and the picture quality closer to CRT) might interest Calamity in making the necessary changes.
jimmer
 
Posts: 9
Joined: 14 May 2018, 06:48

Re: Is groovymame with 120fps BFI still a good option ?

Postby Chief Blur Buster » 16 May 2018, 14:01

All the modes that I have given are tearingless for the "cost-and-time-no-object" modes.

You need to create separate diagrams for strobed and non-strobed. The lag gradient is different in the screen's Y dimension.

-- "Scanout" equals "pixels lit" for non-strobed (+GtG response). They're not separate for CRT and lagless LCDs.
While
-- "Pixel lit" occurs practically after "scanout" for strobed.

Excluding cable-lag and GtG-lag, the numbers are:

LCD Non-strobed 60fps @ 60Hz (non-QFT), heavy motion blurring
Top: Add +0ms
Center: Add +8ms
Bottom: Add +16ms
Blur Benchmark: 1/60sec = 16.7ms Persistence (MPRT, not GtG).

LCD Strobed 60fps @ 60Hz (non-QFT), zero blur (CRT-clarity)
Top: Add +16ms
Center: Add +16ms
Bottom: Add +16ms
Blur Benchmark: 1ms strobe flash = 1ms Persistence (MPRT, not GtG)

LCD Non-strobed 60fps @ 1/240sec (e.g. Option 1 of my cost-no-object scenario), heavy motion blurring
Top: Add +0ms
Center: Add +2ms
Bottom: Add +4ms
Blur Benchmark: 1/60sec = 16.7ms Persistence (MPRT, not GtG)

Strobed 60fps @ 240Hz (when maximizing QFT effect), zero blur (CRT-clarity)
Top: Add +4ms
Center: Add +4ms
Bottom: Add +4ms
Blur Benchmark: 1ms strobe flash = 1ms Persistence (MPRT, not GtG)

(Excludes GtG time)

Anyway, do you now understand how the input lag gradients change during strobed modes? Because you see "scanout" equals "pixel lit" because the scanout is realtime emitting photons (just like a CRT), as the display is scanning top to bottom. Cable lag adds about 1ms and GtG lag adds about 1-2ms. So add both numbers equally to top edge of screen, center of screen, and bottom edge of screen.

So...question is....Do you want strobing or not? Reducing motion blur by over 10x? Getting less than one-tenth the blur of a typical 60Hz LCD? There's a lag penalty for that, but the quick frame delivery effect can massively compensate for that, as you can see above in the "60fps at 60Hz"

Once you decide you want strobing or not, then factor this math into your next diagram. The Y-axis lag gradient of a display changes with scanout velocity, as well as changes with global presentation (whole-flash) versus sequential presentation (CRT scanning).

Summary:
* CRT = Sequential presentation (scanout equal photons)
* Non-strobed LCD = Sequential presentation (scanout+GtG equals photons) (essentially GtG is just simply a time offset on sequential presentation)
* Strobed LCD = Global presentation (scanout after panel refresh)
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4695
Joined: 05 Dec 2013, 15:44

Re: Is groovymame with 120fps BFI still a good option ?

Postby jimmer » 16 May 2018, 15:01

Yes I understand all those examples, thanks.

I forgot about strobe when I was doing the diagram, here's my latest attempt. I've shown the transmit taking 4ms now with the scanout running in parallel with a slight lag. Maybe I can remove VsyncOffset from my pre-vysnc times, I don't understand well enough to know if it's part of the new scheme.

LAG3_fastscanoutv2.png
LAG3_fastscanoutv2.png (64.91 KiB) Viewed 67 times


I agree with you on the blur reduction, in the 240Hz examples I am happy to sacrifice 2ms response for 90% blur reduction. In a 60Hz case I would have to see the blur reduction and feel the lag to see if it was worth 8ms average.


I'm not even sure that I'm unhappy with my current system. I really need to redo my back to back testing against ArcadePCD+CRT. What's prompted this research is that I switched to an IPS panel for better side viewing angles when rotated to vertical orientation, but I noticed the lag and blur seemed worse than my older TN panel. Then I started on the quest for just how good could it be...
Last edited by jimmer on 16 May 2018, 17:02, edited 4 times in total.
jimmer
 
Posts: 9
Joined: 14 May 2018, 06:48

Re: Is groovymame with 120fps BFI still a good option ?

Postby Calamity » 16 May 2018, 15:58

Thanks for the superinformative post.

Chief Blur Buster wrote: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.


This should be relatively easy to do in GM. What I need to understand is, do you mean to do this sequence at 240 Hz:

frame_1, frame_1, frame_1, black frame, frame_2, frame_2, frame_2, black frame, ...
Calamity
 
Posts: 24
Joined: 17 Mar 2018, 10:36

PreviousNext

Return to Software Developers / Low-Lag Code / Game Programming

Who is online

Users browsing this forum: No registered users and 0 guests

cron