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

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


  

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

0 Members and 1 Guest are viewing this topic.

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #160 on: December 15, 2016, 01:58:45 pm »
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.

https://www.youtube.com/watch?v=SF6r9nMj0y0

(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

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5592
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #161 on: December 16, 2016, 09:44:28 am »
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?
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #162 on: December 16, 2016, 10:15:57 am »
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
« Last Edit: December 16, 2016, 10:17:57 am by oomek »

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #163 on: December 16, 2016, 10:41:57 am »
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

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 5592
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #164 on: December 16, 2016, 11:31:09 am »
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).
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

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #165 on: December 16, 2016, 12:25:34 pm »
:D
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #166 on: December 16, 2016, 05:20:33 pm »
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

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1265
  • Web Developer.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #167 on: December 17, 2016, 12:48:03 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 277
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #168 on: December 17, 2016, 06:35:48 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
    • Eiusdemmodi
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #169 on: December 19, 2016, 05:58:03 pm »

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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #170 on: December 20, 2016, 09:44:51 am »
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 :D :D



« Last Edit: December 20, 2016, 10:45:19 am by Dacasks »

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #171 on: December 20, 2016, 09:59:06 am »
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)
« Last Edit: December 20, 2016, 11:01:10 am by Dacasks »

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
    • Eiusdemmodi
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #172 on: December 20, 2016, 12:17:36 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 29
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #173 on: December 26, 2016, 10:24:27 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #174 on: December 31, 2016, 01:34:31 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #175 on: December 31, 2016, 01:41:35 pm »
I could program some macros in Arduino emulating input sequences with transitions shorter than 1 frame to see how it behaves.

lettuce

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1849
  • Make It So!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #176 on: January 01, 2017, 10:46:36 am »
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?
« Last Edit: January 09, 2017, 04:15:47 pm by lettuce »

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 465
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #177 on: January 13, 2017, 09:44:44 am »
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?
« Last Edit: January 13, 2017, 09:50:35 am by jimmer »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #178 on: January 13, 2017, 11:11:00 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 465
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #179 on: January 13, 2017, 01:04:41 pm »

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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #180 on: January 13, 2017, 03:29:53 pm »
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.
« Last Edit: January 13, 2017, 03:50:31 pm by oomek »

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 465
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #181 on: January 13, 2017, 05:09:31 pm »

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

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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #182 on: January 13, 2017, 05:32:18 pm »
Is it more clear now?



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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #183 on: January 13, 2017, 05:42:43 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #184 on: January 13, 2017, 05:45:00 pm »
Btw, I still have no clue if input of hardware machines is interrupt or timer driven.

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 465
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #185 on: January 13, 2017, 08:46:36 pm »

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  ;D


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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 277
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #186 on: January 20, 2017, 05:23:47 pm »
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.
« Last Edit: January 20, 2017, 05:41:16 pm by intealls »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 98
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #187 on: February 02, 2017, 07:50:05 am »
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!
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #188 on: February 02, 2017, 11:30:50 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #189 on: February 13, 2017, 09:44:06 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1849
  • Make It So!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #190 on: February 18, 2017, 04:45:17 pm »
Will Windows 10 new Game Mode help reduce latency further?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #191 on: February 18, 2017, 07:29:21 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 111
  • Mame forever.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #192 on: February 18, 2017, 07:31:36 pm »
If you are running mame on lcd I would advise to go for freesync.
« Last Edit: March 03, 2017, 04:48:33 pm by oomek »

snappleman

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #193 on: March 03, 2017, 04:47:32 pm »
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.

  
 

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