Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode 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 135881 times)

0 Members and 2 Guests are viewing this topic.

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #80 on: April 24, 2014, 02:47:28 pm »
fyi taken from another thread (http://forum.arcadecontrols.com/index.php/topic,138817)

question to andy warne:
regarding your ipac/keyboard encoders products, there have been some talk about people using using eg. windows xp overclocking their usb ports which are usually 125hz default i believe, up to 1000hz in an attempt to shave off a bit of input lag
i think you may have answered some questions on this before but can u just verify
regarding your usb2.0 devices such as the minipac, is there actually no benefit/no need/no point to overclock the usb ports?
many thanks

his response:
Thats right, there is no need. The fixed default only applies to "Low speed USB" where the host ignores the device-specified interval and substitutes 7 ms. These use Full Speed USB which specifies 2 ms and the host uses this value.

RandyT

  • Trade Count: (+14)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 6882
  • Last login:March 26, 2024, 03:33:28 pm
  • Friends don't let friends hack keyboards.
    • GroovyGameGear.com
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #81 on: May 17, 2014, 01:48:26 pm »
Finally, regarding the suggestion of a continous input poll while waiting, I think this wouldn't mean any difference, as inputs are event driven rather than polled. So think about the inputs as messages that get stored in a mailbox. It doesn't matter if you check the mailbox 100 times in a day or just once before you go to bed, the amount of messages you will pick during the day is the same.

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.

When folks are considering input "lag", the two quotes above are very important.  I believe that when people hear the word "lag" they infer the meaning to be that it will slow them down somehow.  What needs to be kept in mind is that everything is relative.  In the world of electronics, things are moving at speeds which mere humans cannot comprehend without using mathematics to represent them.  At a certain threshold, everything becomes instantaneous with regard to our abilities to sense or react to them.  To put this further into perspective, even light traveling in a vacuum has "lag", but unless it's origin is 186282 miles away, it wouldn't even take a second to reach your eyes.  In the sense of display frame timing, 60hz was selected first because it was easy (electricity in North America runs at 60hz) and second because it's well above the 24 fps found to be the minimum for film to produce continuous, "flicker-free" motion images for viewers, at a time when high frame rates were impossible or prohibitively costly to create.

In the case of whether or not emulation can provide the same experience as actual hardware, it all operates relative to the same, very small scale.  The fact that elaborate, frame accurate capture setups with LED indicators are necessary to flesh out what is happening at that level, is proof enough that it is happening at speeds which are well beyond our "instantaneous" perception threshold.  So those who believe they experience lag which can affect their play, due to being a half, or even a full frame behind, are very likely doing a bit of projecting.  But as Calamity states, fast systems should be able to do what the original hardware does for each frame, which is, in simple terms:

Check input
Calculate result based on input
Display result
Repeat

So whether user input is checked once or a thousand times, it will make little difference to the code, as it must do these things in the above order.  Any input buffered after the initial check, will need to be acted upon in the next frame, as it cannot stop what it's doing and recalculate the result in midstream.  The original code is likely to be further limited by allowing only one data transition for each frame which is calculated.  So in the case of the example used earlier, either the ship moves one pixel per displayed frame, or it does not.  Having these movements queued 1000 times over, as opposed to just once, will make no difference to the code.

So, given the above, "low-speed" (again, a very relative term which has no bearing on human perception) USB devices which report the states of all controls at 8ms intervals (i.e. twice for each generated frame) are more than sufficient.  Therefore, 1 ms polling intervals are entirely unnecessary, and really only adds unnecessary system overhead and bus traffic.

The most important thing to look at with controllers is the manner in which input is processed.  For example, a controller which transmits it's states 1000 times a second will not be advantageous if that controller takes 20 or 30ms to decide whether the status of the devices connected to it have changed.  It will simply be uselessly transmitting exactly the same data until it does.  Those who might believe that it's important to get an input message in "under the wire" before the inputs are polled and when processing begins, really need to take a hard look at the extremely tiny fraction of time where this occurs, and honestly assess whether there is any practicality there whatsoever.   And if there's not, then adding more burden to the system in the way of higher polling rates, doesn't make sense, and may actually work against the goal.

Then, take a hard look at the actual devices (buttons, joysticks, etc,) and decide whether these are offering the performance you expect for the types of games you play.  There is a vast difference in the mechanics of varying devices, which can lead to a delay between the time you intend to perform an action, and when it actually gets to the point of indicating to the controller that something has changed.  If this is the cause of issues for you, even original arcade hardware would show them, with those devices attached.
« Last Edit: May 17, 2014, 03:28:49 pm by RandyT »

sudopinion

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 32
  • Last login:June 08, 2022, 12:53:41 pm
  • 01100001 01101100 01101100 00100000 01101001 01101
    • RoM-Jacket
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #82 on: May 18, 2014, 02:11:35 pm »
just wondering why retroArch + KMS wasn't included in these tests.
01100001 01101100 01101100 00100000 01101001 01101110 00100000 01100001 01101100 01101100 00100000 01101001 01110011 00100000 01100001 01101100 01101100 00100000 01110111 01100101 00100000 01100001 01101100 01101100 00100000 01100001 01110010 01100101

Monkee

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 166
  • Last login:March 27, 2018, 09:37:30 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #83 on: May 18, 2014, 03:02:25 pm »
just wondering why retroArch + KMS wasn't included in these tests.
+1, it seems that KMS doesn't suffer from the lag you encounter with sdl so it's the best solution for linux on the paper.
« Last Edit: May 18, 2014, 03:03:57 pm by Monkee »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #84 on: May 19, 2014, 01:14:41 pm »
Hi RandyT,

Thanks a lot for sharing your insight here. I totally agree with what you're saying.

For example, a controller which transmits it's states 1000 times a second will not be advantageous if that controller takes 20 or 30ms to decide whether the status of the devices connected to it have changed.

This is a very important observation imho. And unfortunately it's something we can't measure through the crude tests we're doing here. We just see the led light up when the switch is triggered but the whole process until the ship moves is a black box for us.

Definitely this is where we should look at. In fact in my experience increasing the usb poll rate didn't make any difference to the results, and instead, to my surprise I started to see issues with my usb hard disks not being recognized.

Quote
Then, take a hard look at the actual devices (buttons, joysticks, etc,) and decide whether these are offering the performance you expect for the types of games you play.

This is another point, I'd say with many joysticks the simple act of moving the stick to one direction until the switch is triggered takes more time than the amount of "lag" we're dealing with here, not sure.

Quote
Check input
Calculate result based on input
Display result
Repeat

Exactly (if we leave apart subtle things like boards that could be polling inputs in the middle of a frame, etc.)

Because emulation of the usual arcade hardware is based on a loop of discrete steps, it's obvious for us that if we made each step last as long as 1 minute, we would always get the input in time for the next frame, even with the most retarded operating system. Now if we gradually reduce the length of each step until the miliseconds range or more it's also obvious that at some point the system won't be able to get the input processed for the next frame. What we're saying here is that with current hardware/OSes, this critical point shouldn't be reached when emulating the hardware at its original speed. The tests with Windows XP / Core2Duo showed that we are *almost* there.

The problem is some people just hear "windoze" and automatically think of a bloated monster that is searching for unused icons on your desktop while it should be processing your input and simply forget that a 16.67 ms period is not exactly in the Plank scale when it comes to modern hardware. The critical point on the software side is having reliable vertical blank signals, and make sure the driver doesn't arrange a frame queue. Here is where mystifiers come to say this is impossible to achieve in "windoze" (while they type from their laptops). The good thing about using the same drivers for everyone is that at least one of the sources of uncertainty (the software) is out of the equation.
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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #85 on: May 19, 2014, 01:20:50 pm »
just wondering why retroArch + KMS wasn't included in these tests.

+1, it seems that KMS doesn't suffer from the lag you encounter with sdl so it's the best solution for linux on the paper.

To be honest when I did those tests I wasn't aware of the existence of Retroarch.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #86 on: May 27, 2014, 10:41:57 am »
Here is a 120FPS video of Terra Cresta in Retroarch's Mame .151 core running in Ubuntu 14.04 with KMS.  The button press LED is directly below the monitor.

https://anonfiles.com/file/4625beaeabff31ae37556b6075a8a456

Please verify my counting method, but here are my results:

10, 11, 10, 9, 9, 10, 10, 10, 11, 10, 11, 11, 11, 10, 11

Average: 5.1333333333333

While this is respectable and 1 or 2 frames faster than my test in Windows with Hard GPU sync enabled, my tests with Shmupmame are definitely faster, averaging between 3 and 4 frames. I understand this may actually be more responsive than the real hardware and not desirable?  Also, what is the best result achieved by GM so far?  The last post with specific results appears to be reply #14 where 5.4 is reported for SSF2T.  What was the best result with Terra Cresta?  All the videos seem to be unavailable from the posted links now except for the Youtube video showing 4 frames for the PCB, so I don't have anything to compare my results/counting method with directly, unless I'm overlooking something.  I'm a little uncertain of what the target should be and how close Retroarch+KMS is to it.   Here are the details of this setup:

PC: Dell Optiplex 755 (Core2Duo e6550, Intel Graphics, 4GB RAM)
OS: Ubuntu 14.04 64-bit.  Default Intel Video drivers are used.  The driver documentation says that KMS is enabled by default, so I'm trusting this.
Retroarch/Mame:  Installed from HunterK's PPA. RetroArch 1.0.0.2 from 3/24/14 and libretro-mame 0.151 from 3/15/14
Display:  640x480 VGA out to Extron Emotia in non-interlace mode to Sony PVM 2530
Input Device: Hori Real Arcade EX-SE, with LED wired directly to one of the buttons. 

Edit:  Added more details and questions.
Edit 2: It seems my understanding of how KMS works is faulty.  To be clear, this test was done by launching Retroarch from the X environment.
« Last Edit: June 02, 2014, 10:40:25 am by vicosku »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #87 on: May 27, 2014, 05:37:43 pm »
Hi vicosku,

Thanks a lot for the test. Maybe you could try testing it on its native orientation, to see if it makes any difference. Your results show a surprising amount of lag, especially considering you're using RA with KMS. It makes me wonder if KMS is actually working in your setup because those results seem to indicate there's a hidden frame queue there.

I've uploaded the video from which I took the results posted here:

https://mega.co.nz/#!A4ViCCiB!avMcQDlg2F_Sov-QExPv7slNuL-ssmqcE95_gNHVbCo

In my video, IIRC the counting was 4 in general (66% of probability) and sometimes 3 when the input happens on the first third of the screen (33% of probability). These values point to 1.5-2 real frames behind input, and because the bare minimum "lag" is 1 frame (=action happens on the next frame on real Terra Cresta hardware), this means 0.5-1 frame of lag as compared to the real hardware. Obviously 0.5 means 0 and 1 means 1 because we deal with whole frames.

PD: Yeah the old links are dead, I'll re-upload the videos if I can find the exact match in my HD.

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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #88 on: May 27, 2014, 06:01:14 pm »
Thank you so much for the quick reply and for uploading the video again.  It looks like your results are basically equivalent to what I experienced with ShmupMAME!  As for testing in the proper orientation, I can't get Vsync to work at all with this set up when I rotate the screen, so testing it that way would be pointless. My results were the same with SSF2T though. I'm basing my assumption that KMS is enabled and working on this article:

https://wiki.archlinux.org/index.php/Intel_Graphics

"Kernel Mode Setting (KMS) is required in order to run X and a Desktop environment. KMS is supported by Intel chipsets that use the i915 DRM driver and is enabled by default. Versions 2.10 and newer of the xf86-video-intel driver no longer support UMS (except for the very old 810 chipset family), making the use of KMS mandatory[1]."

I'd be glad to do some more testing when I get the time, but for now I'm much more interested in getting GM set up in XP ASAP and taking advantage of all the apparent benefits over my current setup.  I was actually using FBA instead of MAME because I had hitching issues with scrolling.  And I'm using FBA .2.97.28 instead of .2.97.30(Next?) because the former has severe issues with sound effects in Neo Geo games.  Regardless, I'll leave the Ubuntu hard drive alone so I can easily switch to it later if needed.  I have a laptop running Ubuntu in KMS with an Nvidia adapter loaded up and ready to test as well. 

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #89 on: May 27, 2014, 06:37:30 pm »
Hi vicosku,

Did you try RetroArch from outside X to make sure KMS is working?

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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #90 on: May 27, 2014, 09:35:46 pm »
Oh, I didn't even consider to try that.  I will sometime in the next few days or this weekend.  I just got my XP install running using the dummies' guide.  It's the same computer, just with an AMD 4550 added in.  I can't believe the results.  Here's another video. 

https://anonfiles.com/file/6787127cf93cc7a48a520606c5ff2383

At 120 FPS, the first 8 results are:  6, 7, 7, 7, 5, 6, 5, 7

This was with Frame_Delay 7.  I've been chasing this result for over a decade.  I really have to play some games now.  I truly appreciate the work that you and others have done on this project.

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 645
  • Last login:March 11, 2024, 02:59:06 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #91 on: May 28, 2014, 05:58:22 am »
I can't believe the results. I've been chasing this result for over a decade.  I really have to play some games now.  I truly appreciate the work that you and others have done on this project.

Indeed. You've just reminded me that I've been meaning to donate, so I've done so.  Nothing compared to the amount I've wasted over the years on failed attempts. Groovy fixes it all.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #92 on: May 28, 2014, 04:54:38 pm »
Hi vicosku,

https://anonfiles.com/file/6787127cf93cc7a48a520606c5ff2383

At 120 FPS, the first 8 results are:  6, 7, 7, 7, 5, 6, 5, 7

This video looks like it's recorded at 60 Hz, isn't it?
Just in case it could make any difference, my tests were done with -priority 1, -nosleep.

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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #93 on: May 31, 2014, 02:39:53 pm »
All my videos were recorded on an iPhone 5s with the default video app in "slo-mo" mode.  According to the properties shown in Premiere, they are all 120 FPS.  Therefore, the frame counts I've provided should be cut in half for 60 Hz.  I haven't done any editing or conversion.  Sorry that they're so huge, by the way.

I had the sleep option on default, which was 1. I don't see a "nosleep" option.  Is this different than sleep 0?  Anyway, priority was set t 1.  I've made another video with with sleep 0, priority 1, and frame_delay 9.  Sorry that it's vertical this time, but this eliminates the weird diagonal refresh effect from my previous videos.  GM Version is 0.153 on XP64.

https://anonfiles.com/file/57f2012fc9531911296f3edf985c218a
GM 5, 8, 7, 7, 5, 8, 7, 7, 8, 7
69/2 = 34.5/10 = 3.45 Frames of lag per second at 60Hz (Unless my math is wrong, somehow)

Also, I managed to verify that Retroarch is KMS-capable on my machine via the RA wiki and I am able to run it outside of X.  However, I cannot seem to get RA to run at any resolution besides 1024x768 this way.  The RA GUI also claimed to be running at 80Hz.  I couldn't tell whether VSYNC was even working through my Super Emotia at that resolution, so I hooked it up to a 31Khz display.  Sure enough, it was running at 75Hz and vsync was not working despite being enabled in the RA GUI.  Because of this I cannot provide any useful results to compare against those for GroovyMame. 


Edit:  I think my challenges with Retoarch were due to some problems with interference with the laptop's built-in display and with rotation modes.  I'll try it on my desktop when I can and re-run the tests.
« Last Edit: June 02, 2014, 08:59:03 am by vicosku »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #94 on: June 02, 2014, 11:41:27 am »
Hi vicosku,

For some reason your videos seem to show 1 frame of lag more than mine (2 frames in the 120 Hz video). I'm assuming your control is connected by USB. Your new video is much better than the previous one because it shows the scan position.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #95 on: June 02, 2014, 02:28:26 pm »
Thanks.  I misunderstood the results of your video.  I ended up speed and FPS matching our two videos to the best of my ability to understand what you were saying.  Indeed, my results show a delayed response compared to yours.

https://anonfiles.com/file/f99731e09eacd3206b75ba3c0548524b

So, it should be possible to achieve even better results?  It already feels really good, so I find that incredible.  I'll run through this thread again and try other things. 

Yes, my Hori joystick connects via its internal PCB to USB.  I do not have the polling rate increased because I thought it was unnecessary.  I'll start with that. 

Edit: Oh, RawInput.  I didn't really understand that part of the discussion before delving into this.  My joystick is recognized as a 360 controller, and Mame shows that it is using DirectInput.  I assume this explains the extra delay.
Edit 2: To be clear to anyone reading this thread, we will not be certain that DirectInput vs RawInput is the cause for the difference between Calamity's results and mine until I can perform more definitive testing.

« Last Edit: June 04, 2014, 06:17:50 pm by vicosku »

machyavel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 67
  • Last login:December 25, 2016, 10:23:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #96 on: June 03, 2014, 05:42:50 pm »
How do we force raw input?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #97 on: June 03, 2014, 06:01:33 pm »
How do we force raw input?

You can't with current MAME unless you use a keyboard encoder or a mouse. It needs to be implemented for joysticks too at some point.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #98 on: June 03, 2014, 06:04:05 pm »
Thanks.  That's what I gathered, so I ordered an I-PAC.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #99 on: June 03, 2014, 06:08:36 pm »
I ended up speed and FPS matching our two videos to the best of my ability to understand what you were saying.  Indeed, my results show a delayed response compared to yours.

That was an amazing job! Thanks.

Quote
So, it should be possible to achieve even better results?  It already feels really good, so I find that incredible.  I'll run through this thread again and try other things. 

Yes, my Hori joystick connects via its internal PCB to USB.  I do not have the polling rate increased because I thought it was unnecessary.  I'll start with that. 

Edit: Oh, RawInput.  I didn't really understand that part of the discussion before delving into this.  My joystick is recognized as a 360 controller, and Mame shows that it is using DirectInput.  I assume this explains the extra delay.

RawInput may or may not be the problem. As RandyT pointed above, the important aspect of a controller is the time that it takes to decide if a button is pressed or not. So it might as well be a "problem" with that controller. It's impossible to know at this time. At least until raw input for joysticks is implemented in MAME. And maybe then we'll find there's no difference at all, but at least we will know that direct input was not the problem :)
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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #100 on: June 03, 2014, 06:11:28 pm »
Thanks.  That's what I gathered, so I ordered an I-PAC.

Oh! You're faster than me answering. Ok maybe it doesn't mean any difference, we simply don't have enough evidence yet.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #101 on: June 03, 2014, 06:21:21 pm »
Ah, thanks for the clarification.  I needed some sort of interface for another joystick anyway, so the I-PAC won't be a waste.  I'll be able to provide more test results when it arrives as well.  Unfortunately, that supposedly won't be for another 21 days.

While I'm waiting, I'll spend some more time messing around with KMS and Retroarch to see if I can get that working. 

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:February 04, 2021, 10:51:51 am
  • Location: Easy St.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #102 on: June 03, 2014, 06:30:52 pm »
....  I'll be able to provide more test results when it arrives as well.  Unfortunately, that supposedly won't be for another 21 days.
perhaps just use a usb keyboard in the meantime for testing  ;)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #103 on: June 03, 2014, 06:35:17 pm »
perhaps just use a usb keyboard in the meantime for testing  ;)

It's not easy to plug a led to a keyboard ;)
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 of pasting it.

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

machyavel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 67
  • Last login:December 25, 2016, 10:23:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #104 on: June 04, 2014, 04:24:13 pm »
How do we force raw input?

You can't with current MAME unless you use a keyboard encoder or a mouse. It needs to be implemented for joysticks too at some point.

Ok I may be slow but does it mean a keyboard always works through rawinput in mame?

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #105 on: June 05, 2014, 05:59:13 am »
perhaps just use a usb keyboard in the meantime for testing  ;)

It's not easy to plug a led to a keyboard ;)

But some keys have an LED already supplied  :)  Well, every 2 presses numlock LED will come on.
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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #106 on: June 05, 2014, 12:00:44 pm »
Ok I may be slow but does it mean a keyboard always works through rawinput in mame?

Yes, unless you force it to use DirectInput by compiling it with a special flag (people do this to be able to use joystick-to-keyboard software IIRC).

But some keys have an LED already supplied  :)  Well, every 2 presses numlock LED will come on.

Yeah but it's not the same thing, it's the BIOS who controls those leds. I did my first tests posted in this thread by using that technic, it turned out the result was not reliable because the leds took too long to light up.
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 of pasting it.

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

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 645
  • Last login:March 11, 2024, 02:59:06 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #107 on: June 05, 2014, 06:03:25 pm »
Any clue if the SDL lag will be removed?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #108 on: June 08, 2014, 07:16:28 am »
Any clue if the SDL lag will be removed?

I'd like to target that at some point, although fixing that will involve going through the whole graphic layer stack as we have no clue where exactly the problem lies. Maybe it's wiser to bypass the whole thing and address the video card through kms after all.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #109 on: June 11, 2014, 10:34:49 pm »
My I-PAC arrived today! Quite the surprise.  Here are the results.  Note that the button is pressed when the LED turns off this time.  Also, I've added multi-threading and can run with frame_delay 9 without problems now.

https://anonfiles.com/file/a29c7c59bd6705fe67d7e57b4dd7bd84

The input lag on my setup now appears as low as that shown in Calamity's videos.  Just to make sure that none of my other changes were responsible, I tested two DirectInput devices again:  a Hori joystick, and a Raphnet Game12. In both cases, my lag was increased to that shown in my previous video.  I'm comfortable saying that Raw Input can reduce lag by at least 1 frame compared to Direct Input in MAME, as others have suggested.  Or at least, an I-PAC or J-PAC can provide this result compared to the two aforementioned interfaces.  I've got some wiring to do.

Also, I did mess with KMS a little bit a week ago.  I've included that video result in the archive as well.  It was done on a 31Khz display at 60hz.  I pressed CTRL+ALT+F1 and then ran Retroarch as root.  The results were slightly better than those when I launched from X, so I assume I did everything right.  They still weren't as good as GM in XP with CRT_Emudriver though.  Note that this was not done with an I-PAC but with my Hori HRAP EX-SE again, so I guess the result should be compared to my previous video.  Calamity, if you think it would be of value, sometime I can try some more KMS tests with the I-PAC or other variables changed.

In summary, these are the best averages I achieved with each scenario.  These numbers count frame 1 as when the LED indicates input occurred and conclude on the frame when action was displayed, inclusive.

X Retroarch 1.0.0.2 Mame Core .151: 5.1333 Frames
GroovyMame .153b XP64 Frame_Delay 9 Direct Input: 3.125 Frames
KMS Retroarch 1.0.0.2 Mame Core .151 (Same input device as above): 4.75 Frames
GroovyMame .153b XP64 Frame_Delay 9 Raw Input via I-PAC: 1.667 Frames

« Last Edit: June 11, 2014, 11:06:35 pm by vicosku »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #110 on: June 12, 2014, 08:34:16 am »
Awesome job vicosku!

Thanks a lot for your tests. I'm so glad that you could replicate my results there by using the I-PAC & raw input. This is the first confirmation that we have outside of my own testing.

I agree Direct Input is probably the culprit. This hopefully serves to encourage the implementation of raw input for joystick devices in MAME. Only then we would be able to do a fair comparison between joystick and keyboard encoders.

Quote
Calamity, if you think it would be of value, sometime I can try some more KMS tests with the I-PAC or other variables changed.

Definitely, KMS & I-PAC results would be very revealing, I would be grateful if you could eventually test this. I dare to say there might still be a little advantage for GM thanks to the frame delay implementation.

Thanks again!
« Last Edit: June 12, 2014, 08:38:10 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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #111 on: June 12, 2014, 11:14:08 am »
You're welcome!  I'd be glad to perform more tests.  I have a pretty busy week ahead, so it may take me some time, but I'm certainly eager to see the results as well. 

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 645
  • Last login:March 11, 2024, 02:59:06 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #112 on: June 12, 2014, 12:17:51 pm »
Kind of off topic, but if GM used KMS would it still require X at all?

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 687
  • Last login:March 10, 2024, 04:41:43 am
    • SCART Hunter
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #113 on: June 12, 2014, 05:15:00 pm »
In summary, these are the best averages I achieved with each scenario.

Nice work! Thanks for sharing your results.

This thread has been a fine read so far...
My MAME/SCART/CRT blog: SCART Hunter

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #114 on: June 13, 2014, 06:36:14 am »
Kind of off topic, but if GM used KMS would it still require X at all?

I'm not sure. I mean the osd relies on X for the most part I believe, so I'd say it would require some major refactoring of the osd layer. Maybe it is easier to simply bypass X on the relevant points.
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 of pasting it.

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

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 645
  • Last login:March 11, 2024, 02:59:06 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #115 on: June 13, 2014, 09:23:43 am »
Correcting myself - I meant would an X server be required or not? Not sure why I'm asking the question (my chosen frontend requires it).

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #116 on: June 18, 2014, 06:28:35 am »
Correcting myself - I meant would an X server be required or not? Not sure why I'm asking the question (my chosen frontend requires it).

I meant that you can certainly modify MAME to run without an X server but I'm not sure how deeply it must be changed to achieve it, whether you need to create a brand new osd layer (RA approach) or it is enough to modify the existing SDL osd to remove any existing dependencies. Anyway I find much more appealing to respect the current osd and simply bypass SDL around the point where the lag resides: frame flipping. So if you can manage frame flipping directly you can get rid of any hypothetical frame queue. At the same time we could manage mode setting directly too, bypassing xrandr.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #117 on: June 20, 2014, 10:46:13 am »

Definitely, KMS & I-PAC results would be very revealing, I would be grateful if you could eventually test this. I dare to say there might still be a little advantage for GM thanks to the frame delay implementation.


I finally ran the Retroarch KMS test with the I-Pac.  Lag was markedly reduced, but not to GroovyMAME levels.  Again, this is 120FPS and input is received when the LED turns off.

https://anonfiles.com/file/bf5fdc4f6e7eafe8ea5ce2ccbd87d2fb

10 samples at 120FPS: 6,6,7,7,7,5,6,6,6,6

Frames displayed as button is pressed until action is seen: 3.1

Edit: This test was performed at 75Hz and should not be used for comparison against the other results at 60Hz.
« Last Edit: June 22, 2014, 07:00:36 pm by vicosku »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #118 on: June 22, 2014, 04:53:17 pm »
Hi vicosku,

Thanks again for your test, much appreciated. I've been watching your new video, and I notice the game can't be running at 60 Hz, it's probably being displayed at 75 Hz or similar, just like you mentioned some posts above. However, in your video from june the 12th KMS was running at 60 Hz, which is the ideal situation. So the frame count could be affected by this, even though what we actually count are the camera frames, not the game frames, and those are constant among videos, but the proper comparison should be with both videos running at 60 Hz side by side. Although I believe your new video already proves what we intended to prove, I want to be extra cautious before claiming anything.
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 of pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #119 on: June 22, 2014, 05:55:58 pm »
You're right.  It was 75hz again.  I must have gotten lucky with a kernel option to get 60hz before, but I don't remember what I did.  I'll try to set it up, but I'm pretty clueless with this KMS video mode stuff.  Most of the instructions I find by Googling don't seem to perfectly apply to Ubuntu 14.04.  If someone can give me some fool-proof instructions on how to change the resolution and refresh rate in this scenario, it would help me immensely to provide better test results.  I'll try on my own in the meantime.