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
Site News

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


  

Author Topic: Input Lag - MAME iteration comparisons vs. the real thing?  (Read 58891 times)

0 Members and 1 Guest are viewing this topic.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #240 on: December 26, 2017, 11:04:46 am »
What if on the real arcade hardware the service menu program loop doesn't take a lot of cpu time and runs straight after vsync. Would this imply that GM with your setup (acquiring input late in the frame with no host lag) may actually prove to be lower latency than the real hardware? (Given that the real hardware uses a framebuffer and doesn't do any "racing the beam" of course!  :))

It's a possibility. I have access to a Magic Sword PCB... Although it's quite a hassle to get a measurement setup with this board. I might need to buy a SuperGun for it to be realistic.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #241 on: December 28, 2017, 04:53:46 am »
Would there be a way to accomodate for this in GM, could we just put in a "0.5" value for intscaley? (how will it handle 567/2?)

It was this discussed somewhere here a few months ago. Check G.2 here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=987#p987

Thanks, this is the way I normally use it. The problem with the MSX driver though is that it reports 467 lines and not 466, and the Amiga driver is 567 lines. Both uneven (they're derived from the interlaced mode for each system). So my worry would be that for example forcing the MSX driver on a progressive resolution of 233 (like in your guide) it may result in scaling artifacts as it's not an integer division of 467.

I used this firmware, but wasn't able to get 1 ms next-frame response. I sniffed the USB traffic with a Saleae Logic and realized it was very late in sending the updated button state, it also sent a complete state update at every USB host poll. I did a very preliminary modification (stripped out almost everything and increased the poll rate) and was able to get the same 1 ms next-frame response with it configured as a joystick.

Great, with that precision it seems safe to assume that there's no real latency difference between rawinput and directinput in MAME/GM.

Quote
I'm currently planning to do a replacement 1 ms controller for the HORI RAP that will work on the PS3 as well, using this firmware as base.

That sounds fantastic. Is it something you would be willing to share once finished? A Teensy with such firmware could possibly be a better alternative for joystick use than an I-PAC 2, since that runs at 4ms.

It's a possibility. I have access to a Magic Sword PCB... Although it's quite a hassle to get a measurement setup with this board. I might need to buy a SuperGun for it to be realistic.

Could provide a worthwhile addition though, especially in regards to our understanding. Nice game BTW  :).   I can even imagine that the real hardware always reads input at the beginning of the game loop, such that not only the test menu but also the game itself may prove to have considerable lower latency in GM (at fd9 with no host lag). 

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #242 on: December 28, 2017, 02:55:39 pm »
Hi Dr., is that Amiga test program available somewhere? I'd like to test it if I have a chance. GroovyMAME (by design) won't be able to paint in red the bottom of the screen, however it should be able to paint yellow right after vblank like the actual Amiga.

Hi Guys,

I came around doing the button test with GM.

Test setup Windows 10, Intel 7700K@4.5Ghz, HD6850, I-PAC 2, Joystick with LED attached, CRT Emudriver and GM0182.

"Button test" as previously attached and MAME "a600" driver. Tested both rasterline value 260 ("button 260") and rasterline value 26 ("button 26"). GM was run with framedelay 7 (the maximum for this driver on my setup to run flawless). Results converted to PAL Amiga frames (1 Amiga frame equals 20ms, equals 4.8 camera frames), average of 10 (random) button presses, filmed at 240fps. Counting is inclusive of frame where LED goes off, until where first yellow rasterlines are seen. Results are compared to exact same test on real Amiga hardware.

Real Amiga:
Button 26: 1.7 frames
Button 260: 0.8 frames

GM 0182 with framedelay 7:

Button 26: 2.1 frames
Button 260: 2.2 frames

Difference:
Button 26: 2.1 - 1.7 = 0.4 frames added latency
Button 260: 2.2 - 0.8 = 1.4 frames of added latency

Given that these tests were run with frame delay 7, we could substract 0,2 frame from the GM results for simulating framedelay 9. Which would leave:

Difference:
Button 26: 2.1 - 0.2 - 1.7 = 0.2 frames added latency
Button 260: 2.2 - 0.2 - 0.8 = 1.2 frames of added latency

What bugs me is that even with (hypothetical) framedelay 9, the rasterline "26" case doesn't even come on par with real hardware. It should on average show lower latency than real hardware when there's zero host delay and we're using a high framedelay value that puts input polling near the end of the frame, instead of the very beginning (rasterline 26).

What bugs me even more is that the rasterline "260" case results in over 1 frame of added latency , even when using (hypothetical) framedelay 9.

Just to have this out of the way: I'm definitely not disputing whether or not GM is capable of "next frame response", it is, as Intealls tests have shown beautifully.

It's just difficult to reconcile the above results. 

Is Windows 10 adding "host delay" back in versus Windows 7? (We're running full-screen application so it shouldn't!)
Is the I-PAC 2 adding more lag than it theoretically should?
Is there a host system lag on my January 2017 high-end hardware setup?
Etc.. etc..

Maybe I'm missing something obvious. I would really appreciate it if we can dig a bit deeper and see whether we can come with an explanation for these results.


u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 78
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #243 on: December 28, 2017, 04:28:58 pm »
It could be the overclocked CPU. I generally would not do such tests with such really high overclocking. At Mameworld we have seen similar strange results with a overclocked CPU in benchmark tests. Overclocking in that range, can introduce fluctuating and we are already in a delicate setup, where every ms. counts.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #244 on: December 28, 2017, 07:25:16 pm »
Dr.Venom, is it possible to see the code of your test program? I think I have an idea of what's going on.

Anyway, fractional frame latency values should be avoided in my opinion. It's better to count this in integer frame values intead of averaging to a fractional figure which obfuscates the meaning of the results.
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

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #245 on: December 29, 2017, 03:22:31 am »
Dr.Venom, is it possible to see the code of your test program? I think I have an idea of what's going on.

Hi Calamity. Itís not my program, it was made by Toni Wilen, the author of WinUAE.

If you look at the end of the following post, it has the button program attached including the asm source code.

http://eab.abime.net/showpost.php?p=1186341&postcount=1

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #246 on: December 29, 2017, 06:40:47 am »
I'm one of those idiots in the back of the class, so I shyly ask...

... Wouldn't real hardware/emulation clock discrepancy affect these kind of tests?

Mame emulation by default is not perfect in many cases. From my experience, for example, as I said sometime earlier... CPS games (maybe not all of them, I don't have access) run faster by default on Mame than on real hardware (putting clock at circa 70% it kinda get close to the real deal). So maybe it would affect input rate/polling?

*rest of the class "UUUUUUUUUUUUUHHHHHHHHHHHHHHH"*

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #247 on: December 29, 2017, 07:18:35 am »
Hi Calamity. Itís not my program, it was made by Toni Wilen, the author of WinUAE.

If you look at the end of the following post, it has the button program attached including the asm source code.

http://eab.abime.net/showpost.php?p=1186341&postcount=1

Hi Dr.Venom,

It's the first time I look at Motorola assembly but after some googling for the main opcodes I think I understand what it's doing. Just as I imagined, it is in fact a "race the beam" case, the one case that GroovyMAME can't match hardware at.

I can't elaborate it right now, but it's not a matter of GM being laggy when input is polled later in the frame, it's actually the Amiga which doesn't get input on time when input is polled early in the frame, so it matches GM more closely in that case. See what I mean? Polling input early (*in that particular race the beam case* ) approximates the experiment to a non-race the beam one.

I'll come back to this later when I have some time.

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

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #248 on: December 29, 2017, 08:38:17 pm »
Hi Calamity,

Thanks for looking into this.

I can't elaborate it right now, but it's not a matter of GM being laggy when input is polled later in the frame, it's actually the Amiga which doesn't get input on time when input is polled early in the frame

Would have been interesting to know a little bit more of your reasoning.

Not sure if I follow you because the Amiga hardware results seem to fit the expected values for the testcases on real hardware quite well.

Button 26 - expectation vs realization
Theoretical best case: button activated at line 25 (LED is filmed to go off), line 26 test: yes button pressed, program waits for vsync at line 310, turn screen yellow, first visible yellow line on camera comes then after blanking at rasterline 26. Lowest possible latency on real Amiga thus 313 lines or ~ 1 frame of latency

Worst case: button activated at line 27  (LED is filmed to go off), line 26 test is just missed, 1 frame will elaps before test at line 26 registers button press. So worst case is "best case + 1 frame" = 2 frames latency.

Latency results for a test with random button presses will be a randomization between best and worst case with an expected value of the average between the two, i.e. (1+2)/2 = 1.5 frames of latency. Any random button test should approach that value if the test is working correctly. Results with real Amiga was 1.7 frames for 10 button presses. Close enough an approximation with 10 button presses I think.

Button 260
Same reasoning for button 260 test on real Amiga:
Theoretical best case is button activated at line 259 (LED on camera off), registered at 260, wait to 310, turn yellow, first visible yellow lines on camera at line 26 in next frame. Lowest possible latency on real hardware for button 260 test is (52+26)/312 = 0.25 frame

Worst case is button activated at line 261 (LED on camera goes off), line 260 check just missed, 1 frame will elaps before 260 line test will register button press, etc. So worst case is "best case + 1 frame" = 1.25 frames.

Expected value of randomized button presses is thus randomization between best and worst or (0.25 + 1.25)/2 = 0.75 frames of latency. The measured result was 0.8 frames of latency for button 260 test on real hardware. Again close enough an approximation.

Based on this I expect the button test to be valid.

I'll come back to this later when I have some time.

That would be nice.

In any case, I've been doing an additional testcase without the button test. I did a game test that I also did previously for WinUAE. It's the Turrican II main character "jump" test. Real hardware versus GM with framedelay 7. Test is simply on startup of the game the main character jumping. Average of 10 button presses.

Turrican 2 "jump" test:
Real Amiga: 2.2 frames of latency, rounded 2 frames
GM fd7: 3.3 frames of latency, rounded 3 frames

So also in this test GM is lagging one frame versus real hardware. If I speak for myself, the pattern seems obvious. Button 26 is one frame short of where it should theoretically be. Button 260 is lagging by a frame, Turrican 2 is lagging by a frame.

To be honest I think I'm getting a bit tired with the topic. It happens I guess. So I'll leave it until someone else comes around to show something different for a change: hardware like response with Amiga emulation.

In any case, I guess now's a good time to return to some good old Arcade gaming with GM!

 

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #249 on: December 29, 2017, 11:00:03 pm »
Turrican 2 "jump" test:
Real Amiga: 2.2 frames of latency, rounded 2 frames
GM fd7: 3.3 frames of latency, rounded 3 frames

So also in this test GM is lagging one frame versus real hardware. If I speak for myself, the pattern seems obvious. Button 26 is one frame short of where it should theoretically be. Button 260 is lagging by a frame, Turrican 2 is lagging by a frame.

I tried to pause, press up, press shift+p and count the frames until the jump.

This is what holding up and pressing shift+p told me.

Code: [Select]
frame 0            1          2
      ^ nothing    ^ nothing  ^ jump

This is what the recording tells me:

Code: [Select]

frame -1                0         1         2
       ^ register input ^ nothing ^ nothing ^ jump

With the MAME model that Calamity's explained, I think this is as good as it gets?
« Last Edit: December 29, 2017, 11:22:26 pm by intealls »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #250 on: December 30, 2017, 07:46:45 am »
Hi Dr.Venom,

Sorry that I couldn't write about this before, but I'm working full time these days, have family commitments, and it takes too long to clarify my points one by one. Since you're in this stuff since the beginning sometimes I take the agreement on some concepts for granted while it may not be the case. Regardless, it would be nice if you had uploaded your video material somewhere for us to check, it makes it easier for us to see how you deduce your values rather than just posting your bare results (maybe you'd actually posted those and I just missed it, sorry).

Now, let's go straight to your results.

Impugnation to your latency computation method

If you have one chicken and I have no chicken, should we say we have 0.5 chicken each?

We will never reach an agreement if we don't use the same logic to measure latency. Your method is valid in the context of real hardware, but when applied to frame-based emulators it easily leads to fallacious conclusions.

For all the tests done in this thread, we've always counted full frames. So, we count how many frames it takes from led lit to action, counting a full frame for each vsync boundary, instead of real time translated to frames. Possiblities are:

0 -> action happens within current frame (red color in your Amiga sample). race-the-beam case, IMPOSSIBLE in MAME.
1 -> action happens in next frame (next frame response).
2 -> action happens in frame after next.
3 -> etc.

Let's see how this applies to your tests:

Button 26

Best case ->1 frame of latency (agree)
Worst case ->2 frames of latency (agree)
(1+2)/2 = 1.5 frames of latency (disagree)

Best case probability: 26/312 -> 8.33% (race-the-beam-like case*)
Worst case probability: (310-26)/312 -> 91.67% (non-race-the-beam-like case**)

* Above I defined the "race-the-beam" case when action happens in same frame (0 frames of latency). Now I'm writting "race-the-beam-like" case for something that takes 1 frame of latency. I'm not cheating. In your particular experiment, the yellow color happens if and only if the red color happens in the previous frame. Thus the yellow color depends on a previous race-the-beam case, it's a somewhat deferred race-the-beam case.

** this is why I said that "button 26" approximates to a non-race-the-beam experiment, because worst case is much more probable than best case. Now you'll disagree saying that theoretical probability is fifty fifty, which is backed by your tests, and this is the exact point I wanted to make: you are measuring lit led to action from whatever position it happens, while I'm stating that best case should only be considered valid if you can prove that the led is lit within the brief interval between vsync and line 26. That makes it much more unlikely than worst case.

Button 260

Best case-> 0.25 frames of latency (disagree) -> 1 vsync in the middle -> 1 frame
Worst case-> 1.25 frames of latency (disagree) ->  2 vsyncs in the middle -> 2 frames
(0.25 + 1.25)/2 = 0.75 frames of latency (disagree)

Best case probability: 260/312 -> 83.33% (race-the-beam-like case)
Worst case probability: (312-260)/312 -> 16.67% (non-race-the-beam-like case*)

The highest probability of best case now makes "button 260" experiment more close to a race-the-beam case, the one MAME can't replicate.

Impugnation to the "button" test program

While this test code is perfectly valid in my opinion it's not clear it's a valid generalization of how games work. I mean, definitely some games may work like that, but not necessarily all of them.

The main point to understand here is, this test code logic spreads across the whole 20 ms of a frame, and can poll input at any time during that time.

Now, because MAME emulation slices time in frames, it's impossible to replicate that behaviour exactly. Those 20 ms will now be compressed to barely 1 ms. It's irrelevant at which point the emulated program tries to poll input, because it can't communicate with the outer world in real time. MAME will poll input right before launching the emulation of next frame. The emulated program can poll input at line 26, 260, or whatever, but all it will do is read a frozen photograph of how inputs were at the time MAME polled them, which will more or less be at line 0 if you're using a high frame delay value.

So, take for instance the "button 260" test. Even if input happens within the first 260 lines, which is very likely to happen, MAME won't set the red color in that frame, ever. On the other hand, the Amiga will. This is expected. MAME can't replicate that with current desing.

However, MAME should be perfectly capable of registering input in next frame (yellow). But it will NOT. It will not because the specific test program we're using is sequential. It won't turn yellow if it has not turned red first. Both events are not independent.

My point is that a typical game loop wouldn't work that way. Of course it can do, and maybe Turrican 2 or all Amiga games do, but that'll be a surprise for me.

So, to put this in context, the "button" program, in pseudocode, looks like this:

Code: [Select]
button:
if right_button_pressed end

wait_line(target)
set_color(green)
wait_not_line(target)

set_color(black)

if not left_button_pressed goto button

set_color(red)

wait_line(0)

set_color(yelow)

wait_line(10)
wait_line(0)

goto button


What I mean is that if it was rewritten this way, you'd probably see GroovyMAME getting closer to actual hardware than with your current tests.

Code: [Select]
button:
if right_button_pressed end

if left_button_pressed set_color(yellow) else set_color(black)

wait_line(target)
set_color(green)
wait_not_line(target)

if left_button_pressed set_color(red)

wait_line(0)

goto button


Of course I might be completely wrong. But even so, chances are the issue would be more related to the way Amiga emulation is done than any mysterious hidden latency source.

EDIT: I've noticed that the "best/worst" case naming in my explanation is misleading. It made sense in your own explanation because best/worse case only referred to a single line, being the rest of cases somewhere in between. In my explanation however, I divide all cases in two groups with no gradation, so I should change "best/worse" by "before/after" or "success/fail" to be more accurate.
« Last Edit: December 30, 2017, 09:49:16 am by Calamity »
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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #251 on: January 22, 2018, 06:53:38 pm »
Retroarch's next frame response breakthrough (January 2018):

https://www.patreon.com/posts/next-frame-time-16390231

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 511
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #252 on: January 22, 2018, 08:23:06 pm »
Retroarch's next frame response breakthrough (January 2018):

https://www.patreon.com/posts/next-frame-time-16390231

Cool. 

Is framedelay in ms now?  (linked post  says framedelay 15)
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

Trnzaddict

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #253 on: January 22, 2018, 09:00:18 pm »
NVM.

After watching the video answered my own question.
« Last Edit: January 22, 2018, 09:14:48 pm by Trnzaddict »

buttersoft

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • Is running at 15kHz
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #254 on: January 22, 2018, 09:04:55 pm »
Retroarch's next frame response breakthrough (January 2018):

https://www.patreon.com/posts/next-frame-time-16390231

lol, welcome to GM 2014. I love how they're broadcasting those "accepted myths" as never having been solved before.

snappleman

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 13
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #255 on: January 27, 2018, 02:23:08 pm »
I don't know, even with optimal settings I've never been able to get GM to feel "right" against hardware, but with RA now I barely feel any difference. The only thing that's lacking from RA is switchres.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #256 on: March 14, 2018, 02:14:01 pm »
Ves, Doozer and I have done new latency measurements on current Linux (e.g. GroovyArcade 2018) and we can all confirm that latency-wise Linux is finally on par with Windows. This means you can achieve next frame response routinely as long as you use frame delay on a semidecent machine.

For instance, this video was recorded by Ves on a Core2Duo using -fd 7, latest GroovyArcade and a "minibox" as input device (keyboard encoder through ps-2), where you can see next frame response for some of the samples (depending on how late the input happens in previous frame): https://drive.google.com/open?id=1J3BJgFhvOdlKWU51PBqExSX4oxcLckXK

This was certainly NOT the case a few years ago when some of us performed the same tests (check previous pages in this thread). So there must have been some change in the kernel in the meantime making next frame response possible.

I think it's important to post about this so we're all updated to current knowledge of things.


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

Franko

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #257 on: March 17, 2018, 01:06:50 pm »
That's great news!

Why was frame_delay set to 7 instead of 9 though? Was it because of the CPU limitations?

Also, what about SDL page flipping that is supposed to add 2-3 frames of lag?
« Last Edit: March 17, 2018, 03:03:13 pm by Franko »

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 586
    • SCART Hunter
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #258 on: March 18, 2018, 02:54:13 am »
we can all confirm that latency-wise Linux is finally on par with Windows.

Excellent news!


Sent from my SM-G955F using Tapatalk

My MAME/SCART/CRT blog: SCART Hunter

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 351
  • Z80 ERROR
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #259 on: March 18, 2018, 03:11:31 am »
That's great news!

Why was frame_delay set to 7 instead of 9 though? Was it because of the CPU limitations?

Also, what about SDL page flipping that is supposed to add 2-3 frames of lag?

Indeed, frame_delay was set to 7 because of cpu limitation.

SDL page flipping can be achieved at each frame. It depends on how sdl_flip is called.
« Last Edit: March 18, 2018, 12:37:07 pm by Doozer »

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 78
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #260 on: March 18, 2018, 07:45:04 am »
I saw something on MAME github: https://github.com/mamedev/mame/issues/3344#issuecomment-373963782

That sounds really nice and promising and Calamity has already adapted some of this genius idea: https://forums.blurbusters.com/viewtopic.php?f=10&p=31750#p31750

I cant understand, why mamedevs are against such ideas and why they welcome new people in such a harsh way. Dont they see that? There are trillion other ways, to speak out concerns about someones ideas.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

buttersoft

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • Is running at 15kHz
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #261 on: March 18, 2018, 06:32:21 pm »
I saw something on MAME github: https://github.com/mamedev/mame/issues/3344#issuecomment-373963782

That sounds really nice and promising and Calamity has already adapted some of this genius idea: https://forums.blurbusters.com/viewtopic.php?f=10&p=31750#p31750

I cant understand, why mamedevs are against such ideas and why they welcome new people in such a harsh way. Don't they see that? There are trillion other ways, to speak out concerns about someones ideas.

Well, the MAME devs have their own priorities, and a workload no one could call small; put it down to that. I did find it interesting that they're planning to rasterise 3D games through the GPU. I wonder if that will speed up 3D.

EDIT: OTT
I've enabled keyboardprovider dinput in mame.ini, as i want to use an autohotkey script to feed some joytokey commmands to mame. Most the joystick commands (directions, buttons) are wired directly to mame (so... rawinput? They worked before i made the dinput change in mame.ini because dinput did not work) only the credit buttons go through autohotkey and dinput. Have i added lag of any sort by enabling keyboardprovider dinput in mame.ini?
« Last Edit: March 18, 2018, 09:56:51 pm by buttersoft »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #262 on: March 23, 2018, 01:57:39 pm »
Current frame response is finally possible!

https://youtu.be/egIEL7158N4

Demonstration of the experimental "frame slice" feature. Tear free rendering at 500 fps, 728x567i 49.890 Hz. Emulation of each frame is divided in 10 "slices", synchronized with the physical raster. Input data is polled and processed for each slice. On pressing F11, slices are shown with a color filter, revealing the (low) existing jitter.

Setup:
- Intel i7-4771 3.5 GHz, AMD Radeon R9 270, Windows 8.1 64 bits
- GroovyMAME 0.195 - Direct3D9ex - custom "frame slice" build
- JPAC wired to a microswitch and a 5V LED.

Testing Toni Wilen's "Button test" program for Amiga, emulated by GroovyMAME. This program polls input at a scanline specified by the user (green line). If input is detected, it colors all lines below the green line in red. After that, on the next frame, it colors all lines until the polling line in yellow.

See how, in many instances, the program reacts to input (LED) right in the same frame.

The second part of the video was recorded at 240 fps. The brightness was raised a bit in GroovyMAME to make the raster visible on the black background.

Thanks to Dr.Venom for inspiring this work.
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

Franko

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 3
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #263 on: March 24, 2018, 05:05:40 am »
Wow, just wow. You guys are awesome.

Do you plan on including the frame slice feature in 0.196?

Also, how much impact will it have for Linux builds? Or simply any builds relying on frame_delay instead of Direct3D9ex?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #264 on: March 24, 2018, 08:05:50 am »
Do you plan on including the frame slice feature in 0.196?

By now, I'm planning to keep it in a separate, experimental build. I've some concerns about this method. Not all drivers in MAME support this method nicely. The driver needs to support partial updates of its screens, otherwise graphical glitches happen. Moreover, I'd say the great majority of drivers won't show any difference latency-wise by using this method compared to frame delay. It's for the drivers that natively made beam chasing where this method makes a real difference (e.g. Amiga). Regardless, this is surely the most important breakthrough since frame delay.

Quote
Also, how much impact will it have for Linux builds? Or simply any builds relying on frame_delay instead of Direct3D9ex?

Mark, the guy from BlurBusters, is developing methods to do this without direct polling of scanlines (which is hard to do cleanly in Linux). This means the method should be cross-platform, eventually.
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

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 586
    • SCART Hunter
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #265 on: March 26, 2018, 04:13:26 am »
Current frame response is finally possible!

This is insane! Amazing development!!!

Sent from my SM-G955F using Tapatalk
My MAME/SCART/CRT blog: SCART Hunter

Ilitirit

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • no i'm not
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #266 on: March 26, 2018, 12:25:03 pm »
Is there a guide/tool one can use to determine the best framedelay setting?  AFAIU it seems it seems to be a matter of trial and error?

buttersoft

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • Is running at 15kHz
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #267 on: March 26, 2018, 08:14:38 pm »
Is there a guide/tool one can use to determine the best framedelay setting?  AFAIU it seems it seems to be a matter of trial and error?

There is, but i can't seem to dig it up. I see if i can find something when i get home from work.

Essentially, you run mame with -nothrottle and a log, and note how fast it's going in %. Or you can watch the screen and hit F10 and F11 to see the speed for yourself -
 some games have funny intros and whatnot, so this isn't a terrible idea. The slowest speed the game itself runs at is what you want to find. Then you take the framerate of that game, and work out how many ms it takes to generate each frame. 60fps is about 16.6ms. If your game can run at 800%, it will have time to generate 8 frames in that 16.6ms interval, where the game only needs 1, and that 1 is equivalent to ~2ms. However, you want a buffer, as some games get slowdown, so double that ~2ms to about 4.15ms. So, your PC needs 4.15ms to guarantee a frame gets drawn in time, which leaves us 12.45ms free time to play with. You then divide 16.6 by the free time of 12.45, and get 0.75 of the total time. Frame delay comes in ten discrete slices, so 0.75 rounds down to 7/10 = frame delay 7.

The calcs normally come out the same way for a given % speed as the framerate is usually around 60, so there's a quickref table. Credit to the original posters, whose names escape me at present. Note that these are very safe values, with a buffer built in as described.

(I think the commandline info below needs altering.)

Quote
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

From command line, 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.
« Last Edit: July 15, 2018, 11:44:15 pm by buttersoft »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #268 on: March 27, 2018, 08:58:14 am »
I'm wondering if something can be implemented straight into GroovyMAME where, the first time you run a game, it does a dry run to see how fast it can go and set frame_delay automatically based on the results. It would be needed just the first time because then the value would be stored in the game's .ini file. That would save a lot of trouble.

I also thought about a script which would run the tests on every ROM and automatically populate the games .ini files with the correct frame_delay.

I'm wondering, though, if frame_delay will become obsolete once the slices thing is made to work properly on all drivers.

buttersoft

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 689
  • Is running at 15kHz
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #269 on: March 27, 2018, 06:40:25 pm »
I'm wondering, though, if frame_delay will become obsolete once the slices thing is made to work properly on all drivers.

I think it does make frame delay obsolete, but i also think reworking all the drivers for MAME is going to be tricky. Some sort of option to enable/disable it for different drivers, and focus on a few bang-for-buck ones like cps1, cps2 neogeo, etc. might be the first step. Atm it's all still proof of concept though.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #270 on: March 28, 2018, 03:58:17 am »
I'm wondering if something can be implemented straight into GroovyMAME where, the first time you run a game, it does a dry run to see how fast it can go and set frame_delay automatically based on the results. It would be needed just the first time because then the value would be stored in the game's .ini file. That would save a lot of trouble.

I also thought about a script which would run the tests on every ROM and automatically populate the games .ini files with the correct frame_delay.

I'm wondering, though, if frame_delay will become obsolete once the slices thing is made to work properly on all drivers.

Intealls implemented that feature for his ASIO build, check this post.

There, you have to launch GM manually with the -bench option, then it gives a suggested value, which you can use later. I guess this could be arranged in an script.

My plan was to add an automatic frame delay option based on scanline timings, eventually. This is a very problematic feature because it will often fail to get a stable value for many drivers and it will be difficult for the user to interpret why it's failing.

Another (complementary?) approach would be adding a slider option to the ui, so it could be easily adjusted while in game, and then it would be stored to a cfg file.

Certainly, frame slice makes frame delay obsolete. However, as buttersoft pointed, it's not clear that the changes required for the individual drivers are going to be possible or accepted. In the coming days I plan to write a post explaining the feature and possibly make a list of drivers that are ready for this.

In the meantime, the idea I'd like to make clear is that frame slice will have exactly the same latency as frame delay has for the great majority of arcade drivers. It is only for a small fraction of drivers (those that originally did beam chasing) that frame slice will provide an actual improvement.
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #271 on: March 28, 2018, 06:13:19 am »
Intealls implemented that feature for his ASIO build, check this post.

...

Another (complementary?) approach would be adding a slider option to the ui, so it could be easily adjusted while in game, and then it would be stored to a cfg file.

My personal GM build already has these options. :)

The slider is infinitely useful. I can post the (small) diff tonight.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #272 on: March 28, 2018, 10:29:24 am »

My personal GM build already has these options. :)

The slider is infinitely useful. I can post the (small) diff tonight.

That'd be great. Hopefully I can add it for the new release on time.
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

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #273 on: March 28, 2018, 12:12:44 pm »
Wait, you're telling me that you can adjust frame delay *while* the game is running and have immediate feedback?

That would be awesome!

Seriously, those are exciting times for MAME enthusiasts, thanks for all your hard work.

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 511
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #274 on: March 28, 2018, 01:13:48 pm »
Intealls implemented that feature for his ASIO build, check this post.

...

Another (complementary?) approach would be adding a slider option to the ui, so it could be easily adjusted while in game, and then it would be stored to a cfg file.

My personal GM build already has these options. :)

The slider is infinitely useful. I can post the (small) diff tonight.

That would be great if you do. I've only framedelayed a few games so far but this would make it so easy.
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #275 on: March 28, 2018, 04:03:14 pm »
Here are the patches.

Calamity: Awesome work on the frame slicing! Super interesting stuff, as always.

The fdbench patch just outputs a statistic when run with -bench. Lets say you get 99.5% with fd 7, and 0.5% fd0. This probably means the game is safe to run at fd 6/7. But if you get 94.5% at fd7 and 5% on fd6, you should probably run the game at fd5/fd6. The slider makes it easy to tweak this. I haven't tested if the value is saved to config - I don't have that enabled.

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 511
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #276 on: March 29, 2018, 12:52:43 pm »
removed: long story about not being able to get the diff file to work, and having to change the files manually.
« Last Edit: March 29, 2018, 01:45:16 pm by jimmer »
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6090
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #277 on: March 29, 2018, 01:15:42 pm »
FYI, both patches are now included in GM 0.196. I had to apply then manually too.
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #278 on: March 29, 2018, 07:07:17 pm »
FYI, both patches are now included in GM 0.196. I had to apply then manually too.

Great!

Thanks for adding these. I tested them before posting with 0.195, they applied without problems there. Should have tried them with 0.196.

Remember that when using the frame delay benchmark, video and sound is not being output. This means that the benchmark will only report CPU time needed for emulation. Thus you should not be surprised if the benchmark tells you that fd9 is perfectly fine to use, but you might end up having to use fd8 for the benchmarked game. Also, for some drivers, speeds vary during gameplay. So when run with -bench 90 for instance, you might only capture a fraction of real world emulated frame times. What I'm trying to say is - the benchmark is only an indication. It's not a definitive answer to what setting is safe to use. The true setting would probably be gotten if you benchmark a recording of someone finishing the game and hitting all driver code paths. With that said, if you benchmark a couple of minutes (-bench 240) the benchmark mostly seems to give a useful value.

Edit: Just remembered, if you want to include video and sound in the benchmark, use 'mame64 game -nothrottle -nowaitvsync -nosyncrefresh -notriplebuffer -video d3d' and press ESC after a while.

There's a pretty big difference when including video and sound. This is on my main rig though, the differences are probably smaller when used on a proper GM CRT Emudriver setup.

Code: [Select]
y:\>mame64 akatana -nothrottle -nowaitvsync -nosyncrefresh -notriplebuffer -video d3d
Video chipset is not compatible.
SwitchRes: could not find a video mode that meets your specs
Frame delay/percentage: 6/0.14% 7/0.07% 8/14.91% 9/84.88%
Average speed: 1380.40% (378 seconds)

y:\>mame64 akatana -bench 240
Video chipset is not compatible.
SwitchRes: could not find a video mode that meets your specs
Frame delay/percentage: 6/0.11% 7/0.22% 8/3.89% 9/95.78%
Average speed: 1633.52% (239 seconds)
« Last Edit: March 29, 2018, 07:30:37 pm by intealls »

Ilitirit

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • no i'm not

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31