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

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

  

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

0 Members and 1 Guest are viewing this topic.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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
  • Last login:April 01, 2018, 04:58:19 pm
  • 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:

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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
  • Last login:April 01, 2018, 04:58:19 pm
  • 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: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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
  • Last login:April 01, 2018, 04:58:19 pm
  • 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: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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
  • Last login:April 01, 2018, 04:58:19 pm
  • 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: 150
  • Last login:March 12, 2024, 04:11:22 am
    • 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
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #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 of pasting it.

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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Today at 07:04:20 am
  • 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.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:February 08, 2023, 08:30:27 pm
  • Gotta have blue hair.
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 »
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 07:31:32 pm
  • 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 »

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #294 on: August 18, 2018, 08:53:45 am »
Just read the entire topic and this is very interesting.

I did many simple measurements with an iphone at 240f/s and a LED connected to button
Comparing my real neogeo hardware and groovymame

Neogeo responses after 3 frames, mame after 4 frames
With shift+P mame shows the machine should respond after 2 frames

I tried space invaders that should respond after 1 frame with shift+p, that is the next frame response
when pressing a button, mame responses after 3 frames

I think my CRT adds a frame, it may have a digital process in, should try with another one
But there is still one frame that I could not get rid off

I was wondering if my JammaSD (I did the 1000hz poliing rate) could add something or the ATI radeon HD7800 ?
Is there something to do with ATI video cards, or do they add one frame lag?

 

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #295 on: August 18, 2018, 08:59:40 am »
Are you using frame delay? GM version? Windows version? Linux?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

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

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #296 on: August 18, 2018, 09:10:01 am »
Hello Calamity
GM 0.194, windows 7, frame delay 9 on space invaders, frame delay 6 for neogeo machine

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #297 on: August 18, 2018, 09:12:19 am »
I tried GM 0.197 with HLSL, but same results

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #298 on: August 18, 2018, 10:37:18 am »
I have focused on the possibility of a pre-rendered frame with my ATI Radeon.
I used RadeonPRO tweak software and could tweak a frame queue size from driver setting to 0

It solved this 1 frame I tried to get rid of.
So ATI owners have to do that

I will try another CRT, mine introduces a frame lag
Did someone else experienced that as well?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #299 on: August 18, 2018, 01:12:48 pm »
The d3d9ex build of GM already removes the frame queue, even without frame delay. What kind of crt are you using? Does it have digital processing?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

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

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #300 on: August 19, 2018, 05:50:27 am »
I have redone a bunch of slowmotions and shift+P, and with .ini different parameters
My CRT does not introduce any lag (I was comparing two different things previously, two different actions in the neogeo)

With shift+P Neogeo reacts at the 3rd frame in Mame
The real hardware reacts at the 3rd (puzzle bubble) for the same action
GM does it in the 4th, depends at lot on when the action happens on the frame
Variation in GM is something like 3.5 to 4.5 reaction

Space invaders reacts at the 2nd, could does something like 1.5 to 2.5
Seems that I could get action happening in the next frame, but action has to happen at the beginning of a frame

I had the feeling that the queue thing in RadeonPro could improve of a 1/4th of frame, but this seems to be more subjective than objective
But Overall average seems to indicate that there is 1 frame of lag

If GM could get one real hardware lag frame off (when it has lag), it could be just as the real hardware
But understood that this is not in Mame's philosophy

Would be happy to test the frame slice feature :-)

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 561
  • Last login:March 17, 2024, 06:03:11 pm
  • I want to play Defender like at the arcade.
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #301 on: August 19, 2018, 09:25:35 am »

See my thread 'Unexplained Lag ...'  Calamity provides a download link and how to run info for the frameslice build.

Thanks to this thread I've started using the frame advance button to analyse what's happening a bit better, I'm not sure exactly what's happening when I step though a frame in 4 steps (note: frame_slice 3 = 4 slices) but I'm seeing some things that I'm sure will be an aid to eventually improving the Defender emulation. 
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #302 on: August 19, 2018, 04:17:53 pm »
Thanks for the link, just tried it.


faybiens

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17
  • Last login:May 09, 2019, 02:07:43 am
  • I want to build my own arcade controls!
Re: Input Lag - MAME iteration comparisons vs. the real thing?
« Reply #303 on: August 22, 2018, 02:25:47 am »
When playing with .ini, I am noticing that frame delay feature is like switched off.
Even at 9, which normally would slowdown a game, it does nothing .

I need to get which parameters could influe, any ideas?