frame delay 9

[Jimbo]

I have a non-overclocked Ryzen 3600, 16GB ram, and a radeon HD 6450 card.

I am running the latest groovyarcade (collab) with -nosleep on a 15Khz CRT.
I've not messed with the default audio settings.

With almost all (80s/90s) mame games I have tried, I can get up to frame delay 8 with no slowdown.
A very few games I have to lower it to 7 or 6, but the vast majority run full speed at fd 8 no problem.

Switching to frame delay 9 drastically slows things down to around 50-75%.

So my questions are: -

1) How much difference is there between fd 8 and fd 9.  Is it worth striving for fd 9 / would it be noticeable?

2) If it's worth the upgrade, are there any CPU benchmarks for this?  What CPU would I need to get fd 9 with no slowdown with the majority of 80s/90s games?

Cheers

[schmerzkaufen]

9 isn't necessarily the best for getting the best timings, I don't fully understand why but too much frame delay can be counter-productive with some games, you risk going over a certain limit where you lose the benefit of delaying the frame for the original intended purpose of 'catching' the moment the input is closest to the desired frame.

The reason why many games crawl at 9 then, I'm not sure if it's because it's going 'against the system' or just because the calculation required for that level demands an insanely fast CPU, much more than when at 8.
If we had a formula that explains it all it would be clearer, but that'd require benchmarks first, which as you could see don't exist.

Whatever, I doubt 9 will ever make a noticeable difference against 8 or even 7 for anyone who's at the very least a biological creature playing video games.
For our cyborg and android friends out there though I cannot speak.

The interest of having a fast CPU is not to 'always reach 9', but to not be limited to lower-tier frame_delay levels (like under 5) when playing heavier games.
(and also to not be forced to reduce it when using higher resolution displays and extras like HLSL, though in these cases the GPU's performance also matters, not just the CPU's)

[Josh128]

Do you guys adjust frame delay per game in the game ini files?  If not, is there a better way?

[schmerzkaufen]

Read the bloody GroovyMAME main release thread and die of shame for ignoring what's new. 

 

(It seems to be a common sickness within GroovyMAME users 'base', many dont read the main news thread and/or don't update their builds anytime often...therefore they don't know about the cool things when they happen.
Probably because people don't read forums anymore, especially the ones sometimes inactive-unresponsive for continuous days, weeks, months anyway)

[jimmer]

deltas at high FD number makes little difference to the player, but a lot to the computer.

FD is 10ths of a frame, so 1FD increment is eg 1.7ms which is not much of a gain.

Going from FD8 to FD9, means the computer time to compute has been cut from 2/10 to 1/10  so you need 2x the processing speed for that last FD step.   Note: FD8 is not twice as demanding as FD7  (it is 3/2=1.5 times )

vsyncoffset steals compute time from the PC, eg 10% vsyncoffset makes FD8 as demanding as FD9 without,  and FD8 twice as hard as FD7 now ( 3-1 / 2-1 ).

[schmerzkaufen]

I was told it's bad to make averages in miliseconds, because the principle is more like at e.g frame_delay 7 there will be possibility of seven occurences of actually ZERO lag inputs, and three occurences of 1 frame lag inputs.

Since 'when' a game polls inputs internally is only a guess, determining the most optimal frame_delay level so your inputs 'fall right' is also a guess, but anyone from experiencing (playing) should pretty much have found out that higher frame_delay is often better.

And we were also told that too high might mean missing the best 'time slot' for optimal input (don't know how to word that).
Yet I still don't think it happens too often that frame_delay is actually so high that we will miss the faster opportunity.

Thanks for your view put in figures BTW, in any case I bet this yet again highlights how important it is to not cheap out too much on the hardware for running GroovyMAME if we want the best results (well, especially for flat panels users, on which a powerful GPU is almost mandatory)

PS: note that an 'inverse' phenomenon exists. For example on a weak PC some games will crawl AF the moment I just turn frame_delay on.
BUT the perfomance will soar and stabilize to 100% (or close) when I pour in some vsync_offset using the slider.
e.g Darius Gaiden or Nebulas Ray
Some games even demand you to find and set the best possible vsync_offset position or they won't stabilize to their optimal performance period.
Thankfully with the slider this task has become easy, while perviously depending on one's hardware strenght it was either as easy...or a nearly impossible job.

[Josh128]

Just curious, how do you access the Vsync offset slider?  Using GroovyMAME .220.

Thanks

[schmerzkaufen]

 

[Calamity]

deltas at high FD number makes little difference to the player, but a lot to the computer.

Excellent post, jimmer.

I was told it's bad to make averages in miliseconds, because the principle is more like at e.g frame_delay 7 there will be possibility of seven occurences of actually ZERO lag inputs, and three occurences of 1 frame lag inputs.

This is still true.

What's bad about talking of latency in ms is that it's generally misunderstood. There's an old myth that says latency is inherent to emulation. According to this myth, there's always some latency tied to any input event due to the nature of emulation. This is false, as we contributed to prove years ago. 
Talking about latency in ms only contributes to perpetuate this myth.

Nevertheless, frame delay has a deterministic effect on the ms meaured by GILT, but this latency must not be understood as some delay that applies to all button presses that we just can't get rid off. It's not that! What this figure actually means is how close to the end of the frame (retrace) we can still catch an input event so that it takes action on then next frame.

E.g., frame delay 9 means that we can still catch inputs 1.66 ms before the retrace (that's the theory, it's a little bit worse on a real system). After that, no key press will pass through the window. This statistically happens in 10% of cases (a human player will spread button presses randomly along the frame period). For this 10%, we'll have a whole frame of latency. For the other 90%, we'll have zero latency: yes, zero, not even the encoder or usb overhead counts here, because the whole frame emulation is compressed in a fraction of its real emulated time.

That's how the "ms" figure must be understood.

PS: note that an 'inverse' phenomenon exists. For example on a weak PC some games will crawl AF the moment I just turn frame_delay on.
BUT the perfomance will soar and stabilize to 100% (or close) when I pour in some vsync_offset using the slider.
impossible job.

I've seen this too. In weak systems the scheduller appearently is not fast enough to get us to retrace start accurately so it's constantly missed, killing the performance. Setting vsync_offset to even an small value adds some room so the retrace start is found consistently.

[jimmer]

I was told it's bad to make averages in miliseconds, because the principle is more like at e.g frame_delay 7 there will be possibility of seven occurences of actually ZERO lag inputs, and three occurences of 1 frame lag inputs.

OK, so I disagree with this.

What the user experiences is a range of response times ranging from X+0 to X+17ms, with an average in the middle.  X depends on input device delay, Framedelay, vsyncoffset, game internal delays, screen internal processing time, scanout time to the point of interest on the screen, and probably some other things.

[schmerzkaufen]

^ I know about that but for the sake of newcomers lacking a long career in emulation video tech OCD, yet are interested in Groovy and who'd like an explanation on what it does for lag reduction, how/why use frame_delay, this is a good-enough one.

- how Groovy mitigates video and input lag;
" Groovy eliminates unnecessary vsync queue frames (without turning vsync off tho), and frame_delay allows your controller inputs to hit on the right frames, so assuming your PC is strong enough for high settings, almost all the lag is gone! core emulation is untouched so no impact on accuracy. don't believe it ? check the dedicated lag test *insert link* "

Period. Well, something in that spirit. That's a much better way to bust myths.

Now that Groovy's finally got an easily accessible and useable fix for tearing, is no time to introduce more scary migraine inducing elements that bring unneccessary strong questions.

RA wins droves of users over because unlike MAME & Co., although expla-doc's there on their website for display, they don't flood average user Joes with migraine-inducing nerdy techxplanation they will struggle reading or not at all if it's TL and full of tech slang, it tells them " hit the run-ahead pedal, lag gone! woot! "

Groovy's got enough little delicate parts remaining (like explaining vsync_offset_tolerance, or how to produce a log among other things), to justify keeping the stuff as short and clear as possible. Legit nerds need to learn how to use the language of commoners because the latter can't catch up to the former's knowledge and expectations in a lifetime.

[note: RA's prolly harder to use even as a basic pc emu software, the problem is not what's real but perception]

In regards to how to use the sliders now, your delta explanation is precious, but I can't manage to word it in a simpler way yet.

- how to use frame delay with the sliders;
" turn frame delay on using the slider, eliminate tearing with the vsync_offset slider, fiddle with the two until you get to the highest stable frame delay level your PC can afford for that game "

- how that affects performance;
"

Well one could write "get a strong PC scrub!" and done with that part. :p

[jimmer]

- how that affects performance;
"

Well one could write "get a strong PC scrub!" and done with that part. :p

The point of my deltas post was: It's not worth chasing high FD values because of diminishing returns.
I play my favourite game on FD7 with 10% vsync offest. To get to FD8 I would need to double my CPU speed for a gain of 1.7ms

Here's something everyone can try:  Can you tell the difference between say FD3 and FD7 ? If not, what's the point of trying for another step that's a quarter of that difference.

[Substring]

Just curious, how do you access the Vsync offset slider?  Using GroovyMAME .220.

Thanks

The slider is only available in Windows (well, it should appear for now in Linux, that's a mistake), and requires GM 224 at least.

[schmerzkaufen]

- how that affects performance;
"

Well one could write "get a strong PC scrub!" and done with that part. :p

The point of my deltas post was: It's not worth chasing high FD values because of diminishing returns.
I play my favourite game on FD7 with 10% vsync offest. To get to FD8 I would need to double my CPU speed for a gain of 1.7ms

Here's something everyone can try:  Can you tell the difference between say FD3 and FD7 ? If not, what's the point of trying for another step that's a quarter of that difference.

Well I consider 7 a high value. 

[rant]Even if the difference between 3 and 7 is indeed placebo for a lot of players, it's different depending on perspectives just like you said.
Diminishing returns will not necessarily be how some see it.

For someone who knows he's got a bit too 'long' a total lag chain because of weaknesses in his setup (a bit laggy display, bad contoller, whatever gets in the way not attended to by the emu itself), then the ability to achieve high frame_delay is welcome if only to eliminate a mere few more miliseconds. There, placebo aside a decently powerful system is a good thing anyways.

There's good reasons to tell people to generally not cheap out too much on the hardware, you know like for instance there's a kind of 'myth' or should I say common saying, that states a salvaged, flea-market-tier weak PC is enough for doing a mamecab as long as it fits the compatibility requirements.
But in the case of Groovy some may want to aim for heavy games, use super resolutions, or in particular a flat panel.
With each requirement an increase in CPU/GPU performance is required, not much of an increase for a CRT cab, but a BIG step up for flatties.
Somewhat veteran mamecab users often when they recommend bottom end hardware, maybe only think about their own low requirements they've been satisfied with, playing mostly long-time well-performing titles in MAME.

Having myself done quite a bit of support (attempted to at the very least) this past year and a half, I can very much tell that the healthier narrative to spread around, is definitely 'favour power and performance'.
That's what Haze or Calamity have been doing for long after all, and so, I've noticed popular recommendations for setup performance ability often go against theirs.

(Also, ain't some sound emulation become much heavier along some drivers like Capcom's, Taito, and recently several 80's oldies? I did sometimes read users who had a 'just enough for the job' PC in their mamecab who went like "well sh*t, I have updated MAME and now my antique mamecab PC crawls" :/ )

I'm not telling ppl to build a high-end PC by default either. Only case would be if they would try something extreme like high frame_delay over UHD.
For instance the Vega I currently have in my PC is absolutely totally overkill for a CRT setup of course, but might be recommendable for a QHD or 4K display.
(I have only tried up to 1200p myself so I cannot tell if such GPU tier is too much or not for 4K, just speculating. All I can say is that it does better over 1080~1200 than my previous RX 570 and even more so than the older R7 260X)
I haven't met anyone asking about Groovy setup recommendations for beyond 1080 yet tho.[/rant]

TL;DR I still think it's a healthier narrative to generally recommend a decently average to strong PC for GroovyMAME, rationally depending on the kind of desired setup of course, but in any case brush aside the typical cheap bottom-end CPU/GPU recommendations that slightly out-of-date users commonly give around.

The slider is only available in Windows (well, it should appear for now in Linux, that's a mistake), and requires GM 224 at least.

Oops, thought he meant windows, that's why I gave the rolling eyes.

[digitron]

Just want to say I'm really enjoying this discussion, thank you everyone.  Now for the dumb question, does the vsync offset do anything for crt users? I've always followed schmerzkaufen's advice for increasing the fd slider until I get frame loss (f11) and it works wonderfully.