Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: frame delay  (Read 644 times)

0 Members and 1 Guest are viewing this topic.

digitron

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:May 18, 2020, 12:55:52 am
frame delay
« on: April 06, 2020, 10:15:55 am »
Unable to use search, error "Unable to access the search daemon"

Is it best to just enable Frame Delay flag to 1 or is it still best to use tab > slider > frame delay 1-10 in-game until you get frame jitter/loss?
GM 219, Win7 64 Bit, i5-2400 @ 3.1Ghz, ATI HD 5750, 8GB RAM, 256GB SSD

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6893
  • Last login:Today at 02:17:36 pm
  • Quote me with care
Re: frame delay
« Reply #1 on: April 06, 2020, 10:24:08 am »
Always do it per-game, never in MAME ini, that was the purpose of the slider.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

digitron

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:May 18, 2020, 12:55:52 am
Re: frame delay
« Reply #2 on: April 06, 2020, 11:09:37 am »
Always do it per-game, never in MAME ini, that was the purpose of the slider.

Thanks Calamity! :)
GM 219, Win7 64 Bit, i5-2400 @ 3.1Ghz, ATI HD 5750, 8GB RAM, 256GB SSD

mrchrister

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 51
  • Last login:May 27, 2020, 01:14:51 pm
Re: frame delay
« Reply #3 on: April 06, 2020, 12:08:34 pm »
Is there any good tutorials on how to use frame delay? I assumed I wouldnt need to do anything because of using d3dex and portaudio...

buttersoft

  • Trade Count: (+1)
  • Full Member
  • ***
  • Online Online
  • Posts: 1000
  • Last login:Today at 09:22:20 pm
  • Is running at 15kHz
Re: frame delay
« Reply #4 on: April 06, 2020, 08:03:58 pm »
I keep losing the post, but i saved the content - credit to the OP not to me:

per game, from command line and not in a shortcut, run: groovymame.exe -v romname >romname.txt

You also add "-v" such that it will output some stats at exit.
 
So as an example, if I run outrun in MAME ("mame.exe outrun -nothrottle -v", let it run for some 30 seconds then quit, then on my machine it shows that it's able to run at 792% unthrottled . So for simplicitly I'll round this to 800%, or said differently 8 times as fast as the original hardware.

Now outrun originally runs at 60hz (and something), i.e. 60 fps. Dividing 1/60 gives us 0,016667 seconds per frame, which multiplied times 1000 says each frame is taking 16.67 milliseconds. Since mame runs it 8 times faster on average, it means on average a frame in mame takes 16.67/8=2.08 milliseconds. I'm stressing the "on average", as emulation is mostly not about averages: some frames may take longer to emulate than others. As a rule of thumb you may multiply the average frame emulate time by 2, i.e. the toughest frames to emulate take twice the average. So that brings us to 2 times 2.08 = 4.16 milliseconds that we at least need in each frame left to emulate the frame and still be in time for vblank.

So how large can frame_delay then be? Each frame takes 16.67ms of which 4.16ms need to be left for emulation. So 16.67ms - 4.16ms = 12.51ms is the maximum value at which we need to start the emulation. Now, frame_delay goes in steps of 1/10th a frame (with maximum setting 9). So in this case each higher value from 0 is adding 16.67/10 = 1.67ms.  The largest value for frame_delay that may be used is thus 12.51ms/1.67ms = 7(.47). So I could use a frame_delay of 7 for outrun on my machine (a 4.6Ghz 3770K) , going any higher to 8 or even 9 , would most surely lead to some (or a lot) emulated frames not being finished in time anymore for vblank, and thus skipped frames / loss of emulation accuracy / input latency added.

quickref table:
speed -> framedelay set to
0-222% -> 0
223-249% -> 1
250-285% -> 2
286-333% -> 3
334-399% -> 4
400-499% -> 5
500-666% -> 6
667-999% -> 7
1000-1999% -> 8
2000% and over -> 9

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 245
  • Last login:May 20, 2020, 07:55:58 am
    • Eiusdemmodi
Re: frame delay
« Reply #5 on: April 07, 2020, 06:40:15 am »
I should add that to the guide at Eiusdemmodi, though I'd like to know who the author is to credit him. Not sure that it's enough with letting the game just run for 30 s -- there're many instances when the CPU demand peaks at some points you won't see in the demo.


For completeness' sake, there's this too:

Quote
For usage of this feature with some particular emulated machines, it may be necessary to set frame_delay in the machinename.ini or drivername.ini file, even if it's only with the value of 1 (and then setting it higher through the Slider submenu). You'll notice this when you only set frame delay through the Sliders submenu and the next time running the emulation, the game/machine's speed is not correct.





schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 596
  • Last login:May 18, 2020, 03:19:01 pm
  • I want a large cream coffee
Re: frame delay
« Reply #6 on: April 07, 2020, 09:11:24 am »
I'd like to add two remarks:

1. -nothrottle observations notwithstanding, in cases I have noticed that some amount of vsync_offset may be necessary even prior to setting frame_delay.
For instance on my low-end laptop (1.9GHz dc, intel hd + nvidia mobile chip a.k.a 'optimus', 900p lcd, win 8.1), I can't use even frame delay 1 if I haven't set something like vsync_offset              400 in a specific machinename.ini or drivername.ini before thinking of touching the frame delay slider.
The uncommon aspect here is that it doesn't seem to make much if any difference whether the running emulated game/driver is resource-heavy or not, so in this case the speeds seen with -nothrottle don't seem useful.
Whether this is a feature-related or hardware-related phenomenon -or both- I don't know, but at the very least it is a life-saving tip to know about in situations such as with this low-end PC, because if lower frame_delay often isn't the best (1~3 max here for stability), there is still significant benefit in having the feature active even if just barely like this, the lowest f_d 1 bringing an immediate full frame reduction as shown in oomek's tests (and the remaining frame is the only 1 frame of lag left in the way, a great result considering a weak pc)

2. HLSL can make frame_delay completely unuseable in a situation such as described in my first point. That is; on a low end PC you may get some frame_delay working fine even if just barely, but both frame_delay and HLSL at the same time might be a no-no.
« Last Edit: April 07, 2020, 09:20:29 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

blackrabite

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 2
  • Last login:April 26, 2020, 09:11:24 am
  • I want to build my own arcade controls!
Re: frame delay
« Reply #7 on: April 25, 2020, 03:45:49 pm »
Heya, I've been enjoying GroovyMAME (thanks y'all!) for a couple years now on a CRT from a relatively old machine. I've been sitting on some questions of my own about cv1k and input response that I thought I'd post and see if anybody could educate me a little more.  I believe I've done the best I can to remove obstacles between my input and the emulator. frame_delay is presently set to 1 on all games to ensure that GPU pre-buffer is not used.

On non-cv1k, say, Dai Ou Jou Black Label, I can use the pause / frame advance test to see 2 frames of input lag, which I understand is accurate to the PCB. That is, I pause from neutral, hold an input, then advance the frames one at a time to see when I move. My count is 2 when movement occurs. Sweet!

On a cv1k such as Ibara Black Label, I use the same above test and count to 3 before movement occurs. So, a couple questions I have that I wasn't sure about:

What is the PCB input response for most cv1k games? I have always assumed it was two frames, and that three frame response is a driver-level limitation at the moment. What I've read from searching around is that further optimizations are probably not happening for the time being - which is all well and good, it's sweet they're even in the state they're in! - but is this the point that folks are using frame_delay to try and achieve faster input response? And if so, does this mean that, not considering other environmental factors (polling rate of controller, processing of video signal to monitor, etc), that there may be a specific value of frame_delay for each cv1k game in the current driver that users could be able to target to get consistent 2 frame response?

Can discussion of emulation/input performance on these be broken down into:
"For the current driver, frame_delay 'x' is needed to consistently to have 2-frame input response". And then folks can talk about what builds seem to be required for achieving that performance?

Anyway, the point is kind of moot for me right now, I have an old AMD Phenom II X4 945 (3.0 Ghz), so I'm totally satisfied with how everything runs for me now. If I decided to build a new machine to try and perform better on cv1k though, I wanted to ask the above questions to try and get a better understanding and have more insightful discussion. I think I most understand frame_delay (holding back processing of next frame as long as the PC can allow to give more time for user input to be processed while still leaving enough time for 100% accurate processing).

Thank you so much for reading and for any clarification on the subject.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6893
  • Last login:Today at 02:17:36 pm
  • Quote me with care
Re: frame delay
« Reply #8 on: April 26, 2020, 07:22:03 am »
Hi blackrabite,

The frame delay feature is not like RA's run ahead thing. The best you can get with frame delay is the live game reacting after the same frame count you'd get with the pause + step method.

For the same reason, there's nothing like a good frame delay value for a specific driver, that idea probably comes from the run ahead feature. The best frame delay value is always the highest you can set it in your specific computer until the emulation speed starts to get uneven. You will need different values than me. You may even need different values on your own hardware for different versions of GM.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 596
  • Last login:May 18, 2020, 03:19:01 pm
  • I want a large cream coffee
Re: frame delay
« Reply #9 on: April 26, 2020, 07:28:41 am »
There's the game program's normal delay resulting of the code as its programmers made it running on a specific hardware, it is what the driver emulates (supposedly most of the MAME drivers with few exceptions are accurate in that aspect)

Then specific to the emulator (and its settings) are inputs polling and buffering frames for vsync video output, both can add-up several frames in total to the game that is being emulated, so the total lag chain is A+B+C (game+polling+videosync. not sure if audio can play a role here or its delay is a separate issue)

GroovyMAME takes care of B and C, not A which remains untouched for obvious accuracy purposes, if you want to reduce the game's own inherent lag you have to use a feature like run-ahead in RetroArch, or hacked drivers in ShmupMAME.
(though with those depending on the settings related to B and C, you may or may not obtain an actually lower lag chain, most times users have to sacrifice vsync to effectively achieve that. Groovy can't touch A but it can preserve vsync while eliminating B+C)

Anyway in GM frame delay can almost completely eliminate B and C, so ideally the only delay left is that of the original game.
In straightforward cases, level 1 leaves 1 frame on top of A, and the higher you move framedelay, the less often that last frame will actually be a thing in your way, in other words increasing framedelay increases occurences of that last undesirable frame not being present when you input: therefore no lag left, it's like playing the pcb.

In practice though the higher framedelay level is not always the ideal to achieve this because we don't know when the emulated game's program itself polls, a too high framedelay can even be counter-productive.
In my experience the best results are often found somewhere 6~7~8, while 9 is rarely achievable anyway in particular with resource-intensive games.

As for variables in lag readings, I think they can depend on the reading method, the general settings of Groovy and of course framedelay level, but also I believe it can vary between games even if they're running from a same driver, either because the code is slightly different, or that it varies within the game at different moments/places (though I don't imagine by more than 1 frame, in comparison some modern games today can show variations of several frames during gameplay, ew). You could also think of the hardware factor, like controller pcbs or OS-software related, etc.

EDIT: oops didn't see Calamity posted before me. Well.

PS: and yes it's good to remind the pause + frame count method only shows the lag from A (or A+B ? in any case it's no indication of how much lag there actually is in total)
« Last Edit: April 26, 2020, 07:33:00 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

blackrabite

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 2
  • Last login:April 26, 2020, 09:11:24 am
  • I want to build my own arcade controls!
Re: frame delay
« Reply #10 on: April 26, 2020, 08:31:52 am »
Thank you both for your thorough replies. I am not interested in run-ahead as accuracy to the PCB is a priority. Your responses refined my understanding, based off the way it was broken down:

Total user experience of input to response is a composite of:
A: Driver level emulation of PCB
B: Polling of user inputs
C: buffering for video output

Frame delay helps mitigate B the most, it tries to push back emulation of the next frame for however many tenths of a frame the setting is configured at. This is to give more time for the input to not "miss the bus" and be pushed back to the later frame.

I have a weak CPU anyway so I can't really make too much use of frame_delay at the moment, but it's really an incredible feature as it is. Much appreciated. And thanks Calamity for maintaining this project, have had many awesome nights sharing and enjoying this setup with friends.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 596
  • Last login:May 18, 2020, 03:19:01 pm
  • I want a large cream coffee
Re: frame delay
« Reply #11 on: April 26, 2020, 12:09:50 pm »
Well, ackthually  ;D

- Using Groovy on default settings earns you something like 2 frames vs. baseline MAME.
- Turning frame_delay on (just 1) cuts another full one.
- Increasing it until hitting a stability limit like Calamity recommends, can cut a final one though at some cpu/gpu cost.

So in that light the simple act of turning frame_delay on has the higher lag-reduction-for-resource-consumption benefit ratio, and in that particular moment it seems to act on C, not B (don't ask me the technical reasons lol)
I love nitpicking.  8)




Additional rant not directly related to your post/case, blackrabite: I've always thought if there was a single vsync_offset value 'kinda working' for everything while frame_delay is fixed on 1, we could almost have packaged a fully pre-configured 'click-and-play' Groovy for lambda pc-with-lcd or pc-crt-but-no-emudrivers users in a hurry for reduced lag and who don't want to read guides nor fine-tune for hours.
Unfortunately it is not the case, as even for such a basic use on an average monitor, it is necessary to learn how to use vsync_offset in combination with frame_delay, and that's the main reason why Groovy is not popular beyond a sub-niche within what's an already niche arcade-retro community.
While for the majority -at least on the psychological level- just firing RetroArch and stepping the run-ahead pedal is a no-brainer solution.
Accuracy issues and questionable effectiveness over the total lag chain are non-concerns for people who only barely scratched the surface of that complex topic. Run-ahead «works» after all, placebos do too, and we're living right in the vortex of the 'popular is right, popular is true, popular is justice' culture era.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15