Input Lag - MAME iteration comparisons vs. the real thing?

[Dacasks]

I did these tests early this year with a really crappy cellphone comparing actual hardware vs groovymame 0.171 Asio. Wonder if the new iterations since 0.171 improved.



(Couldn't figure out how to embend)

... I take the opportunity and ask if anyone knows how to make mame keep its CPU Clock settings saved (slider controls). It's a pain having to downclock it everytime in some game/systems to make on par with real hardware.

[Calamity]

Awesome video! Thanks for sharing.

I'm wondering how it looks when you don't downclock it. Default cpu speed for cps2 is already 74% in stock MAME. What difference does it make that 4%? As long as vsync is enabled, that should be ruling the overall speed doesn't it?

[oomek]

You see Calamity? On the vido there is a moment when the emu does not react. Can it be that missed human induced sub 16ms input trigger we were talking about ?

0:06

[Dacasks]

Hi, thanks for answering!

I think it would be better if I inform also other details about the setup used... I used a "lag free" usb board, it's not the chinese made one ("Zero delay", or something), a guy here in Brazil did it... and it's pretty good so far. And the buttons/stick are also hooked through an Db15 conector, to the jamma harness... I believe the lag input, with the usb part connected to the PC, I don't know if would be possible to have the same amount of lag than a wire connected directly to the jamma harness, and the board itself, which is really "raw", but, as soon as I did this test one day early this year, I was amazed on how it's so close to the original thing, to the point I sold a lot of board that I had. In fact, from whatIi recall, some games like konami games (I had a Vendetta board, TMNT, and I don't remember if I tested Simpsons as well), and, it was really really... you can't really see a difference because I think those games they have less native lag. Capcom games, specially fighting games, they often have some native input lag., so, it's more noticeable when added a little bit.

Now, the %.. I already heard some people, but I couldn't test this too much myself, that some games they are Voltage sensitive in the sense of speed. I don't know much about that, but I do know that people are unnacustomed with real speed on some games. I think the most clear example is Street Fighter 2 Hyper Fighting. Most emulators by the default runs the game EXTREMELY fast, since, forever. The only emulator that I know which is on par with real hardware, is the old Callus emulator. If someone wants to know the speed of the real thing, run callus and see it. Finalburns, Kawaks, nébulas, all these... and mame itself, it's too fast, like, fast, fast, It's not a little bit, it's fast fast, ridiculous fast. The Hyper Fighting speed is a little bit more than Champion Edition, not like, Turbo 3 Speed on Super 2x/Turbo.

So it was really by eye, really. Because.. I don't have all the... skill and... the electronics things to measure, but, I tried to reach a point where I could feel like I was playing my real boards. And 70% for cps1 and 2 games,I think it's good overall, but some games you can't really tell difference, for more, or less. Some exceptions are Ghouls n Ghosts, I can see some slowdowns in some parts, I never had a ghouls n ghosts original board, I did had a conversion, but, I needed to make more tests, but it's okay 100%, I like to use circa 74%, it get rids of these slowdowns in some heavy parts...
Carrier Air wing, the intro, in the original board, when the plane takes off and leaves the burning from the jet behind, in the original hardware it's really slow, like, heavy slowdown, and using the default 100% it makes the intro smoother, so it's also an example of wrong speed compared to the original hardware. At least from the boards that I have/had, running it through 5v.

And yep, some inputs they don't react right? By a really small margin.

(my english is terrible btw if write it too fast so, sorry! =D )

[Calamity]

You see Calamity? On the vido there is a moment when the emu does not react. Can it be that missed human induced sub 16ms input trigger we were talking about ?

0:06

Exactly.

Hardcore Street Fighter players often complain some combos are harder to achieve or just impossible with MAME compared to the pcb. This could be the final confirmation (and the good news is we might already know the reason, it's a shame Dacasks sold his boards so we could abuse him asking for more tests).

[Dacasks]

Well, I do have some boards yet. Actually… I think… yeah, I think I still have the same boards I used in the video. I do have… Sf2hf with the cpsdash motherboard, which runs at 12mhz oppose to the 8mhz of “vanilla” cps1 boards… But I also have a Carrier Air Wing, and a Unsquadron board… Magic Sword… mainly Capcom games because I like it. I have a Taito F3 with Darius Gaiden, I could try it as well… Capcom Zn boards, like Rival Schools, still have I guess, which runs really well too
But the setup would be the same, with the same crappy câmera, and that’s the problem I guess because… it’s really, how they say.. “ghetto”, even the setup itself, I just hook up the things in the most quick way and… But one thing that I could try maybe, one day, is see… I never actually , I heard about something of increasing the polling rate of USB, I didn’t that, as far as I remember, so I could try that too.… and of course using a newer version.
But yep, if there’s something special that I could try that I didn’t… with the same boards, let me know… But mostly boards, from what I tested (I was no… museum by the way, I had some few more boards than what I have now), it was really spot on, this clock stuff… and, it could be  a “Mame” thing right, maybe not video related anymore. Like, even the skippy inputs. Maybe the game it’s running a little bit faster, or slower, on the emulator, other things going on, I don’t know.

I tried shmupmame, and today with Gsyng/Freesync monitors, shmupmame it’s great because it syncs well… but, you can feel that, it’s even, faster than the real hardware like, really sensible, like, more lagfree than the real thing, to the point you start to understand why programmers they sometime add input lag for purpose, don’t know, it feels weird sometimes, and I heard that some games got broke in the process.  I do think Groovymame is the… closest… thing. And I don’t know if it reaches a plateau, the Mame part itself, when, there are other things involved. Even gaming programming, like, I already heard the Super Turbo and some revisions of other Street Fighter they have some high degree of randomness going on, like, bugs and… input flaws and stuff, so even the original hardware is skippy with these aspects, because of voltage, because of the hardware itself, like, electronics level stuff. For example, I already had two Night Warriors boards, with differents motherboards, and, at Jon Talbain stage, it had mad flickering, like, the lamps, and stuff, in the foreground and background? Even the characters and, since were two of them… I think it’s a game/hardware issue, right? Because on emulators it’s not like that, even decreasing the clock, it didn’t have that heavy flickering… so I guess there’s some kind of degree of accuracy “perfection” that… even real hardware can’t reach often sometimes. There are guys complaining about combos and stuff… but sometimes  it’s really not like playing on real hardware, and In my humble opinion it will never be, because even on real hardware, it’s not perfect sometimes depending on the setup, the electronics, voltage, and etc. But it’s the closest thing, and it’s great as it is already. I mean, think about how much money one would have to spend to play these games close to the real hardware, and these things sometimes are like bombs you know, they just stop, and boom, it’s over, no repair, no anything, so yeah, it’s a great service.
But let me know if I can do something to help sometime =)

[Dacasks]

Had the opportunity to try the most recent 0.180, and, the d3d one works great just like the 0.171 I guess. The only problem is the Asio support, I guess there isn't an Asio build right now? Regular Mame sound really comes off once you get used to the low latency audio of Asio.

Wish they improved the console drivers tho, guess they aren't focusing too much on it now. Still waiting to play PS1 Doom under Mame  (it's glitched :/). CPS2 romset changed as well, I guess... wonder if improved anything.

[keilmillerjr]

I was wondering the same thing about asio support? I am finally almost ready to actually install my mame build in a cab. Only took 3 years. Updated everything to 0.180 and they was like what happened to asio updates? Why isn't this sound driver included in base mame? Is it a hack?

[intealls]

Why isn't this sound driver included in base mame? Is it a hack?

There's a number of reasons. Firstly, with XAudio2, latency has been reduced somewhat.

Also, ASIO is not really compatible with the MAME license (GPL).

I have a semi-working PortAudio implementation that does everything the previous ASIO build did (low latency audio + sinc resampling for the final mix), but uses WASAPI as the main API instead. It's possible to build PortAudio with ASIO, but it would be illegal to redistribute this binary. If I find the time I could clean this up and post a patch/build.

[Recapnation]

So it was really by eye, really. Because.. I don't have all the... skill and... the electronics things to measure, but, I tried to reach a point where I could feel like I was playing my real boards. And 70% for cps1 and 2 games,I think it's good overall, but some games you can't really tell difference, for more, or less. Some exceptions are Ghouls n Ghosts, I can see some slowdowns in some parts, I never had a ghouls n ghosts original board, I did had a conversion, but, I needed to make more tests, but it's okay 100%, I like to use circa 74%, it get rids of these slowdowns in some heavy parts...
Carrier Air wing, the intro, in the original board, when the plane takes off and leaves the burning from the jet behind, in the original hardware it's really slow, like, heavy slowdown, and using the default 100% it makes the intro smoother, so it's also an example of wrong speed compared to the original hardware.

Could you elaborate a bit more on all that with better phrasing, please? I'm not sure if you do know that 74 % is "MAME default" for CP-S since you mention "100 %" many times, and if you really notice a difference when setting it at 70 % instead (from 74 %). Also, how's exactly your set-up (regarding control connection)? Tests like this are getting harder and harder to get and you could even get something useful to send to MAME Dev. CP-S 1 & 2 speed issues are well-known and it all depends on properly emulating wait states, it seems, but F-3 tests could well be a novelty.

Thanks!

[Dacasks]

The setup  was just an arcade stick hooked both to the jamma harness (pcb) and to a usb interface (Groovymame), which so far has unnoticeable lag (probably not lag free, I suppose, but I don't have the tools to measure that)

Yep, I know that CPS 2 driver has 74% by default. The CPS 1 games as I said are totally off at 100%. But as I said... it's something really based on personal feeling, I don't have the tools to measure ms input and all of that stuff, if someone could point, I could maybe try something a next time

For example, Street Fighter Zero 3 using real hardware, if you pull a Shoryu Reppa with Ken, Level 3, the trailing shadows they produce some kind of slowdown, like, frame skipping on the real hardware. By using 74%, this slowdown doesn't happen on Mame, at least not often as the real hardware, which sometimes also doesn't happen depending on what is on screen, but's more often. By using 70% (I used to leave it on 68%, but by throwing Hadoukens at the same time, on real hardware and Groovymame, I realized that the speed of the game was a little bit off at 68%), the game behaves more like I feel it's the real hardware. But as I said, it's something purely based on personal feeling and on basic screen test, without any kind of deep measuring. I could be totally wrong, maybe 74% it's the right % or nearest to the real hardware, but, I just felt it was better. Besides, CPS1 and 2 they share similar hardware, so, if at 70% CPS1 behaves almost like real hardware, and 74% shows a little bit off, then... maybe 70% for both machines would be better.

I already saw some posts here and there in some forums, even reddit from what I remember... of people complaining about Street Fighter 2 Hyper Fighting speed, which is ridiculous compared to real hardware, and I already saw some mamedev kind of... almost, kind of "reluctant" to get into the issue more, I don't know why. Some people believe it's the 12mhz - 8mhz difference between the ordinary CPS 1 motherboard compared and the CPSDash (which original Hyper Fighting boards came equipped with), but, I already had the opportunity to try Hyper Fighting on a 8mhz board, and honestly, couldn't tell the difference at first, but maybe it has some with possible slowdowns, but, then again, it's another example of something that's going for ages now. And that's saying a lot because Capcom fighting games have a huge following, like, there are sites, like shoryuken and other forums that are dedicated most to capcom arcade fighting games, so, who am I to do something about it

[Dacasks]

Btw, tried Ghouls n Ghosts on Callus yesterday.

The slowdowns that I said are there, in some parts (most notably at the little "mountain" part with shooting flowers and those worm things raising off the ground at the end of stage 1 if lot's of action is on screen)

So... if Callus has the correct speed for most games, then, maybe its another example of 70% being more appropriate (at least for CPS 1 games)

[Recapnation]

In case you haven't read the comments here and want to post your findings:

http://mametesters.org/view.php?id=408

But as long as wait states aren't properly emulated, there's not much use. Input lag is another matter, though.

[Dacasks]

I'll think about it. Tried this week a little bit of SF2HF again... and yep, 70% it's the closest speed I could find to the original hardware, time clock speed, and everything... it's just a little bit off, I guess it has to do with non emulated features as you said.

I just realized that if you save state, the Clock% setting is also saved... so I made a hotkey combination with the Arcade Stick to Load/Save states whenever I want to play CPS games.

[oomek]

I've made a little picture visualising missing input events as it has been shown in the recently posted video.
What can be done is to delay the key_up event when there is another key_down event occurring in the same frame.
Regarding the button presses shorter than 1 frame: delay the key_up event  when key_down and key_up occurring in the same frame, but only when key_down is first, to avoid not releasing a button if the button is released and then pressed again within 1 frame.
Delaying just the key_up events unconditionally by 1 frame will not work I suppose, as it may add unnecessary delay in input processing.

[oomek]

I could program some macros in Arduino emulating input sequences with transitions shorter than 1 frame to see how it behaves.

[lettuce]

Why isn't this sound driver included in base mame? Is it a hack?

There's a number of reasons. Firstly, with XAudio2, latency has been reduced somewhat.

Also, ASIO is not really compatible with the MAME license (GPL).

I have a semi-working PortAudio implementation that does everything the previous ASIO build did (low latency audio + sinc resampling for the final mix), but uses WASAPI as the main API instead. It's possible to build PortAudio with ASIO, but it would be illegal to redistribute this binary. If I find the time I could clean this up and post a patch/build.

That would be great!, so it would be as good a ASIO then?

[jimmer]

I've made a little picture visualising missing input events as it has been shown in the recently posted video.
What can be done is to delay the key_up event when there is another key_down event occurring in the same frame.
Regarding the button presses shorter than 1 frame: delay the key_up event  when key_down and key_up occurring in the same frame, but only when key_down is first, to avoid not releasing a button if the button is released and then pressed again within 1 frame.
Delaying just the key_up events unconditionally by 1 frame will not work I suppose, as it may add unnecessary delay in input processing.

This is interesting because I've just started to program my encoders myself (also arduino).

I was wondering if we need to adjust the encoder for different joysticks because they have different sized diagonal zones. But I suppose the player adapts his technique to make the move register. ie the speed of execution down/downright/right determines the overlap on the input.

What's the tolerance on say streetfighter2 registering a move?  Does it need to see the necessary inputs on succesive frames or can you be slower than that.   eg does a poll of down/down/downright/downright/right  give you  whatever down/downright/right does?

[oomek]

If for example down released and right pressed are registered in the same frame the downright won't be registered. The downright position even as long as 16ms may not be registered.

[jimmer]

I think it's clearer to should the polling as a discrete event:

This diagram also shows how lengthening the key release (ie a longer hold on the key) could spread say the input across more more polling points.  Hence my previous question about a poll of down/down/downright/downright/right

[oomek]

My graph is showing quantized key down/up events sent by the device while yours a logical key value for specific frame. Anyway on the bottom part you drew one pair of down-right too much.

[jimmer]

now I've thought some more, I understand your diagram even less 

Is your POLL line the encoder polling the button, or the PC polling the USB encoder, or the game rom polling MAME ?







Maybe I don't get what you are trying to say.

When I think about polling it is the game polling the button states, which is usually/always(??) a once per frame discrete event. Certainly that's how some/most?? arcade games worked. How it is implemented in MAME is something I want to know more about.

[oomek]

Is it more clear now?



The yellow bars show when polling function must return keypress even if it's already up.

[oomek]

for inputs shorter than 1 frame it's relatively easy to implement a fix, but for the scenario with not registering quarter circles is a bit complicated as the polling function has no way of knowing what game input the keyboard key is bound to. The fix to not introduce any unnecessary delays must be applied only when two neighbouring joystick directions overlap for a specific player.

[oomek]

Btw, I still have no clue if input of hardware machines is interrupt or timer driven.

[jimmer]

That clarifies that you are talking about the game polling. 

So, we are I think, talking about altering the INPUT line by programming the encoder.

For the missed short button press we could program a minimum press time eg 18ms to cover all the 60Hz games. I don't think it would be a terrible idea, but it could spoil a legitimate input. eg in Defender it's theoretically possible to fire every other frame, to do that you need to be on-off-on at successive polls (17ms) so an imposed minimum press length could change your on-off-on into on-on-on which would be one shot instead of 2.  If you choose a minimum button press of exactly 1 frame then you would be very unlucky to get either a missed input or the failed double shot.

Ps. I have separate panels and encoders for Streetfighter and Defender so I can program them diffferently if desirable 


You could look for diagonals and extend them to a minimum period easy enough.

Whether any of these schemes will be any good (or are cheating) is open to debate. Have you done any sampling of quarter circles to see what the debounced switch states look like?  it would be nice to know what typical overlaps look like as there might not actually be a problem.

[intealls]

That would be great!, so it would be as good a ASIO then?

Sorry for the late reply, for all intents and purposes, it should be just as good!

Audio card rate estimation isn't done, which doesn't seem to matter much with WASAPI/WDM-KS. Also, there's no sinc resampling at the moment, but it would be very difficult to hear any difference due to this in most situations.

Edit: If you want to be properly anal, sinc resampling is of course "better", and I have a working sinc resampler implementation, it's just that (at the moment) it comes at a cost which is MUCH higher than the nearest neighbor approach taken in mainline. Even though it's written to make use of SSE/AVX, it will steal CPU cycles from the main thread (and definitely cripple frame_delay for instance). The sinc resampling with the ASIO patch was "for free", since it wasn't being done in the main thread. But like said previously it will be very difficult to hear any difference in the vast majority of titles. Also, it might even be possible to get rid of all humanly audible issues (however slight they may be) by simply increasing the sample rate.

[vicosku]

There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!

Hi, I've been out of the loop for at least several months and am updating to the latest GroovyMAME stuff.  It's nice to see all the great work that has been done by people like Calamity and Intealls.  Is the above still true, or have things been changed so that a value of 9 will actually reduce lag more than 8 without issues?  I can't seem to find any documentation regarding this point, though the answer may be hidden in a thread somewhere.  I figure this thread would be a decent place to add that information.  Thanks!

[oomek]

I'm testing GM with Freesync and it's amazing latencywise. I get 0.45 frame minimum in D3D with HLSL on the LCD but in BGFX it's 1 frame more unfortunately. It would need a true fulscreen or dx12 iFlip to reduce it to match the D3D mode. Can we do something about it?

[snappleman]

I was curious how the input/display lag really was with GM since it always felt nearly perfect to me. I compared it to my hardware Neo Geo MVS by using a custom controller I built that has both Neo Geo controller ports and an Ipac2 so I can use it on both systems simultaneously.

I left the GM settings at default, running a Radeon HD5450 with CRT_Emudriver and ASIO4ALL on a VGA CRT at 120hz. The Neo Geo was going into an LCD monitor (because my CRT tv died.. ) through an old Jrok video converter. The input response in GM was faster than that of the real hardware, which I know isn't surprising because it was going through an LCD which introduces lag, but I was still surprised that it was clearly faster in GM.

Now I got a new CRT TV and once I set it all up I'll do the test again for a more dependable result.

[lettuce]

Will Windows 10 new Game Mode help reduce latency further?

[oomek]

It will not unfortunately. It only reserves more memory and cpu cycles to a fullscreen app. Anegdotically it even reduced the fps in some games. Since mame is fps limited it will do nothing to the lag.

[oomek]

If you are running mame on lcd I would advise to go for freesync.

[snappleman]

So I finally got to test GroovyMame vs Neo Geo MVS on a properly set up NTSC CRT TV, and GM has a noticeable input lag over the real thing. I have my framedelay at 7 and the games are running at the same refresh rate and resolution. Also running on a 120hz VGA CRT the results are the same. The only thing I can think of that I can change is uninstalling Windows 8.1 and going to Windows 7, hopefully that will improve things a bit.

[Dacasks]

Just bumping this old thread because, even if someone probably did already another test since then... I managed to get a beat up monitor and time to hook up the jamma setup, again. (mainly to sell stuff, actually, and play some Samsho 64)
So I did another test, now with Groovy 190,  but now with an extra fine twist:
Instead of hooking it through USB, I’ve wired the arcade stick through a LPT port (using the PCI slot)
Same thing: Left Real PCB, Right Groovymame 190 running on a I5 OC to 4.4, Win7, with frame_delay set to 5, just for the heck of it (even if, in some tests, frame_delay 1 gave me noticeable more lag).

It has 5 minutes of Ryu giving head to Ken in outerspace, but it’s Worth of it.

[oomek]

Would you share some links explaining how to configure mame to get the input from the LPT port? I didn’t even know it’s possible and I would like to give it a go.

[Dacasks]

Would you share some links explaining how to configure mame to get the input from the LPT port? I didn’t even know it’s possible and I would like to give it a go.

Well, one option would be to convert a PS1 controller http://www.raphnet.net/electronique/psx_adaptor/psx_adaptor_en.php Or, you can use this tutorial also which covers making an interface from the ground (http://bitenkof98.blogspot.com.br/2013/07/lpt-switch-o-que-e-e-como-usar.htm), it's in portuguese but, it can be translated and has pictures and everything...
You can search for an already made PS2 > LPT adapter as well.

If your mobo doesn't have a LPT port (or pins to hook one), you can use a PCI Express LPT port.

On the software side, you just need PPJOY https://drive.google.com/file/d/0B8n2DGNd2UIUQmpNSXVYdmZEaHc/view
It Works under WIN 10 as well

It has several options inside its control panel depending on the input you have, but it basically routes the inputs to a virtual joystick. It Works great, even with new games and everything.  I can't make the old Groovymame Asio work with it though, maybe my groovymame setup is broken I don't know.

[intealls]

Just did a test run with 1000 Hz USB polling (with the driver somewhere in this thread, http://www.overclock.net/t/1597441/digitally-signed-sweetlow-1000hz-mouse-driver ). Tried fixing the controller to 31 Hz to make sure the driver worked as intended, which made next frame response impossible.

Game was sf2 with GM 0.192 d3d9ex, frame delay 9. The controller was a Hori Real Arcade Pro V3-SA.

I used a scope to see when vblank occured and when the button was pressed. Next frame responses could be observed down to about 2.5 ms before vblank!

Frame delay 9 would should give about 1.68 ms to emulate the frame with sf2, along with the 1 ms poll rate (actual delay would probably be 0 <= 1 ms).

I never observed any next-frame responses below 2.5 ms in the recording.

In summary, upping the poll rate of the controller should lead to more next-frame responses. The default 125 Hz poll rate gives a granularity of 8 ms. With a frame time of 16.76 ms, we would get one poll at 8 ms, the second at 16 ms, which is past the deadline of ~15.084 ms (16.76-1.68). Thus, we would only get next frame response if a button was pressed within 0 to 8 ms (if perfectly aligned with vblank).

A picture of the setup is attached, if anyone wants the videos I could post them somewhere.

[Calamity]

Thanks Dacasks and intealls for these new tests. Really exciting results!

When I have some time I'll redo my tests on my rebuilt system. Last time I tested I was still running GM on XP 64.

I take the opportunity to comment that there's still a big amount of skepticism concerning our results if you look around the web.

[jimmer]

Good stuff intealls.

Do you have any tips on installing the sweetlow driver?  I can't get it to do anything on either my win7 noSP or my win7 SP1 machines.

Running the setup doesn't change the mouse poll rate. (I don't have a way to test the keyboard or my keyboard encoder.) Attempted direct driver update reports back that driver doesn't need updating.