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 33229 times)

0 Members and 1 Guest are viewing this topic.

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Input Lag - MAME iteration comparisons vs. the real thing?
« on: July 01, 2013, 12:28:58 pm »
Guys

Minimizing input lag is HUGE (as many already know) especially when it comes to very time sensitive game types like shmups and fighters.  The "tricks" used by ShmupMAME has garnered it the "unofficial" non-actual-hardware choice method of playing the game Super Street Fighter II Turbo.  In fact, some work had been done to draw direct comparisons to actual hardware:

http://forums.shoryuken.com/discussion/178437/official-shmupmame-super-turbo-thread/p1

Has anything like this ever been done with GroovyMAME?  From an overall library availability perspective, GroovyMAME is hugely preferable.  I'm just VERY curious how close to actual hardware GroovyMAME get's.  I'm already playing it on a CRT with:


hlsl_enable              0   (I run 480p into my CRT but use a miniSLG to create scanlines - looks terrific this way).
triplebuffer               0
waitvsync                 0
frame_delay             1

To try and do everything I can to minimize input lag....but I don't have the necessary measurement equipment to tell me how close I'm getting to the "real thing". 

Would love to hear any input on this topic.

Thanks,
Jim

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 508
  • Arcade Otaku sysadmin...
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #1 on: July 01, 2013, 04:46:18 pm »
If you're using Groovy properly then triplebuffer and waitvsync are being controlled internally ;)

That thread seems to be more about emulation speed accuracy than input lag. I'm not sure they're quite the same thing, but I'm not about to download 100MB videos to check.

Framedelay 1 makes a massive difference in my setup, effectively making everything I test compared to the PCB indistinguishable in a blind test.
Please don't PM me with support questions. Ask in public so everyone can learn!

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #2 on: July 01, 2013, 10:09:35 pm »
Actually, scroll down...he first tests the overall speed of the emulation then looks specifically at lag.  Its an all inclusive measurement, meaning that it account for display lag, emulation lag, and usb lag.  It is REALLY close to the hardware.

I would LOVE to hear that GroovyMAME can get this close (or closer)...I just don't have the measurement hardware to test it out myself.

-Jim

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #3 on: July 02, 2013, 11:46:07 am »
Also, any experimentation done with changing the USB polling rate?

-Jim

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #4 on: July 06, 2013, 12:50:47 pm »
Hi jdubs,

I'd be very interested too in seeing some real latency tests done for GroovyMAME. I wrote long ago in the shmups forum to invite people testing it with no success.

Bear in mind GroovyMAME doesn't implement any trickery (i.e. removing sprite buffers), it just tries to reduce or eliminate the lag associated to v-sync in normal MAME, so in the best case it would have the same lag that non-vsynced normal MAME has. On this regard, it's pointless to disable v-sync and report lag values based on that, as GroovyMAME is *supposed* to run v-synced, so that it's visually indistiguishable from the real thing.

As soon as I have the time, I'm going to run the tests myself. I have a new camera that can record at 240 fps. I'll add a frame number prompt on screen, and use the method of mapping a button to Caps Lock so the keyboard leds flashing are recorded together (as proposed by DaRayu's at mameworld's forum).

The problem is, I don't have the real hardware to compare with, so I'll need to test those games that we have reliable measurements based on real hardware.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #5 on: July 08, 2013, 03:38:41 pm »
Doing the measurements as you describe would be awesome, Calamity!!  Hopefully we can pull some real-hardware data together, as a community, for valid comparisons.

This will be huge for everyone!

Thanks!!
Jim



Hi jdubs,

I'd be very interested too in seeing some real latency tests done for GroovyMAME. I wrote long ago in the shmups forum to invite people testing it with no success.

Bear in mind GroovyMAME doesn't implement any trickery (i.e. removing sprite buffers), it just tries to reduce or eliminate the lag associated to v-sync in normal MAME, so in the best case it would have the same lag that non-vsynced normal MAME has. On this regard, it's pointless to disable v-sync and report lag values based on that, as GroovyMAME is *supposed* to run v-synced, so that it's visually indistiguishable from the real thing.

As soon as I have the time, I'm going to run the tests myself. I have a new camera that can record at 240 fps. I'll add a frame number prompt on screen, and use the method of mapping a button to Caps Lock so the keyboard leds flashing are recorded together (as proposed by DaRayu's at mameworld's forum).

The problem is, I don't have the real hardware to compare with, so I'll need to test those games that we have reliable measurements based on real hardware.

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #6 on: July 08, 2013, 06:28:56 pm »
Calamity, you might also want to take a look at the link I posted in the fist post in this thread.  papasi at the Shoryuken forums did some actual hardware lag tests / measurements for a CPS2 board (Super Street Fighter II Turbo).

-Jim

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #7 on: July 09, 2013, 06:25:39 am »
Calamity, you might also want to take a look at the link I posted in the fist post in this thread.  papasi at the Shoryuken forums did some actual hardware lag tests / measurements for a CPS2 board (Super Street Fighter II Turbo).

-Jim


Yeah I had read those links, I meant to test the same game (Super Street Fighter II Turbo) in GroovyMAME, as the lag in the actual board is a known value. However I still don't get how he got those values, from the videos he just seems to make the character jump, but I don't see how that relates to the moment the button is pressed.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #8 on: July 09, 2013, 02:21:57 pm »
I think the concept is using a universal gaming stick (working with PC plus the actual game) with an LED "tied" to the applicable button(s).  Using a camera with the LED and the screen in view, you can time how long it takes for the button press to translate into character movement on-screen.

Pretty good way of doing it assuming you've got a fast enough camera. 

-Jim



Calamity, you might also want to take a look at the link I posted in the fist post in this thread.  papasi at the Shoryuken forums did some actual hardware lag tests / measurements for a CPS2 board (Super Street Fighter II Turbo).

-Jim


Yeah I had read those links, I meant to test the same game (Super Street Fighter II Turbo) in GroovyMAME, as the lag in the actual board is a known value. However I still don't get how he got those values, from the videos he just seems to make the character jump, but I don't see how that relates to the moment the button is pressed.

Ex_mosquito

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #9 on: July 17, 2013, 07:05:20 am »
I am MEGA curious about the Groovymame input lagg. To me it's indestiquisgable from the actual PCB, on Shinobi, R-Type and Daimakaimura at least (I have these pcb's). I'd love to try and help. I have an AstroCity with GroovyMame+CRT_Emudrivers through a Jpac, and I also have a few PCBs. The only problem is I'm not sure how I would wire up a light to a button using the PCB, I could use the Caps button light like Calamity suggested for the emulation side. Anothing problem is I only have a camera that does 30fps. Would this be at least acceptable to get a rough analysis? I'm guessing you'd need 60fps minimum?

Also one more thing that I'm confused about. What is the 'frame_delay' option? Is this turned on by default in GroovyMame or would I need I generate an .ini and enable it?

Cheers Guys.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #10 on: July 18, 2013, 01:23:00 pm »
Also one more thing that I'm confused about. What is the 'frame_delay' option? Is this turned on by default in GroovyMame or would I need I generate an .ini and enable it?

It's the latter. You may want to read up a bit in the other thread "Re: Successfully reducing MAME input lag via 120Hz monitor (applies to LCD and CRT)". Specifically with regards to the practical use of -frame_delay I've posted some info halfway down this post: http://forum.arcadecontrols.com/index.php/topic,133327.msg1374143.html#msg1374143

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #11 on: July 21, 2013, 12:01:37 pm »
So yesterday I run some tests to see how GroovyMAME performs as compared to the results on the real hardware, here: http://forums.shoryuken.com/discussion/178437/official-shmupmame-super-turbo-thread/p1

First of all, by watching the videos done by papasi, I notice he is counting one frame less than I count (I'm referring to his videos). He says that SSFII Turbo, when played on the supergun, lags 4 frames natively, then I count them on his video and I get 5 frames. I'm guessing it must be due to the counting method: I start to count when the red led turns off, that frame is #1, then 2, 3, 4, and on #5 the character starts moving. Please correct me if you think I'm wrong.

The number of frames on my test videos has been counted following this rule, using Media Player Classic, CTRL+Right to advance frame by frame.

One difference is that I'm recording at 120 fps while papasi recorded his videos at 60 fps. So to get the number of frames on my videos you need to divide by too. I take 5 values and get the average.

The other difference is that the led in papasi's system is directly wired to the button, so in theory it's lag-less, but in my tests I'm using the keyboard leds, mapping the button to the caps-lock key in MAME (as suggested by DaRayu in MAME World). The problem with my setup is that, according to the old-school knowledge, it's the bios the one that turns these leds on/off, so the keypress signal must travel from the keyboard to the computer, be processed by the bios, then travel back to the keyboard where the led is finally lit. Obviously, this involves time, and judging by the slow motion video I took it takes at least 1 full frame of extra lag (5 frames at 240 fps). This means the led turns on/off one frame late, so you need to add 1 frame to the results from my videos.

So, due to this, my setup is suboptimal for this kind of tests. I really need to figure out how to wire a led to the buttons without short-circuiting my jpac, then I'll be able to get more accurate results.

The system that I used:
Pentium 4 3.0 GHz
Windows XP-64
ATI HD 4350
Catalyst 9.3 (CRT Emudriver)

Here are the videos:
http://www.2shared.com/file/jVoGNfgz/d3d_120fps.html
http://www.2shared.com/file/bgDinjGs/ddraw_120fps.html
http://www.2shared.com/video/FdRDSCvk/keyboard_led_lag_240fps.html

And here are the results and how it would compare to the real hardware:

d3d_novsync: 9, 6, 9, 7, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
d3d_vsync: 16, 16, 15, 17, 17 -> 16.2 -> 8.1 + 1(led-lag) = 9.1 ≈ 9 (4 frames of lag)
d3d_framedelay: 10, 11, 10, 9, 10 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)

ddraw_novsync: 8, 9, 9, 5, 8 -> 7.8 -> 3.9 + 1(led-lag) = 4.9 ≈ 5 (no lag)
ddraw_vsync: 11, 10, 12, 9, 8 -> 10 -> 5.0 + 1(led-lag) = 6.0 ≈ 6 (1 frame of lag)
ddraw_framedelay: 11, 9, 9, 10, 10 -> 4.9 + 1(led-lag) = 5.9 ≈ 6 (1 frame of lag)

The huge lag of d3d_vsync (4 frames) confirms DaRayu results and what we've been discussing here about the flip queue. This will need to be tested in W7 too, with newer versions of the drivers. So the only reasonable way of using d3d is by enabling the -frame_delay option: it removes 3 frames of lag, although, ironically, not because of the reason it was conceived for.

So, if these tests are right, we would have 1 frame of lag (as compared to the real hardware) for the properly working vsync cases (d3d_framedelay, ddraw_vsync, ddraw_framedelay). The frame_delay option doesn't seem to be making any fundamental difference here, although probably more accurate tests will be required to confirm this.

I believe the non-vsynced modes just show less lag because the changes are shown immediately without waiting for a full frame to be displayed. This is a little difficult to judge because the videos are not vsynced with the screen, so you get tearing either way.

« Last Edit: July 21, 2013, 12:40:26 pm by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

machyavel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 67
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #12 on: July 22, 2013, 01:05:32 pm »
Hello All,

This is very interesting discussion and very informative but what about GM running in linux?

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #13 on: July 22, 2013, 03:01:48 pm »
Calamity, thanks much for taking the time to do the testing!!  Very interesting results, indeed....

I think you're counting methodology makes sense.

-Jim

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #14 on: July 28, 2013, 05:40:50 pm »
Yesterday I figured out how to connect a LED to my arcade controls, it's been much easier than I had imagined. Just connecting a 5V LED between the button cable and the microswitch leg where the cable normally is, and the LED will flash instantly as soon as you press the button.

This has confirmed my previous measurements, when I added an extra frame to the raw results from the video to account for the keyboard led lag, it seems I was doing the right thing. In particular, the d3d + frame_delay case, which is my standard test case, now results in 6 frames counted (1.25 frames of lag as compared to the supergun).

The interesting part is that I have found why the frame_delay feature was not working properly for the purpose it was designed. It seems the input poll was being done before it was supposed to, so the potential benefit was not happening. I have made an experimental build fixing this, and the good news are these new videos seem to confirm a real input lag reduction of 0.6 frames (average). With the new implementation, MAME would be on average only 0.65 frames laggier than the supergun, and that's probably the best it can be. I have added a frame counter on the screen so it makes it easier to identify each frame.

Regarding Linux, I have done a similar test with GroovyArcade, although using the regular GroovyMAME Linux build (the frame_delay option was not enabled). Unfortunately this test seems to confirm that SDL page flippling adds 3 frames of lag, just like Direct3D. However, we still don't have a workaround for this as we have in Windows, so until this is figured out maybe it turns out that Windows with all these hacks applied is a better platform by now.

Here are the videos:  http://www.2shared.com/file/l2AWR4jk/input_lag_test_d3d_sdl_120fps.html

supergun (measured from this video: http://www.2shared.com/video/DXXoI0di/supergun_us_turbo2_CRT.html)
5, 4, 5, 5, 5, 4, 5, 6, 4, 4, 5, 5 -> 4.75

d3d_frame_delay_old
12, 12, 12, 13, 13, 12, 11, 11, 11, 13 -> 12 -> 6 (1.25 frames of lag)

d3d_frame_delay_new
10, 8, 11, 11, 11, 11, 10, 12, 11, 10, 12, 10, 12, 10, 13 -> 10.8 -> 5.4 (0.65 frames of lag)

sdl_linux
14, 15, 16, 17, 17, 15, 17, 16, 15, 18, 15, 17, 15, 16, 16 -> 15.93 -> 7.97 -> (3.22 frames of lag)


This time the system used for testing was:

- Core2Duo
- Windows XP 64
- CRT Emudriver 6.5
- ATI 9250
- JPAC
« Last Edit: July 28, 2013, 05:54:36 pm by Calamity »
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 508
  • Arcade Otaku sysadmin...
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #15 on: July 29, 2013, 04:58:08 am »
Excellent work! Look forward to testing the next release, see if I can notice any difference.
Please don't PM me with support questions. Ask in public so everyone can learn!

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #16 on: July 29, 2013, 05:47:40 am »
Hi Calamity,

The interesting part is that I have found why the frame_delay feature was not working properly for the purpose it was designed. It seems the input poll was being done before it was supposed to, so the potential benefit was not happening. I have made an experimental build fixing this, and the good news are these new videos seem to confirm a real input lag reduction of 0.6 frames (average).

This is awesome news! Big thanks for doing these very interesting tests and persevering in getting the frame_delay feature right. Hope you don't keep us waiting too long for the update!

Quote
With the new implementation, MAME would be on average only 0.65 frames laggier than the supergun, and that's probably the best it can be.

We're not there yet ;) I see two possibilities that might provide even greater reduction of the input delay:

1. Increase the USB sample rate from the default 125Hz to 1000Hz.
This will change the average delay from 8ms to 1ms, shaving of ~0.5 frame of delay.
It's possible in both Windows XP and Windows 7, see this link for the downloads: http://www.ngohq.com/news/15043-how-to-increase-usb-sample-rate-in-windows-vista-7-a.html.

Please note that the link is explaining it for Windows 7, but the patch for Windows XP is also included. For XP you apparently only need the hidusbf.zip, third download on that page, or directly from here: http://www.ngohq.com/attachments/news/1954d1243462515-how-to-increase-usb-sample-rate-in-windows-vista-7-hidusbf.zip. There's a "README.ENG.TXT" inside the package explaining the install for XP.

2. Replace DirectInput with the RAWINPUT api for joysticks.
To quote from the Microsoft site, http://msdn.microsoft.com/en-us/library/ee418864.aspx#WM_INPUT (see directly below the "DirectInput" header, about halfway down the page):
Quote
Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly.

There are no hard facts on how large that overhead reduction is, but based on experience it's substantial enough to notice. Note that this isn't easy to implement, but it has been done succesfully by Toni Wilen in WinUAE, completely replacing DirectInput for Joysticks and Gamepads. https://github.com/tonioni/WinUAE/blob/master/od-win32/dinput.cpp

Given your earlier testing results and the improved frame_delay feature, applying the two options above could possibly mean that GM's input delay can be reduced to *zero*. That is quite an exciting prospect! :P



jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #17 on: July 29, 2013, 02:40:48 pm »
Calamity, wow, thank you!!!  This is huge!

Now I have ZERO reason to even think twice about a different MAME!

Dr. Venom, you raise a couple of interesting ideas.  I did the sample rate change to 1000hz a couple weeks back and it seems to have improved thing.  Calamity, any desire to further your testing with the USB sample rate and RAWINPUT tweaks?  I'm very curious how close we can really get to zero lag!!

Actually, Dr. Venom, how does one implement the RAWINPUT tweak?  I went to the link but just see a bunch of code.

-Jim

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #18 on: July 29, 2013, 03:27:51 pm »
Actually, Dr. Venom, how does one implement the RAWINPUT tweak?  I went to the link but just see a bunch of code.

Jim,

RAWINPUT is not a "tweak" but an API for user input devices. So it needs to be incorporated by the programmer (that would be Calamity in this case ;) ) before end-users can make use of it. The link is showing the code for the WinUAE implementation, purely as an example of how it's been implemented for another emulator, as the implementation is not without quirks.

Hopefully Calamity is interested in exploring this further for GM at some time.  Official documentation from Microsoft is here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536%28v=vs.85%29.aspx

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #19 on: July 29, 2013, 04:11:43 pm »
Got it, thank you, sir!

-Jim


Actually, Dr. Venom, how does one implement the RAWINPUT tweak?  I went to the link but just see a bunch of code.

Jim,

RAWINPUT is not a "tweak" but an API for user input devices. So it needs to be incorporated by the programmer (that would be Calamity in this case ;) ) before end-users can make use of it. The link is showing the code for the WinUAE implementation, purely as an example of how it's been implemented for another emulator, as the implementation is not without quirks.

Hopefully Calamity is interested in exploring this further for GM at some time.  Official documentation from Microsoft is here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536%28v=vs.85%29.aspx

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #20 on: July 29, 2013, 04:18:19 pm »
Actually MAME already uses raw input since version v0.117u1: http://mamedev.org/updates/whatsnew_0117u1.txt

Quote
  * Changed the Windows implementation of input handling to fully support the raw input interfaces for keyboard and mouse. DirectInput is still used for all joystick inputs, as well as for keyboard and mouse inputs on pre-Windows XP systems. This allows for multiple keyboards and mice to be supported. Also changed keyboard and mouse behavior to use non-exclusive mode in DirectInput, and to keep the devices alive during pause for more consistent input handling.

I'm using a JPAC which is recognized as a keyboard, so it must be using raw input already.

Regarding hidusbf, I did install it in the system I used for the previous tests (with the keyboard leds). It didn't seem to make any difference then, that's why I didn't install it in the Core2Duo. But that was before I had the new frame_delay option and the proper led wiring, so I need to install it now and measure it more accurately to see if there's any extra lag that can be removed.

Definitely now any possible improvement will come from minimizing the time it takes to the system to pass input messages to MAME, so probably this is influenced by the overall system performance. Theoretically more powerful and multi-tasking efficient systems should react faster, but you never know.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #21 on: July 29, 2013, 05:14:21 pm »
Actually MAME already uses raw input since version v0.117u1: http://mamedev.org/updates/whatsnew_0117u1.txt

Well, that's only partly true. As your quote shows it will only use RawInput for Keyboard and Mouse, but not for any attached (non JPAC) Joysticks or Gamepads. This can also be seen this from the log:

Code: [Select]
RawInput: APIs detected
Input: Adding Mouse #0: HID-muis
Input: Adding Gun #0: HID-muis
Input: Adding Mouse #1: HID-muis
Input: Adding Gun #1: HID-muis
Input: Adding Kbd #0: HID-toetsenbordapparaat
Input: Adding Kbd #1: HID-toetsenbordapparaat
DirectInput: Using DirectInput 7
Input: Adding Joy #0: XBOX 360 For Windows (Controller)
Input: Adding Joy #1: 2600-daptor

Quote
I'm using a JPAC which is recognized as a keyboard, so it must be using raw input already.

Ah, so then for the purpose of this test it has already been using RAWInput, that's good.

It still leaves the many people using gamepads / joysticks etc. for their MAME and/or their SNES, Genesis, PSX, etc emulation (using GroovyUME) in the cold though :( In that respect adding RawInput for GamePads/Joysticks could possibly still bring a general benefit to GM...

I can imagine though if the JPAC is the sole input device you're using for MAME/MESS (SNES etc), that for yourself there's little benefit of adding RawInput as the general Input api. Well, hopefully for us poor souls not using jpac, you could still put it somewhere on your list... somewhere... deep deep down your priority list I guess... ;)

Quote
Regarding hidusbf, I did install it in the system I used for the previous tests (with the keyboard leds). It didn't seem to make any difference then, that's why I didn't install it in the Core2Duo. But that was before I had the new frame_delay option and the proper led wiring, so I need to install it now and measure it more accurately to see if there's any extra lag that can be removed.

OK, it will be interesting to see if it makes a difference in the test. From personal experience (in WinUAE) it can make a noticable difference with some shoot 'm ups (like Hybris on Amiga).

Given your interestings tests, I was thinking about some possible drawbacks that we may need to keep in the back of our mind. Could it possibly be that given that the recordings are done at 120fps, i.e ~8ms per frame, that this recording resolution may be too low to actually reliably record the input reduction given by the USB overclock? 

I guess another (related) thing could be that because of the 120fps resolution, and the camera not being synchronized to the vblank of the game (as you earlier mentioned) that in every individual test there's a risk of measuring an improvement (or vice versa a deterioration) while there actually may be none, simply because the camera started recording at another point in the frame?

Quote
Definitely now any possible improvement will come from minimizing the time it takes to the system to pass input messages to MAME, so probably this is influenced by the overall system performance. Theoretically more powerful and multi-tasking efficient systems should react faster, but you never know.

Indeed, theoretically the more powerful the better. That said, a less powerful system running less background processes, may possibly be more powerful regarding input response than a more powerful system running more background processes. Ah, the complexity of modern PC's/OS's. We could really need a realtime OS for this emulation stuff...

papasi

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 2
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #22 on: July 29, 2013, 05:42:24 pm »
Hi all,

sorry i haven't followed groovymame's development.

so it has .65 frames at best? that's not better than shmupmame is it?

i didn't go into the details of how shmupmame reduce the input lag (as well as groovymame).
can groovy or shmup take advantage of each other's trick and make it even better?

btw, does groovymame use github or other public repo?

i tried to contribute to shmupmame but they dont have a repo and the maintainer is not responding to issues compiling the binary so it discourages people from contributing or have faith in it not ending up being abandonware.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #23 on: July 29, 2013, 06:30:25 pm »
Given your interestings tests, I was thinking about some possible drawbacks that we may need to keep in the back of our mind. Could it possibly be that given that the recordings are done at 120fps, i.e ~8ms per frame, that this recording resolution may be too low to actually reliably record the input reduction given by the USB overclock?

Maybe. This camera can record at 240 fps too, although the quality is highly degraded (320x240). However it should still show the sprites moving to allow frame counting (the frame counter will be too blurry unless I increase the font size somehow).

Quote
I guess another (related) thing could be that because of the 120fps resolution, and the camera not being synchronized to the vblank of the game (as you earlier mentioned) that in every individual test there's a risk of measuring an improvement (or vice versa a deterioration) while there actually may be none, simply because the camera started recording at another point in the frame?

Certainly, that's why I'm making longer videos now so all possible deviations are averaged. I didn't post results confirming any improvements in the frame_delay feature until I got consistent results from several videos, anyway, please don't take these figures as definitive until more accurate tests are done (preferrably by other people). I mean, I'm quite sure it's below 1-frame of lag but 0.65 is just what I'm getting from this particular video and game.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #24 on: July 29, 2013, 06:59:03 pm »
Hi papasi,

Welcome and thanks for your videos!

so it has .65 frames at best? that's not better than shmupmame is it?

Bear in mind that all my tests are done with v-sync enabled, while I *believe* shmupmame has been tested without v-sync.

When tested GroovyMAME without v-sync, it resulted in no-lag (always compared with your supergun video). However I'm only interested in v-synced emulation.

Quote
i didn't go into the details of how shmupmame reduce the input lag (as well as groovymame).
can groovy or shmup take advantage of each other's trick and make it even better?

The approach in shmupmame is different: they remove the sprite queue so the sprites are shown faster although not in sync with the backgrounds. Recently they have a new the method, forcing the emulated CPU to get the input faster bypassing the emulated pcb's input processing. In either case, that involves breaking the emulation itself.

GroovyMAME patches leave the emulation alone and just try to optimize the way the external part of the emulator talks to the host system.

In theory, both methods combined might result in less lag than the actual hardware, but that's not the goal of GroovyMAME.

Quote
btw, does groovymame use github or other public repo?

The source is available as available as .diff files here:

https://code.google.com/p/groovyarcade/downloads/list

There's also a git but it's not being mantained as such.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #25 on: July 30, 2013, 06:00:48 am »
Maybe. This camera can record at 240 fps too, although the quality is highly degraded (320x240). However it should still show the sprites moving to allow frame counting (the frame counter will be too blurry unless I increase the font size somehow).

It would be nice if that works, with a 4 ms interval the chance of getting "wrong" readings is at least dimished by a lot.

Quote
Certainly, that's why I'm making longer videos now so all possible deviations are averaged. I didn't post results confirming any improvements in the frame_delay feature until I got consistent results from several videos, anyway, please don't take these figures as definitive until more accurate tests are done (preferrably by other people). I mean, I'm quite sure it's below 1-frame of lag but 0.65 is just what I'm getting from this particular video and game.

No I won't take the figures as definitive. But assuming that the supergun streetfighter doesn't have any delays built-in that weren't present on the real arcade cabinet, I take your figures as a good estimate (the best objective estimate we currently have even...). Personally I would rate the results definitive much easier if you had the real hardware sitting at your desk, and both real hardware and emulation were filmed with the same camera. No comparing different sources. Second, highly preferable would be to do comparisons with real hardware that has zero lag. For example a real SNES (Super Turrican and the likes) or Megadrive compared versus GroovyUME. But that said, I'm pretty happy with your tests and the fact that we at least have some objective facts now :)

A bit OT maybe, but I'm actually quite surprised that the real StreetFighter hardware has such a big lag. I would have expected such a quick reflexes game would be running everything within a frame. 4 frames of delay actually seems like a crazy big lag? Or would that delay actually be intended by the developers, given the type of "special move" that is initiated in the game?  I'm completely ignorant when it comes to a "supergun", so possibly this is a very dumb question, but how trustworthy are these "superguns" when it comes to replicating the original hardware?

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #26 on: July 30, 2013, 08:26:29 am »
Dr. Venom, the supergun idea was / is to allow folks to play arcade hardware at home.  In the case of the Shoryuken video, Capcom CPS2 hardware, specifically Super Street Fighter II Turbo.  There is no standard for the hardware but they all basically just route signals to allow plugging in joysticks, a monitor etc.  Some have converters to change the arcade RGB signal to something like component or s-video so that you can use it on a consumer-style television.  No lag should be introduced by the device itself so the results posted by Papasi should be 100% representative of the arcade game.

I have one which is about as bare bones as you get:

http://arcadeforge.net/Supergun-MAK-Strike/Supergun-MAK-Strike::74.html?MODsid=d0063e34b32656adde30d6599457ca8f

-Jim


Maybe. This camera can record at 240 fps too, although the quality is highly degraded (320x240). However it should still show the sprites moving to allow frame counting (the frame counter will be too blurry unless I increase the font size somehow).

It would be nice if that works, with a 4 ms interval the chance of getting "wrong" readings is at least dimished by a lot.

Quote
Certainly, that's why I'm making longer videos now so all possible deviations are averaged. I didn't post results confirming any improvements in the frame_delay feature until I got consistent results from several videos, anyway, please don't take these figures as definitive until more accurate tests are done (preferrably by other people). I mean, I'm quite sure it's below 1-frame of lag but 0.65 is just what I'm getting from this particular video and game.

No I won't take the figures as definitive. But assuming that the supergun streetfighter doesn't have any delays built-in that weren't present on the real arcade cabinet, I take your figures as a good estimate (the best objective estimate we currently have even...). Personally I would rate the results definitive much easier if you had the real hardware sitting at your desk, and both real hardware and emulation were filmed with the same camera. No comparing different sources. Second, highly preferable would be to do comparisons with real hardware that has zero lag. For example a real SNES (Super Turrican and the likes) or Megadrive compared versus GroovyUME. But that said, I'm pretty happy with your tests and the fact that we at least have some objective facts now :)

A bit OT maybe, but I'm actually quite surprised that the real StreetFighter hardware has such a big lag. I would have expected such a quick reflexes game would be running everything within a frame. 4 frames of delay actually seems like a crazy big lag? Or would that delay actually be intended by the developers, given the type of "special move" that is initiated in the game?  I'm completely ignorant when it comes to a "supergun", so possibly this is a very dumb question, but how trustworthy are these "superguns" when it comes to replicating the original hardware?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #27 on: July 30, 2013, 08:39:24 am »
If the output of a supergun is RGB, then definitely it should be 100% real. However if it's converting the signal to S-video or similar crap, then we can't rely on the results. Hopefully Papasi can confirm this.

On the other hand, the test done by NKI shows 4 frames (1 less than Papasi's):

NKI Testing Input Lag street fighter 2 turbo - arcade, dreamcast, ps1, CCC2


To clarify, Papasi's test shows 4 frames of lag = 5 frames counting since the LED lights up. NKI's apparently shows 1 frame less (4 frames counting since the LED lights up). But there is only one sample in the video, so I wouldn't trust it too much.
CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #28 on: July 30, 2013, 02:05:38 pm »
Jim, thanks for the explanation on the supergun. Seems like a cool bit of kit to have.

It would be interesting to know how the joystick connectors work on these boards. Basically how the signal routing is done and whether or not there's a conversion done like for example on many of these chinese "PS3->USB", "SNES->USB" etc. adapters, which unfortunately many of them use chips to poll the controller in the range of (a disappointing) 125Hz. Quite possibly the only reason being that they are cheap to use.

Given the price of some of these superguns I wouldn't be surprised if some have these cheap chinese controllers on them... But that is pure speculation on my side. I might be completely wrong, and possibly all these things are wired to work in realtime.

On the other hand, the test done by NKI shows 4 frames (1 less than Papasi's):

That's an interesting video. I think you're right that we shouldn't trust it too much, but given how the test has been setup, with additional "double tests" being done (like keeping the test the same but switching the TV and such) to verify whether the results are consistent does give some comfort on the quality of the test. To be honest, given this new "evidence", I think there's quite a chance that the real hardware has only 3 frames of lag.

But indeed, maybe Papasi has some idea on where these differences may come from.


jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #29 on: July 30, 2013, 02:37:06 pm »
Jim, thanks for the explanation on the supergun. Seems like a cool bit of kit to have.

It would be interesting to know how the joystick connectors work on these boards. Basically how the signal routing is done and whether or not there's a conversion done like for example on many of these chinese "PS3->USB", "SNES->USB" etc. adapters, which unfortunately many of them use chips to poll the controller in the range of (a disappointing) 125Hz. Quite possibly the only reason being that they are cheap to use.

Definitely.  They are good to have around to the extent you've got room for arcade boards.  At least with the MAK (and I think *most* super guns), the controls are all real-time.  That is, the super gun just routes inputs from a connector (in the MAK's case a simple db-15) to the JAMMA interface.  No conversion going on at all, just signal routing. 

-Jim

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #30 on: July 30, 2013, 03:14:13 pm »
Definitely.  They are good to have around to the extent you've got room for arcade boards.  At least with the MAK (and I think *most* super guns), the controls are all real-time.  That is, the super gun just routes inputs from a connector (in the MAK's case a simple db-15) to the JAMMA interface.  No conversion going on at all, just signal routing.

That's the best you can get, good to know they work that way.

papasi

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 2
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #31 on: July 30, 2013, 08:30:05 pm »
The reason why the frame counts are not consistent in ST is because of this

http://combovid.com/?p=5002

At JP T3/ US T2, SSF2T is running at 143% compared to SSF2 (the previous version)

The frame skip pattern is like this 2,2,3,2,2,3,   

Ideally it is easier to test with SSF2 or Hyper SF AE with turbo set to 0. But no one is interested in those competitively and the people who have the boards for those games are not interested in emulator lags either...

So for ST the only way is like what I and Calamity did, run a good amount of samples like 20 and average them.

The supergun shouldn't have lag compared to the arcade cab.

Also, even though it takes ~= 4.5 frames from the time you press round house to the animation changes on the screen, the arcade game has no lag.

All the moves in the game have different frame data and for round house kick it doesn't become active until a few frames later.

Otherwise that move will be overpowered as you can punish anything immediately.

And Calamity is right. It is unclear whether NKI just ran a bunch of samples and took the medium value or not.
That's why I posted a video of me doing 20 in a row.
« Last Edit: July 30, 2013, 08:32:03 pm by papasi »

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #32 on: July 30, 2013, 09:13:27 pm »
papasi, certain of your tests are with a crt, but is the crt fed an RGB signal from the supergun or is it being run through a video converter (to something like s-video, component, etc.)?

-Jim


The reason why the frame counts are not consistent in ST is because of this

http://combovid.com/?p=5002

At JP T3/ US T2, SSF2T is running at 143% compared to SSF2 (the previous version)

The frame skip pattern is like this 2,2,3,2,2,3,   

Ideally it is easier to test with SSF2 or Hyper SF AE with turbo set to 0. But no one is interested in those competitively and the people who have the boards for those games are not interested in emulator lags either...

So for ST the only way is like what I and Calamity did, run a good amount of samples like 20 and average them.

The supergun shouldn't have lag compared to the arcade cab.

Also, even though it takes ~= 4.5 frames from the time you press round house to the animation changes on the screen, the arcade game has no lag.

All the moves in the game have different frame data and for round house kick it doesn't become active until a few frames later.

Otherwise that move will be overpowered as you can punish anything immediately.

And Calamity is right. It is unclear whether NKI just ran a bunch of samples and took the medium value or not.
That's why I posted a video of me doing 20 in a row.

jdubs

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 61
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #33 on: July 31, 2013, 04:45:47 pm »
Guys, another discussion regarding this topic (tangentially) is happening on SRK.  Some more pretty interesting info:

http://forums.shoryuken.com/discussion/181076/super-turbo-offline-setup-guide-lag-rating

-Jim

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5469
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #34 on: August 01, 2013, 02:58:27 pm »
Papasi, thanks a lot for your detailed post, the frame skip pattern certainly explains the uneven results from the videos. Regarding the frames it takes to get certain movements to show, it's interesting to use the shift+P method that you surely know, and indeed you can see how some movements take longer than others. Thinking about it, it makes sense that a game that is supposed to accept combos can't show the action instantly, it must wait to check if a certain sequence of inputs happens before it decides what to do (just an idea).

However this information got me thinking that possibly this game is not the best test case if we want to find what is lowest actual input lag achievable with the MAME emulator. Based on the list here: http://shmups.system11.org/viewtopic.php?t=26394 there are games that have no lag, i.e. action happens on the next frame. This means that if you use the shift+P method, while pressing the joystick on one direction, you'll see how the spacecraft or whatever moves right on the next frame. This is so because pausing the emulator and stepping frame by frame discards any possible input latency due to the host system overhead. This way you make sure that when you press shift+P, the input is already available for the next frame. But, would this happen when running the game normally?

On the other hand, when recording a game that has a refresh rate different than 60 Hz (as is the case of cps2), you'll see how the raster's begin and end roll by the screen during the video. This makes it difficult to get accurate lag results because depending on which point the raster is at the time the frame is captured, relative to the point when the LED lights up, you will need to be very careful to actually judge how many whole frames you need to count.

Fortunately, if we film a game that has an exact refresh rate of 60 Hz, the raster position is going to be "static" between diferent captures. This makes the task much easier. I've chosen Terra Cresta, because it's 60 Hz and it's known to have the minimum possible lag (action happens on next frame).

What I've found is that GroovyMAME can really get the action happen on next frame, but this is only true if the input happens somewhere inside the first 1/3 of the previous frame. I'm running GM with -frame_delay 7. This means that the period of time that takes from 1/3 to 7/10 of frame (green and red lines in the picture) is the estimate lag attributable to the host system. The USB polling rate has been set to 1000 Hz, and GM is using raw input already (JPAC), so this is the bare minimum lag that seems to be possible for my particular system (Core2Duo).

This has interesting implications. In most games action happens on the lower 2/3 of the screen. This means that when you get to see the sprite, it's normally too late to get your input on time for next frame. So for horizontal games, you'll experience the minimum possible lag when the character sprite is on the top 1/3 of the screen, while for vertical games this means the left 1/3. So for horizontal games, the ultimate setup would be physically rotating the monitor by 180 (upside down) and then rotating the picture again with MAME  ;D

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

matrigs

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #35 on: August 01, 2013, 06:07:13 pm »
If someone with a bit of electronical experience would chip in, we could achieve a way of recording the game screen with perfect accuracy, syncing the camera to the vertical sync.

The Playstation EYE camera has an exposed frame sync input on its' chip, which has been used to sync the recording speed with another Playstation EYE, as these have also an exposed vertical sync output.

http://www.instructables.com/id/The-EyeWriter-20/?ALLSTEPS

http://www.zhopper.narod.ru/mobile/ov7720_ov7221_full.pdf

It shouldn't be difficult to connect a vertical sync signal from a source computer, this way achieving perfect sync regardless of the refresh rate, so perfect for cps2 games etc.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #36 on: August 04, 2013, 01:58:15 pm »
Hi Calamity,

Fortunately, if we film a game that has an exact refresh rate of 60 Hz, the raster position is going to be "static" between diferent captures. This makes the task much easier. I've chosen Terra Cresta, because it's 60 Hz and it's known to have the minimum possible lag (action happens on next frame).

It's great that you've been doing these additional tests, they are truly valuable.

Quote
What I've found is that GroovyMAME can really get the action happen on next frame, but this is only true if the input happens somewhere inside the first 1/3 of the previous frame. I'm running GM with -frame_delay 7. This means that the period of time that takes from 1/3 to 7/10 of frame (green and red lines in the picture) is the estimate lag attributable to the host system. The USB polling rate has been set to 1000 Hz, and GM is using raw input already (JPAC), so this is the bare minimum lag that seems to be possible for my particular system (Core2Duo).

It's especially nice that we now can attach a figure to "host system lag". Basically what your test says is that the host system lag for your system, while using rawinput and 1ms clocked usb ports, is that it takes 6ms for the input to be available to the application (GM in this case). I had a quiet hope that this would be lower, but given my own tests and experience I do find a "base" host lag of 6ms to be plausible. It would be interesting to see how this compares to other systems but I guess that will be difficult to test.

So with a frame_delay of 7 we are at 11ms (average) input delay for a 60hz game. I guess the maximum possible reduction would be the ability to run at a frame_delay of 10, reducing the delay only to the host system delay or in other words 6ms. But I wonder if that will be ever feasible give the -variation- in frame emulation time and the facts that the Windows wait command may sometimes result in less than exact 1ms wait times also.

Ah well, in the end, as it is now, being able to reliably reduce average input delay to half a frame makes me a very happy gamer :) 

For discussion sake, I disagree on the rotating monitor part :D

1) In many shoot' m ups your worst enemies are at or coming from the top of the screen (gradius, r-type, etc.), wouldn't want to have that rotated to the "slow" displaying part of the screen

2) Given that human reaction time when measured from sensing (with eyes or ears) to muscle action is physiologically taking on average more than 200 (two-hundred) ms, it's impossible for a human to react to something -unexpected- happening in the first 1/3rd displayed on screen and move the joystick in that same frame.

I guess Arcade games are more about recognizing sprite patterns and anticipating to those. By anticipation and adaption a large part of the 200ms+ "reaction time" may be reduced. E.g. if you know the road with all its corners by heart you can drive faster (knowing when to turn the wheel) than someone for whom the road is totally unfamiliar.

Given this adaption mechanism "reaction time" becomes quite a complicated thing. Bottom line is that we can still differentiate between input delay  up to a granularity of single frame delays (on average at least), but for the rest... I guess that may be something for the X-Files :)

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 593
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #37 on: August 04, 2013, 08:29:02 pm »
on a sidenote, i've found that using a gamepad instead of a real arcade joystick reduces 'human lag'

on a gamepad which uses a typical dpad, there isn't much travel/time lost between physically moving the dpad from eg. left to right.  with a real arcade joystick obviously the travel between eg. left and right is greater, and the longer the joystick shaft, the worse things get :o (no doubt that's why those sanwa short shaft/super light/high sensitivity ball-top joysticks are popular amongst streetfighter fans)

i really noticed the difference on my mame pc when i tried a real arcade joystick (with a zero delay encoder board) instead of my ps2 dualshock2* controller (via ps2 to usb adapter), and went back to my dualshock2 controller right away. my brother reported the same problem too with his ultimarc minipac + arcade joystick (although i suppose you could argue that we are simply more used to using dpads rather than real arcade joysticks.. who knows.  with a real arcade joystick maybe things get better once you master just moving your wrist instead of your entire arm (which i admit i tend to do :lol)


*modded, because as standard i find the diagonals are a bit too hard to hit!

« Last Edit: August 04, 2013, 09:27:50 pm by jadder »
typed using my...

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #38 on: August 05, 2013, 02:39:58 pm »
on a sidenote, i've found that using a gamepad instead of a real arcade joystick reduces 'human lag'

on a gamepad which uses a typical dpad, there isn't much travel/time lost between physically moving the dpad from eg. left to right.  with a real arcade joystick obviously the travel between eg. left and right is greater, and the longer the joystick shaft, the worse things get :o (no doubt that's why those sanwa short shaft/super light/high sensitivity ball-top joysticks are popular amongst streetfighter fans)

Yes the joystick hardware configuration can certainly make a difference. I'm not sure whether a good gamepad mechanically can be quicker than a -good- joystick, but alas. Personally I prefer a Gamepad for console (MESS) emulation only, but for Arcade gaming and some homecomputers I highly prefer a joystick. For the latter I'm a big fan of my Suzo Arcade joystick (with 1ms USB adapter) for many shooters as the joystick is -really- tight (mechanically) in its movement. (http://en.wikipedia.org/wiki/The_Arcade_%28joystick%29)

Unfortunately it only supports two firebuttons, so I've been looking for an alternative and purchased the X-Arcade joystick (http://www.xgaming.com/store/arcade-joysticks-and-game-controllers/product/x-arcade-solo-joystick/). But sadly (IMHO) that joystick very much suffers from the point you made, it takes quite large movements to get the microswitches to trigger :(.  There is a way too make them tighter to react (as per the manual on the x-arcade site), but even then it doesn't come close to the Suzo Arcade joystick mentioned earlier.

I'm thinking about replacing only the joystick on the X-Arcade board with the "Suzo System 500 Joystick", mentioned as the "Euro-Stik" on this page on Ultimarc.com: http://www.ultimarc.com/controls.html :

Quote
This is the Suzo System 500 stick. This is one of the most popular sticks in European arcades. It's fair to say that compared to the traditional USA sticks it takes some getting used to, but it has many fans with it's short, well defined throw. It is fully adjustable 4-8 way by rotating the plate (the screws can be left slightly loose) and even has a 2-way mode!
Mounting this stick under a wood panel takes a little more work as it has a raised ridge around the shaft which needs a recess. It's also great for mounting into the top of a panel, covered by an overlay, or on a metal panel.

This seems to be the real Arcade version joystick of the earlier mentioned Suzo Arcade for home use. Hopefully it's as tight in its movement as I hope it to be...

Quote
with a real arcade joystick maybe things get better once you master just moving your wrist instead of your entire arm (which i admit i tend to do :lol)

LOL, I remember doing that too when I got my very first home computer, not only bend over with my arm, but move with my hole body. Especially fun when you saw family members / friends doing the exact same thing, it looked really silly ;D
« Last Edit: August 05, 2013, 02:42:44 pm by Dr.Venom »

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 254
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #39 on: August 08, 2013, 09:56:08 am »
Hi Calamity,

What I've found is that GroovyMAME can really get the action happen on next frame, but this is only true if the input happens somewhere inside the first 1/3 of the previous frame. I'm running GM with -frame_delay 7. This means that the period of time that takes from 1/3 to 7/10 of frame (green and red lines in the picture) is the estimate lag attributable to the host system. The USB polling rate has been set to 1000 Hz, and GM is using raw input already (JPAC), so this is the bare minimum lag that seems to be possible for my particular system (Core2Duo).

Now that we've almost hit rock bottom on the possible input delay reductions, finally getting a sense of all the variables involved (many they are) to get to the lowest possible latency, I was thinking of some very last straws to latch onto, to possibly lower that average input latency of 0.65 frame even further.

Basically where we are now:
  • frame_delay feature allows us to reliably reduce traditional emulator delay, by moving the frame emulation closer to vblank. A setting of 7 seems to reliably reduce the input delay with rounded 12ms for a 60hz game, leaving about 5ms of delay.
  • "host system delay", i.e. the delay in the USB signal traveling through the Windows layers, seems to add about 6ms.

I have two observations:

Regarding 1:  On my machine, a 4.6Ghz i7 3770k, using MESS drivers that run unthrottled in the range of 2600% (26 times faster than real hardware frametime), it seems as if the frame_delay has a limit of 7, before starting to skip frames occasionaly (my personal conclusion), adding to the input latency. I find it odd that for this setup and PC hardware, frame_delay isn't able to reliably use a value of 8 or 9, or the valhalla 10 even, given how high the untrottled speed is?

I can currently think of only one reason, which is the reliability of the Windows wait() function. Apparently this normally defaults to a smallest value of 10ms wait time, regardless of whether you specify a smaller value. Only by setting specific parameters the granularity can be increased to the lowest possible, which I understand to be 1 ms. Now I did a small test some time ago, and from my findings it looked that Windows mostly provides wait() periods with granularity of up to 1ms, but every now and then will throw in a 4ms wait time. I'm definitely not sure how this works for MAME, but "random" instances where the wait() time will extend by 4ms, would most definitely be the cause for the frame_delay feature to not work to its fullest extend, because any setting - larger than 7 - will then occasionaly push a frame beyond the vblank, causing a skipped frame and adding 16+ ms to the input delay.

Hopefully other knowledgeable people can bud in, as possibly the above is one of the causes that - if improved upon - could lower the input delay by possibly as much as 4ms for many drivers when run on a fast PC.

Regarding 2: I'm wondering about the base host delay,  i.e. the delay in the USB signal traveling through the Windows layers, being 6ms and how this works.

In Calamity's update we will have the following loop:
Code: [Select]
a.display frame-> b.run the frame_delay (i.e. wait!) ->c. poll input -> d. emulate frame -> (loop to a.display frame)
Which to me raises the questions:
  • What are the chances that (part of) the "host system delay" is from the point on that the "c.poll input" is done?
  • Does "c.poll input" return OK with 100% certainty before moving to d.emulate_frame in a multi-threading setting?

If there's any possible slight delay from the "c.input poll", then (with multithreading enabled and frame emulation starting in parallel) the input event may not be available to the frame_emulation in time! Thus adding a full frame of extra input delay in these situations. Even if that only occurs occasionaly, possibly depending on speed of host PC, then that would be very detrimental to the whole purpose of the frame_delay feature.

In case the above might be true for certain situations, what could be a possible solution that would not burden the emulation in other ways? Currently "frame_delay" is simply "waiting" until point X in the frame. Can't we make that wait time more productive, i.e. why not make the frame_delay wait() period a simple loop that does:

Code: [Select]
while time left {
poll input;
}
 
That would make it extremely certain that the very last input event is available to the d.emulate_frame part, even if there would be a possible "host system delay" in a multithreading setting between c.poll_input and d_emulate frame.  Possibly this method could wipe a large part of the current "host system delay", further reducing the input_latency?

I guess I may be very wrong about this, as I have no understanding of how and where the "host system delay" in a Windows PC is adding up to the measured 6ms, and I'm also not knowledgable about how the input polling event works out in a multi-threading setting.

Hopefully there's some reason to it (but possibly not :D), and we'll be able to squeeze out some of those remaining 11ms in input latency...
« Last Edit: August 08, 2013, 09:59:27 am by Dr.Venom »

  
 

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