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

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

  

Author Topic: Raw Input versus Direct Input input lag testing  (Read 9999 times)

0 Members and 1 Guest are viewing this topic.

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Raw Input versus Direct Input input lag testing
« on: April 30, 2015, 09:20:09 am »
Hey Calamity. If I sent you a SFIV fight stick (it's basically an Xbox 360 pad internally), would you be willing to do some input lag tests to compare the difference between Raw Input with a keyboard and the USB joystick?

I want to prove once and for all that Raw Input is more responsive than Direct Input.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6737
  • Last login:Today at 12:57:56 pm
  • Quote me with care
Re: Raw Input versus Direct Input input lag testing
« Reply #1 on: April 30, 2015, 09:33:32 am »
I'd would be definitely interested in testing this. I'd need to figure out how to wire a led to it, assuming it is possible and the buttons work at 5V.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #2 on: April 30, 2015, 09:46:34 am »
I'd would be definitely interested in testing this. I'd need to figure out how to wire a led to it, assuming it is possible and the buttons work at 5V.

PM me an address, and I'll send you the stick.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:Today at 12:54:54 pm
  • 0x2b|~0x2b?
Re: Raw Input versus Direct Input input lag testing
« Reply #3 on: April 30, 2015, 12:48:52 pm »
No one was debating you about not using DirectInput for keyboard or mouse input. MAME uses RawInput for keyboard and mouse anyway so don't bother. The assertion you made was that DirectInput is "more laggy" than using RawInput for reading joysticks. So that's what you should be profiling. While you're at it why not test the performance difference between PS/2 and USB I-PAC encoders?

rCadeGaming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1255
  • Last login:September 22, 2019, 08:04:40 am
  • Just call me Rob!
Re: Raw Input versus Direct Input input lag testing
« Reply #4 on: April 30, 2015, 08:01:22 pm »
I don't have any numerical results on hand, but I can give you some anecdotal evidence I remember from when I was lag testing a few months ago.

I was using a KADE (usb keyboard encoder - RawInput) and some MC Cthulhu's (usb joystick encoder - DirectInput).  When only one Cthulhu was plugged in, it seemed to perform just as well as the KADE, but when I plugged in a second (1 is needed per player) lag increased measurably.  I think the KADE was generally more consistent as well.  I think I still need to test multiple KADE's plugged in at the same time.

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #5 on: April 30, 2015, 08:30:32 pm »
No one was debating you about not using DirectInput for keyboard or mouse input. MAME uses RawInput for keyboard and mouse anyway so don't bother. The assertion you made was that DirectInput is "more laggy" than using RawInput for reading joysticks. So that's what you should be profiling. While you're at it why not test the performance difference between PS/2 and USB I-PAC encoders?

The choices for MAME today are some kind of keyboard encoder with Raw Input or a USB gamepad using Direct Input. That's it. That's what we're comparing, and what I've always said we were comparing from the beginning.

I'm waiting for your MAME submission that's going to magically support every USB gamepad using Raw Input. Until then, it's a keyboard encoder or a joystick with direct input.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:Today at 12:54:54 pm
  • 0x2b|~0x2b?
Re: Raw Input versus Direct Input input lag testing
« Reply #6 on: April 30, 2015, 11:05:30 pm »
The choices for MAME today are some kind of keyboard encoder with Raw Input or a USB gamepad using Direct Input. That's it. That's what we're comparing, and what I've always said we were comparing from the beginning.

I'm waiting for your MAME submission that's going to magically support every USB gamepad using Raw Input. Until then, it's a keyboard encoder or a joystick with direct input.

You're the one singing praises for RawInput when I said DirectInput is perfectly fine for reading joysticks. You're the one saying DirectInput is laggy and I'm the one saying the performance difference would be negligible. Not once did I mention using DirectInput for keyboard or mouse. Everyone knows you shouldn't use DirectInput for keyboard or mouse even before it was deprecated.

By all means compare performance using as USB and/or PS/2 keyboard encoder with RawInput and a joystick using DirectInput. I could even ask Andy (of Ultimarc) to donate a USB and PS/2 I-PAC just for this test. Just say the word and I'll shoot him off an e-mail.

BTW Why should I submit RawInput gamepad support for MAME when you're the one saying "Raw Input or don't even get out of bed."? I'm the one saying DirectInput is perfectly fine for reading gamepads.
« Last Edit: April 30, 2015, 11:16:10 pm by headkaze »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #7 on: May 11, 2015, 12:53:46 pm »
Bulbousbeard, was there a problem with my results from last year, or are you just trying to bolster them with additional testing?  I just want to make sure people know that this has been verified before.  It will be nice to have some more recent tests from someone else since the videos I posted are no longer available.  I can record new ones without much trouble though.  My setup is more convenient for such testing now.

« Last Edit: May 11, 2015, 01:02:04 pm by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 81
  • Last login:September 26, 2019, 05:33:08 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #8 on: May 12, 2015, 08:36:31 am »
I'm the one saying DirectInput is perfectly fine for reading gamepads.

By all means and respect for you as a person and your awesome skills, but this time i think you are wrong with your statement. Just click the link of vicosku and you will not find a single comparison in the whole thead, where direct input is superior over raw-input. Judging by the thread, Direct Input creates more lag and it is proved by doing many real life tests with huge effort and different setups.

Maybe I am wrong, but the thread is the main reason, why I wouldnt recommend any cab-builder to buy the cheaper usb-encoders (they are even more worse in 2 or 4 player setups, because it gets even more lag, from what I have read)  for their setups.
I hope you still like me now  ??? , because it is really nothing personal.

greets u-man
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #9 on: May 12, 2015, 10:27:51 pm »
The system I run GroovyMAME on now is completely different from the one I used to test last year.  As a result, I've been meaning to run some new tests to verify its input lag.  This thread is good motivation to do some. 

Here are DirectInput and RawInput results with an I-PAC2 I recently procured.  I've provided links to the 240FPS videos so they can be verified by others (Sorry about my hairy arm in the shot).  They contain 60 samples each, but I only bothered counting the first 10.  Frame_Delay was set to 0 for this test to keep it out of the picture.  The game used was Street Fighter II.

DirectInput - 2.35 Frames of Lag
RAWInput - 2.4 Frames of Lag

Surprised?  I was!  I made sure that the button being pressed was configured to only act as a RAWInput keyboard button in one test, and a DirectInput joy button in the other.  So what is going on here?  Was the Direct Input delay I recorded last year due to Windows XP?  Is it not present in Windows 7?  Did I make a mistake somewhere?  Is something else at play?  I don't know, but it seems like on my newer system there isn't any appreciable difference between Direct Input and RawInput.  If anyone else wants me to perform any additional testing, let me know what variables you would like to change.

Specifics:

CPU - Pentium G3258
Motherboard - MSI H81m-P33
Video - ATI 4550 with CRT EmuDriver
OS - Windows 7 x64 SP1
Interface - I-PAC2 DirectInput/RawInput
Mame Version - GroovyMAME .156 with ASIO patch
ROM - SF2

Logs:

DirectInput
RawInput

Edit - Grammar
« Last Edit: May 12, 2015, 10:54:35 pm by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 81
  • Last login:September 26, 2019, 05:33:08 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #10 on: May 13, 2015, 07:31:32 am »
thats interesting.... would never expect that, to be honest. So Headkaze statement is right then... i apologize my last post given these results, i hope he understand that.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #11 on: May 13, 2015, 08:16:30 am »
thats interesting.... would never expect that, to be honest. So Headkaze statement is right then... i apologize my last post given these results, i hope he understand that.

Yes, it seems that way in Windows 7, at least.  I think that using the IPAC2 for both tests should be a better comparison between APIs than using different PCBs like I did before.  I suppose it's also possible that the extra lag from my Windows XP testing was attributable to the Hori EX-SE (Xbox 360) and Raphnet Game12 PCBs I was using.  According to this Shoryuken thread, some of the PCBs recorded have shown to lag over a full frame, so I think it's possible.  If anyone else wants to test, picking a PCB that has been proven to exhibit close to no lag would be necessary. 

GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6737
  • Last login:Today at 12:57:56 pm
  • Quote me with care
Re: Raw Input versus Direct Input input lag testing
« Reply #12 on: May 13, 2015, 08:29:11 am »
Hi vicosku,

Thanks a lot for your new tests. How did you switch between Direct Input and Raw Input? Did you compile specific MAME binaries for each test?

Besides, to be totally sure you should indeed enable frame_delay to its highest possible value. This way you will expose any residual lag that might be introduced by each api, which otherwise might get masked by the default frame buffering. I'm telling this because from recent tests we now that figures below 2 frame count are usual these days.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #13 on: May 13, 2015, 11:13:40 am »
Hi Calamity,

The IPAC version 2 can have its individual inputs changed from keystrokes to joypad buttons using the WinIPAC software.  I believe this is a new feature over the older version I tested with last year.  You can see from the logs that the "I-PAC 2" was detected and is using Direct Input.  In the case of this test, I used WinIPAC to change 2PSW1 from the "A" keystroke to the "joy #0 button 1" input.  I then went to the game specific input menu after the game was launched and changed the player 2 button 1 input to use only "A" in the RAWInput test, and only "Joy #0 button 1" in the Direct Input test.  Let me know if you have any concerns about this.

Thanks for the info; I'll do another test with Frame_Delay 9.  I wasn't sure if its use was relevant to this test.  I'll also record the settings mentioned above so that you don't have to take my word for it.  Please let me know if you would like me to change any other variables, the GroovyMame version, or game.  I can run SF2 at around 3000% speed I believe, so there shouldn't be any problems with Frame_Delay 9.  I like CPS games because they have that handy input screen in the DIP menu, but I'll use something else if you prefer.

*Edit - I had a thought of something else I would like to change for the next round of testing.  If you watch my videos, you can see that the number of 1/240 frame counts between input and result changes depending on what vertical quarter of the screen is refreshing when input is received.  To combat this, I think it would be ideal to activate all inputs simultaneously in order to have pixels change in as much of the vertical area as possible.  Perhaps there is a better game to use for this.  I'll look into it, but this may delay my next round of tests a bit.
« Last Edit: May 13, 2015, 11:56:22 am by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6737
  • Last login:Today at 12:57:56 pm
  • Quote me with care
Re: Raw Input versus Direct Input input lag testing
« Reply #14 on: May 13, 2015, 01:08:48 pm »
The IPAC version 2 can have its individual inputs changed from keystrokes to joypad buttons using the WinIPAC software.

Brilliant, I had no idea.

Quote
I like CPS games because they have that handy input screen in the DIP menu, but I'll use something else if you prefer.

The cps test screen is perfectly fine and probably far better for testing purposes than other methods we've used.

Quote
*Edit - I had a thought of something else I would like to change for the next round of testing.  If you watch my videos, you can see that the number of 1/240 frame counts between input and result changes depending on what vertical quarter of the screen is refreshing when input is received.  To combat this, I think it would be ideal to activate all inputs simultaneously in order to have pixels change in as much of the vertical area as possible.  Perhaps there is a better game to use for this.  I'll look into it, but this may delay my next round of tests a bit.

Don't need to bother with that. It's perfectly clear, since you notice the led state change it's easy to figure out which game frame is currently being displayed by looking at the raster position. Instead of counting recorded frames you can just check if the button state changes in the very next full game frame or if it rather takes two frames to react. The later is the case in your video. Theoretically using frame_delay will make it possible to see the action in the very next frame (game frame) for a certain percentage of the samples. If we got that for all frames (not achieved yet) we'd be in the situation to affirm that emulation = pcb in terms of input.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

twistedsymphony

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 580
  • Last login:August 15, 2018, 08:57:58 am
  • Play stupid games... win stupid prizes.
    • solid-orange.com
    • CollectorsEdition.org
Re: Raw Input versus Direct Input input lag testing
« Reply #15 on: May 13, 2015, 01:35:08 pm »
I would be interested in seeing if the direct input numbers changed when there are other direct input devices present.

several people have claimed that when 2 or more joysticks are present the lag gets worse.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #16 on: May 13, 2015, 01:39:10 pm »
Don't need to bother with that.

Ah, thanks.  That will make things easier.  I should be able to post some new videos tonight, in that case.  I'll just keep all the variables the same except change to frame_delay 9. 

I would be interested in seeing if the direct input numbers changed when there are other direct input devices present.

several people have claimed that when 2 or more joysticks are present the lag gets worse.

Okay, I'll attach a Mayflash V2 joystick in Dinput mode as well for a third test scenario.  The LED will still be connected to the IPAC2 in DirectInput mode.
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

2600

  • Trade Count: (+7)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1630
  • Last login:June 05, 2017, 10:20:56 am
  • I want my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #17 on: May 13, 2015, 02:33:07 pm »
I would be interested in seeing if the direct input numbers changed when there are other direct input devices present.

several people have claimed that when 2 or more joysticks are present the lag gets worse.

That could be related to USB and not direct input.  It would be different for every PC, device, hub or no hub, model of hub, etc.
That would probably explain if it happens on some systems and not others.

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #18 on: May 13, 2015, 08:44:00 pm »
Those results are interesting, but I'm almost sure that they're wrong.

How could there be more lag with raw input when--behind the scenes--direct input for a keyboard input would be calling raw input anyway?

It doesn't pass the smell test.

In my own frontend, inputs take fewer cycles to process using raw input than direct input (or xinput).

Like I said, not buying it. Something else is goofy with your setup.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #19 on: May 13, 2015, 09:50:04 pm »
Please provide suggestions to refine the results or to provide better proof and I will do my best to comply.  I have no agenda here other than to provide the best testing and results I can.  I look forward to others providing theirs as well.

Here is my next round of testing.  My .156 results with Frame_Delay 9 were basically no different than what I posted previously.  I find that interesting and have some theories that I will address in the previous GroovyMAME lag thread.  Because of this, I started over with GroovyMame .161 and a fresh mame.ini generated with mame -cc.  The ini folder was empty.  Here are links and results. In the videos I showed the game input screen to show which input was being used for Player 2 button 1.

Raw Input Frame_Delay 9 - 20 Samples - Avg 1.5   -   Log
Direct Input (IPAC 2 Only) Frame_Delay 9 - 20 Samples - Avg 1.55   -   Log
Direct Input with 2 Devices (2nd Raphnet Game12) Frame_Delay 9 - 10 samples - Avg 1.575   -   Log

Screenshots of WinIPAC Configuration and Windows 7 Game Controllers Properties
Spreadsheet with my frame counts
Mame.ini used


GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #20 on: May 14, 2015, 08:13:03 am »
I thought of a better way to conduct these tests.  Both devices being tested should be wired to the same button, and then the two inputs should be mapped to separate Mame buttons.  On the CPS test screen, Player 1 and Player 2's "SHOT1" button indicators occupy the same vertical space. 

This morning I used this test method to compare the IPAC2 in RawInput (Keyboard) mode to a cheap Mayflash V2 joystick with the XInput/Dinput switch in the Dinput position.  There were differences 25% of the time, with the Mayflash being a full gameplay frame slower.  Please review the spreadsheet and video for those details.  I don't think averages are useful here.  Player 1 is the Mayflash, player 2 is the IPAC as before.

RawInput Ipac2 vs Dinput Mayflash V2 - Log

I would like to perform this test again with the IPAC against itself in both modes, but am out of time this morning.  In both separated tests, it never went above 8 frames at 240FPS, and I wouldn't expect it to in a simultaneous test either.  The Mayflash went to 9 and 10 repeatedly.  I believe this is the fault of the Mayflash's PCB, not DirectInput.  We need more data, but at the moment I think it is likely that the average PCB is laggier/more inconsistent than an I-PAC in either Keyboard or Gamepad mode.  I wish I had a PS360 to test against.

« Last Edit: May 14, 2015, 10:57:24 am by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

Malenko

  • KNEEL BEFORE ZODlenko!
  • Trade Count: (+58)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 13665
  • Last login:June 07, 2019, 05:07:28 pm
  • Be the change you want to see in the world.
    • forum.arcadecontrols.com/index.php/topic,142404.msg1475162.html
Re: Raw Input versus Direct Input input lag testing
« Reply #21 on: May 14, 2015, 08:31:30 am »
Those results are interesting, but I'm almost sure that they're wrong.

What were the results of your extensive testing BB?
If you are helping someone and expecting something in return, you are doing business not kindness.

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:August 11, 2019, 08:35:42 pm
  • Location: Easy St.
Re: Raw Input versus Direct Input input lag testing
« Reply #22 on: May 14, 2015, 09:32:51 am »
hey vicosku I just want to say MANY THANKS FOR YOUR TESTING!

ps. to the groovymame forum, this is jadder here, my nick now changed to 'adder' (I lost some weight you could say haha)  :)

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 81
  • Last login:September 26, 2019, 05:33:08 pm
  • I want to build my own arcade controls!
Re: Raw Input versus Direct Input input lag testing
« Reply #23 on: May 14, 2015, 09:33:46 am »
Those results are interesting, but I'm almost sure that they're wrong.

What were the results of your extensive testing BB?

good point :D
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6737
  • Last login:Today at 12:57:56 pm
  • Quote me with care
Re: Raw Input versus Direct Input input lag testing
« Reply #24 on: May 14, 2015, 04:37:30 pm »
Both devices being tested should be wired to the same button, and then the two inputs should be mapped to separate Mame buttons.  On the CPS test screen, Player 1 and Player 2's "SHOT1" button indicators occupy the same vertical space.

That was really witty.

I've been watching your videos. Considering you get a count of 1.5 in your previous videos this means that 50% of the times the input is processed just in time for the next frame. I'd say this is the best result we've seen so far, quite close the ones by rCadeGaming but slightly better.

This 50% seems to match with the samples taken when the led state changes while in the first half of the previous frame. This would be consistent with an input processing time of half the duration of a frame. If we assume a frame to last 16.77 ms (at 59,60 Hz), it would mean that from the instant you press a button to the moment MAME is notified of it, it takes around 16.77 / 2 -> 8 ms.

Quote
There were differences 25% of the time, with the Mayflash being a full gameplay frame slower.

That 25% compared with the previous result would imply an additional delay of 0.25 x 16.77 / 2 -> 2 ms. Then 8 + 2 = 10 ms.

This means there's seems to be a difference of 8 ms vs 10 ms. This could very well be due to the actual pcb being slower rather than the API itself.

IIRC the Microsoft documentation says DirectInput involves more overhead than Raw Input because it needs to create a separate thread for input polling or whatever it does. I already said in the other thread that more overhead not necessarily means more lag at the scale we're working at, specially as systems get faster. However till now tests seemed to be confirming that DirectInput was noticeably more laggy. Maybe it could be just that the input hardware we were testing was slow to react (as Randy Fromm suggested).

Regarding 0.156 not making a difference with -frame_delay, while 0.161 does, I'm a bit puzzled about that, because the relevant frame_delay improvement  was introduced in switchres 0.015d which is the one 0.156 uses. Wondering if the ASIO build has anything to do.
« Last Edit: May 14, 2015, 04:39:56 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #25 on: May 14, 2015, 10:02:34 pm »
Thank you all for the kind words.  Glad to be of service.  Calamity, it was rCadeGaming's posts that motivated me to finally switch to Windows 7, so I'm glad I was able to duplicate his timings.  I was pretty surprised that I had been operating with an unnecessary frame or two of lag for the past few months.  I won't presume that I'll always have optimal results when making changes from now on.  I expect you're right about the ASIO patch being responsible, but I'll do some tests later in attempt to verify and pick it up in the previous thread.  Thanks for all the detailed information.  Randy's posts make a lot more sense to me now then they did back then.  I think he was right as well.

I have the IPAC RawInput vs IPAC Direct Input results on the spreadsheet now.  I decided to count 60 results this time, and it's a good thing that I did.  Something interesting happens at the 25th button press.  In this sample, the Direct Input button indicator (1PSHOT1) responds after just 4 frames @240FPS, but the RawInput (2PShot2) button does not. It responds a full gameplay frame later.  This repeats two more times immediately after.  However, in the 33rd sample, the results are reversed with RAW Input responding 1 frame before Direct Input.  I'm not sure what to make of this, but I find it interesting that it only happens in cases where one of the inputs is reflected 4/240 frames after the button is pressed, and how rarely this happens.  All other samples I counted are identical, and none go beyond 8 frames at 240FPS like the Mayflash PCB did. 

Video - IPAC2 Raw Input vs Direct Input Simultaneous Test - Log

*Edit - Ignore comments about the ASIO patch introducing lag.  Laggy tests were accidentally performed with Frame_Delay 0.  This problem was resolved in all subsequent tests discussed by removing the ini folder from the mame directory and only manipulating settings through mame.ini directly.
« Last Edit: May 29, 2015, 11:58:02 am by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

Malenko

  • KNEEL BEFORE ZODlenko!
  • Trade Count: (+58)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 13665
  • Last login:June 07, 2019, 05:07:28 pm
  • Be the change you want to see in the world.
    • forum.arcadecontrols.com/index.php/topic,142404.msg1475162.html
Re: Raw Input versus Direct Input input lag testing
« Reply #26 on: May 15, 2015, 07:29:31 am »
vicosku, would you mind running this test on a midway game like mortal kombat II?  Just because it runs at a weird refresh Im just curious if it matters at all. You could have player 1 high punch and low punch in the midway test menu take the place of shot 1 from the CPS test menu. Just for my own edification.
If you are helping someone and expecting something in return, you are doing business not kindness.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #27 on: May 15, 2015, 08:59:58 am »
Certainly.  Unfortunately I can only run that game at 1062% speed, so we'll have to settle with Frame_Delay 8.  I was curious about Neo Geo and Street Fighter 3 Third Strike results too, so I threw those in as well.  I can only run those at Frame_Delay 8 too.  Counting frames takes more time than anything else in these tests, so I've only checked about 10 samples each myself so far.  MK2 dipped to 9/240 a few times, SFIII3u stayed between 5-8, and garouh was between 9-13.  Seems like Neo Geo inputs are a bit slower.

IPAC2 Direct/Raw Input Frame_Delay 8 MK2
IPAC2 Direct/Raw Input Frame_Delay 8 SFIII3u
IPAC2 Direct/Raw Input Frame_Delay 8 garouh
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

adder

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 640
  • Last login:August 11, 2019, 08:35:42 pm
  • Location: Easy St.
Re: Raw Input versus Direct Input input lag testing
« Reply #28 on: May 15, 2015, 10:21:25 am »
hey vicosku, I don't know if its helpful but if you don't like your .MOV movie files being quite large (eg. 150mb) you can use the free software called 'handbrake' to convert them to .MP4, this would probably get them down to eg. 10mb-20mb. you can still keep the same frame rate and resolution of your videos etc, it's very flexible and very good regarding options/settings and quality/speed of encoding

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #29 on: May 15, 2015, 10:58:44 am »
Thanks.  I'm aware.  I'm actually doing my frame counts in Premiere.  I just don't want to be accused of tampering with evidence, so I am leaving the videos free of any editing or compression.  I'm lazy and don't want to spend time encoding either  ;)
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #30 on: May 18, 2015, 11:18:07 pm »
Okay Adder, I gave a brief attempt at not being lazy, but I didn't see an obvious option to compress video in Premiere without dropping to 60FPS, so I gave up rather quickly.

Thanks to Twistedsymphony, I was able to test a PS360+.  It's a bit quirky.  No USB port on my machine would recognize it until I attached a hub and connected through it.  As a result, this can also serve as a test with 2 direct input devices connected, the one being tested going through the hub.  Despite this, in the 60 samples I counted, it did not exhibit the 2ms of extra lag that Calamity theorized the Mayflash V2 did.  It equaled the IPACv2 in Raw Input in all but two samples, where it was 1 gameplay frame faster.

240FPS Video - IPACv2 Raw Input vs PS360+ 2.03 firmware 1.66
Log
Spreadsheet (Columns T and U)

I have not been able to find evidence that points to a significant difference between Direct and Raw Input in GroovyMame 0.161 x64 on Windows 7 using the settings in the logs and the mame.ini file I have shared.  I certainly intended to when I started testing.  In fact, of the over 150 direct input samples I've counted for the IPAC and PS360, only 6 showed differences.  Only 1 of those 6 was in favor of Raw Input. 
« Last Edit: May 18, 2015, 11:20:26 pm by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

twistedsymphony

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 580
  • Last login:August 15, 2018, 08:57:58 am
  • Play stupid games... win stupid prizes.
    • solid-orange.com
    • CollectorsEdition.org
Re: Raw Input versus Direct Input input lag testing
« Reply #31 on: May 19, 2015, 08:15:57 am »
Thank you for all the testing work you've done  :cheers:

now I don't have any hesitations about swapping out my IPAC for a pair of PS360s, if there is essentially no lag difference in MAME the better compatibility with modern PC Games that the PS360 provides will be worth the switch, for me at least.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #32 on: May 19, 2015, 03:19:03 pm »
Yes, I'm considering doing the same.  Maybe I'll switch the IPAC2 from keystrokes to gamepad buttons and keep using it on my GM machine.  Keyboard behavior in modern games has been an annoyance lately.  I'll certainly be using the PS360 for consoles. 

By the way, I realized that my previous IPAC is a 2014 IPAC-VE.  The IPAC2 used in all these tests was a 2015 board.  From Ultimarc's download page and what some others have alluded to, I gather that gamepad functionality is a new feature that was added to 2015 boards. 

*Edit - Oh, here's the official info: http://forum.arcadecontrols.com/index.php?topic=142969.0
« Last Edit: May 19, 2015, 04:16:32 pm by vicosku »
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

twistedsymphony

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 580
  • Last login:August 15, 2018, 08:57:58 am
  • Play stupid games... win stupid prizes.
    • solid-orange.com
    • CollectorsEdition.org
Re: Raw Input versus Direct Input input lag testing
« Reply #33 on: March 24, 2016, 10:47:57 am »
I realize I'm bumping an old topic but I came across something and this seemed really relevant to this conversation.

http://www.hackmycab.com/?portfolio=usb-polling​

I'd never heard of anyone modifying the USB polling rate. I wonder how much of an actual difference it makes.

this site suggest increasing the usb polling rate in order to reduce lag when using a JPAC. I wonder if anyone here has ever done that and or tested for that to see how much of a difference it actually makes.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 100
  • Last login:April 01, 2018, 09:12:24 pm
Re: Raw Input versus Direct Input input lag testing
« Reply #34 on: March 24, 2016, 10:53:06 am »
Hi There.  Please review the older thread, where USB polling is discussed quite a bit.

http://forum.arcadecontrols.com/index.php/topic,133194.0.html
GroovyMAME/ASIO Machine Specs for Hardware Discussion and Reference:
MSI H81M-P33, G3258 @ 4.6GHz, Diamond Radeon HD 4890 XOC, Win7x64, HPET Off/bcdedit /useplatformclock True, 2x Sony PVM via powered VGA splitter

TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 788
  • Last login:September 08, 2019, 04:06:27 pm
  • On and off hobbyist
Re: Raw Input versus Direct Input input lag testing
« Reply #35 on: November 30, 2018, 09:09:15 am »
I'm sorry to bring this thread back but I need it for context.

I have been having a terrible time getting AHK scripts to send keys to MAME, and recently found a post on a different forum stating that, for MAME to receive input commands from AHK, keyboardprovider must be set to dinput.  I'll try this later today but it seems like the answer to my problems.

I wonder if vicosku or calamity have compared input lag using rawinput vs. dinput for the keyboardprovider parameter in MAME on the same device.

Besides possibly lag, would there be any other setback in using dinput instead of the default rawinput?
I use a 2001 version of the i-Pac encoder in my cab.
"The Manuel"

buttersoft

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 871
  • Last login:Yesterday at 12:03:36 am
  • Is running at 15kHz
Re: Raw Input versus Direct Input input lag testing
« Reply #36 on: November 30, 2018, 04:26:49 pm »
Besides possibly lag, would there be any other setback in using dinput instead of the default rawinput?

Not that I'm aware of. I can't answer anything about lag though, but i'd be keen for more info if anyone has some.

Regarding using AHK to send keys to MAME - https://www.aussiearcade.com/showthread.php/6415-Limiting-credits-in-MAME?p=1162294#post1162294

TheManuel

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 788
  • Last login:September 08, 2019, 04:06:27 pm
  • On and off hobbyist
Re: Raw Input versus Direct Input input lag testing
« Reply #37 on: December 01, 2018, 12:00:20 am »
Yeah, it would be good to see what the more lag averse folks here have to say.  I was able to find AHK code that worked for me, but requiring dinput.  For my part, I can't notice any difference in my typical subjective evaluation, which consists of using Ken to spam my opponent with hadokens in hsf2  :laugh2:.  Then again, I'm not a super-gamer so I'm not too sensitive to input lag.
"The Manuel"