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

0 Members and 1 Guest are viewing this topic.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #280 on: March 30, 2018, 03:29:48 pm »
Meanwhile...

https://forums.libretro.com/t/input-lag-compensation-to-compensate-for-games-internal-lag/15075

Unless I'm too tired to think straight, that won't help with next-frame response. It would probably even make next-frame response more difficult, since two (or more) frames need to be emulated in the same timeslot (which will lead to less time spent waiting for input). It will only affect internal lag (which is supposed to be there, if emulation accuracy is of concern). See the (crappy) sketch applied.

At least with frame delay, and not Calamity's fresh frame slice method.

Edit: I guess I'm too tired to think straight, when refraining from sleep, you should refrain from posting. It shouldn't make next frame-response more difficult, at least in theory. The sketch is a bad example and probably a stupid way to implement something like this.

Code: [Select]
1 ms slots

 ------------------------------------------------
 |  |  |  |  |  |  |  |  |  |PL|ET|ET|PL|ET|ET|VB|
 ------------------------------------------------

PL = poll
ET = emulation time
VB = VBLANK

Input will be reflected by either first or second poll and output to screen.

Edit again: Upon further consideration (and sleep) this method will eat next-frame response time. Polling the input twice per frame will probably lead to weird artifacts, since it can lead to different outcomes in the game. The only way to get around this is to poll the input once, and then emulate after the poll, which eats CPU time. Like so:

Code: [Select]
1 ms slots

 ------------------------------------------------
 |  |  |  |  |  |  |  |  |  |  |PL|E0|E0|E1|E1|VB|
 ------------------------------------------------

PL = poll
E0 = emulation time, frame 0
E1 = emulation time, frame 1
VB = VBLANK

Input needs to be polled earlier, making next-frame response more difficult.
« Last Edit: March 31, 2018, 11:07:26 am by intealls »

iVoid

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 7
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #281 on: April 01, 2018, 11:12:02 am »
Here is a video of the feature in action, by TylerL:
https://www.youtube.com/watch?v=_qys9sdzJKI

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #282 on: April 01, 2018, 12:29:41 pm »
For drivers that actually have next-frame response, that will be more difficult to achieve, since the input always need to be polled earlier. I really don't think there's any way around this. For very fast drivers though, it probably won't matter much.

One interesting aspect of an approach like this would be that it might be possible to relax the CPU requirement and still achieve the same (or better) response you would with a very high frame delay setting, if the game itself does not have next-frame response. That could even make the emulation feel more like the original system than frame delay would be capable of (shaves off the last few milliseconds).

iVoid

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 7
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #283 on: April 01, 2018, 02:24:47 pm »
That is correct. The author himself has stated that this will only be useful for games with internal input lag.

But for those games with internal lag (which are very common) the difference is massive since it cuts entire frames of lag, which can easily offset the gains from frame delay.

Furthermore, unlike frame delay, there is no need for trial and error to determine the correct values since it is very easy to determine how many frames of internal lag a game has by pausing, holding a button, and running the emulator frame by frame.
« Last Edit: April 01, 2018, 02:30:36 pm by iVoid »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #284 on: April 01, 2018, 03:13:09 pm »
But for those games with internal lag (which are very common) the difference is massive since it cuts entire frames of lag, which can easily offset the gains from frame delay.

For games with internal lag, in practice, it should be (almost) the same gain, with a lower processing time requirement. At least if you want to the emulation to be faithful to the original system.

SMW on my (oold) laptop feels really responsive with this. Pretty cool.
« Last Edit: April 01, 2018, 03:18:11 pm by intealls »

iVoid

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 7
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #285 on: April 01, 2018, 04:13:59 pm »
But for those games with internal lag (which are very common) the difference is massive since it cuts entire frames of lag, which can easily offset the gains from frame delay.

For games with internal lag, in practice, it should be (almost) the same gain, with a lower processing time requirement. At least if you want to the emulation to be faithful to the original system.
Yeah, if the internal lag is completely removed it is possible to get lower latency than real hardware, which isn't exactly faithful to the original. But modern hardware always adds a bit of latency which is not faithful to the original either. At least now we have a way to lower latency to the amount we see fit, and the only way to determine if the total latency is the same as real hardware is to run tests.
« Last Edit: April 01, 2018, 04:17:04 pm by iVoid »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #286 on: April 01, 2018, 04:27:10 pm »
But modern hardware always adds a bit of latency which is not faithful to the original either.

Sure, but not a properly set up GM ;)

With a (proper) 1kHz USB polled controller, a CRT and FD 9 you get a (16.67 - 1 - 1.667)/16.67 guarantee of getting the same response as actual hardware, assuming ~60Hz, input-polled once model, accurate driver, excluding any system jitter etc. With faster CPUs and higher USB poll rates this probability will grow.
« Last Edit: April 01, 2018, 04:39:27 pm by intealls »

iVoid

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 7
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #287 on: April 01, 2018, 04:48:09 pm »
But modern hardware always adds a bit of latency which is not faithful to the original either.

Sure, but not a properly set up GM ;)

With a (proper) 1kHz USB polled controller, a CRT and FD 9 you get a (16.67 - 1 - 1.667)/16.67 guarantee of getting the same response as actual hardware, assuming ~60Hz, input-polled once model, accurate driver, excluding any system jitter etc. With faster CPUs and higher USB poll rates this probability will grow.
Sure but even on those conditions the average latency will still be higher than real hardware, even if only slightly, there's no way around that. It's pretty amazing that even with modest hardware and maybe even an LCD it might be possible to get the same results on some games! Who knows, further testing will tell :)

One of my favorite arcade games ever, Samurai Shodown 3, has 1 frame of internal input lag and regrettably I don't have a CRT monitor anymore so I'm pretty excited about this :D I can only imagine how responsive the game must be with this feature on a CRT.
« Last Edit: April 01, 2018, 04:59:11 pm by iVoid »

b4nd1t0

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 31
    • b4nd1t0's repository
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #288 on: April 03, 2018, 07:53:02 am »
Some questions, after having performed the bench and having received a percentage value, which one should I consider best, is my goal to aim at zero? Another question, where is the frame delay value set by slider recorded? After i quit the game, nothing, about the frame delay, is stored in .gfg file.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Online Online
  • Posts: 5851
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #289 on: April 03, 2018, 08:00:32 am »
Some questions, after having performed the bench and having received a percentage value, which one should I consider best, is my goal to aim at zero? Another question, where is the frame delay value set by slider recorded? After i quit the game, nothing, about the frame delay, is stored in .gfg file.

It's not stored, I think this should be added to make the feature useful. As for the value, if you pick the lower one you'll probably be 100% safe, anyway I'd pick the higher one if the percentage is very high, at the risk of some eventual hiccup.
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #290 on: April 03, 2018, 11:44:51 am »
It's not stored, I think this should be added to make the feature useful. As for the value, if you pick the lower one you'll probably be 100% safe, anyway I'd pick the higher one if the percentage is very high, at the risk of some eventual hiccup.

An option to store the value without having to use the writeconfig option could be useful. Currently, for some reason, writeconfig doesn't update the value set with the slider. Personally, I don't like writeconfig, which is why I have it disabled (and thus never tested if the value was updated, which I stated in the original post).

Edit: You could use writeconfig, do the benchmark and run the game with the determined value. That seems to store it.
« Last Edit: April 03, 2018, 01:09:32 pm by intealls »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 103
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #291 on: April 05, 2018, 12:00:16 pm »
That was the idea I had for it.

When you start the game, it checks if a framedelay value is present in the game's configuration file (or if the file is present at all).
If it isn't, it starts a brief test to determine the ideal framedelay value, stores it in the configuration file and starts the game.

Just to be sure, we could tell the script to store the value found minus 1 just to be 100% sure that it won't cause hiccups during gameplay. One can always get in the menu and adjust the value via the slider if he wants.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1847
  • Gotta have blue hair.
    • Tank + Paladin = Tankadin
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #292 on: April 21, 2018, 11:12:22 am »
Edit: Just remembered, if you want to include video and sound in the benchmark, use 'mame64 game -nothrottle -nowaitvsync -nosyncrefresh -notriplebuffer -video d3d' and press ESC after a while.

It might be be useful to create a new "benchfull" switch that includes those options.

Also, do your statistic calculations take into account that the number of seconds reported by bench (at least the output, anyway) is always off by one...

http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=111303
« Last Edit: April 21, 2018, 11:15:05 am by krick »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 306
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #293 on: April 21, 2018, 07:06:50 pm »
Also, do your statistic calculations take into account that the number of seconds reported by bench (at least the output, anyway) is always off by one...

http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=111303

The benchmark doesn't care about the number of seconds run at all. It's a 10 bin histogram of emulated frame times.

If you want a better result, you run it longer.

Edit: Correction: it's a 10 bin histogram of the average of a 1/4th of an emulated second worth of frame times. If more accuracy is needed (doubtful), this could be changed by altering ATTOSECONDS_PER_SPEED_UPDATE in video.h, which might cause issues.
« Last Edit: April 21, 2018, 07:28:16 pm by intealls »

  
 

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