Frame Delay vs Low Latency?

[ABTmRw]

In the Groovy MAME ini settings, there are options for Frame Delay and Low Latency.  What's the point of both?  I thought low latency was the same as Frame Delay.

Like, if low latency is enabled, should frame delay be enabled?

Also, I like the look of crt-geom-deluxe...what's the best video option for that shader in terms of input lag, bgfx or opengl?

[schmerzkaufen]

It is something that was always 'part' of GroovyMAME and was recently added to baseline MAME by Calamity.
And since Groovy is based on the official MAME the option in return just appears in it too now.

Baseline MAME (as well as every other variant besides Groovy) was always 1 frame laggier because of the way it polled inputs, Groovy fixed that since back in 2012 or something, and that reached MAME only now.
Standalone, it is more like a fix for a longstanding baseline MAME flaw than a low latency feature.

Because it won't work with a handful of games they had to add the option so people can turn it on/off, but mamedev named it a boastful 'low latency' which it deserves only if you're in the case of using a FreeSync/G-Sync setup, in which case it will equal Groovy.

The naming was bound to confuse people, and sure it did as you can witness everywhere on the internet since then, people made a big deal of it because they did not understand that it wasn't as huge as the name hints if you don't own VRR.
Even more confused when if you tell them it was ported from Groovy but that it does not provide the same lag reduction.

With few game exceptions then (mostly 3D ones iirc) just leave it on, it is part of Groovy's architecture.

Also, I like the look of crt-geom-deluxe...what's the best video option for that shader in terms of input lag, bgfx or opengl?

Note that Groovy's features don't work with BGFX (or opengl) right now, because it still adds unwanted lag which is a problem.

Groovy is meant to work with D3D9ex only, which is does by default.
leave 'video' on 'auto'
If you change that then kiss Groovy's features goodbye.
You can still use HLSL if a CRT look is what you want.


EDIT: in fact Groovy is not like other MAME builds, you cannot change whatever you want without knowing in advance if you should or shouldn't, or you risk breaking its functions.
You cannot deviate from the guide: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=433
(@Recapnation IMO the guide should really specify 'don't change the video API period')
Like many aspects this is why the build is not very popular, you can achieve the greatest MAME experience with it, but it requires discipline, time, and proper hardware.
This is why I really insist people should seriously consider FreeSync/Gsync route instead, unless they like blood and tears.

[ABTmRw]

Thank you on the explanation on low latency!  Very helpful!

I was reading some of Groovy MAME release notes, in particular this one from 2016:

"- Dropped Direct3D 9ex support. LCD owners who used -video d3d9ex in order to enjoy reduced latency are suggested to move to -video bgfx, which now implements the same latency reduction method (SetMaximumFrameLatency)."

It seems to say that bgfx will work the same, please correct me if I'm wrong.

[schmerzkaufen]

That's old information, for a time Groovy indeed worked with BGFX but it came to light that this backend added more lag that the current features cannot defeat, so Calamity went back to D3D9ex.

I think the long term objective is to go back to BGFX, assuming it is even possible, but I have no idea about where development is at regarding the issue, you'll have to ask Calamity.

PS; here's a chart that was made with oomek's dedicated latency test:
https://postimg.cc/z35RCrQT
it's a bit out of date, substract 16ms from the blue columns (thanks to the introduction of 'low latency')
As you can see there's still no way Groovy with D3D9ex and frame_delay can be beat.

[ABTmRw]

Does this mean, frame delay does not work with bgfx?

Running video with bgfx and turning up frame delay does seem to have some effect in Groovy MAME.

[schmerzkaufen]

That's exactly what I said! no BGFX.
If you set video to BGFX you will get warnings from SwitchRes and turning frame_delay on ingame should even make the emulator crash.

Stick to D3D9ex (set 'monitor' to 'lcd', leave 'video' on 'auto', and use HLSL for crt look)


edit: if you don't see the warnings either you're missing something, like have you set 'monitor' to 'lcd' ?
OR you have modified things you shouldn't have, when in doubt start over from a clean mame.ini

edit2: you may be able to get around the BGFX crashes if you don't turn f_d on the fly using the slider, and use stored settings in cfg or ini instead, but don't be fooled that doesn't mean frame_delay is working as intended. You're not using vsync_offset yet not seeing any tearing? = it's not working as expected, plus you will experience crashes when moving the slider, and in any case you are playing with an additional amount of lag inherent to BGFX that you cannot eliminate with frame_delay (like 2~3 frames, no, actually even more though we'd have to update the lagtests to confirm exactly)
Just stick to D3D9ex (video auto) and you won't suffer any of these issues, Groovy is tuned for it.

edit3 @Recapnation: the guide seems to forget to mention the 'monitor' 'lcd' setting, well it does but at the very bottom where VRR is mentioned, and only as a command line term.

[ABTmRw]

Thank you for the detailed explanation!

Yeah, if I set frame delay in the UI with bgfx, MAME would crash.  If I set frame delay in the ini, it would APPEAR to work with bgfx.

So, I'll stick to D3D9ex for Tetris The Grand Master because input lag is super important there. 

[schmerzkaufen]

I sure miss crt-geom too, that shader is convenient because it hides the scanlines unevenness efficiently, and the crt look is reasonably convincing, its default settings are alright.

HLSL is not that much worse but you have to master it, there is hardly a default configuration that will fit most screens, editing the raster.ini manually takes patience.
But that is an entirely different topic.

Alternatively, if you don't want to bother with HLSL but enjoy a crisper default scaling with good colors, create an HORIZONT.INI, write the following in it:

Code: [Select]

filter                    1
prescale                  2And drop it into the 'ini' folder.
It's rather pixellated but the lighter smoothing keeps a crisp and vivid look I personally enjoy.

Don't forget to set filter back to 0 and prescale to 1 when/if you activate HLSL, otherwise the settings will clash scaling-wise.

[ABTmRw]

Thanks, I will definitely go with HLSL because crt emulation is the only way I'll play these games now!