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: GroovyMAME - Input Lag tests 2019 (new method)  (Read 64110 times)

0 Members and 2 Guests are viewing this topic.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #120 on: July 28, 2019, 02:00:51 pm »
About the other topic: how's your 15KHz FreeSync experience ?

I tested it for a couple of hours last week and while it works, I mean Freesync is enabled and its effects are clearly visible on the screen, but I couldn't get a stable picture, it bounces on the screen all the time, it's unusable. This is what I expected frankly. Freesync works by adding variable vblank lines as required. Freesync capable LCDs are designed to ignore those lines geometry-wise, but CRT guns are just driven by the video signal, so adding those extra lines randomly makes just makes the picture jump up and down.

The cool thing about Freesync is that, provided we could get it working fine on CRTs, it would make it unnecessary to create custom video modes, since the refresh would be adjusted on real time. This would make the implementation generic for all gpus, no need for custom drivers, etc.

The other cool thing about Freesync is that it deprecates the need of frame delay.
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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #121 on: July 28, 2019, 02:27:19 pm »
Well if you manage to make that raster polling thing a working solution for it this would sure be some sort of journey end, at least for the CRT side.
That would still be an AMD thing but so much simpler and lighter indeed.

As for the BGFX topic if it works it'll be great, I guess that would mean resuming BGFX w/ frame_delay too (?)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #122 on: July 28, 2019, 03:17:15 pm »
Thanks, I'm gonna test it as soon as my daughter gives me my main pc back

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #123 on: July 28, 2019, 04:32:56 pm »
Freesync Off, 60Hz, -noka -noflt -notb -waitvsync -unevenstretch -throttle -syncrefresh -fd 0 shinobi

groovymame64_0211.017n
84.66 ms

groovymame64_0211.017n_d3d9ex_bgfx-mod
67.79 ms

groovymame64_0211.017n_bgfx-dwmflush.7z
51.35 ms


Freesync Off, 60Hz, -noka -noflt -notb -nowaitvsync -unevenstretch -throttle -syncrefresh -fd 0 shinobi

groovymame64_0211.017n
84.66 ms

groovymame64_0211.017n_d3d9ex_bgfx-mod
67.79 ms

groovymame64_0211.017n_bgfx-dwmflush.7z
67.85 ms


Small update. It seems that in dwmflush build waitvsync makes a difference, and it's a bit counterintuitive.
« Last Edit: July 28, 2019, 05:11:06 pm by oomek »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #124 on: July 28, 2019, 04:35:33 pm »
Have you ever had a situation where freesync is working on a CRT and the image does not jump? I'm asking because I've had several sessions completely stable. Still trying to figure out what is the breaking factor here.
« Last Edit: July 28, 2019, 04:37:04 pm by oomek »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #125 on: July 28, 2019, 06:25:16 pm »
Holy ---steaming pile of meadow muffin---. dwmflush version is acting weird but in a positive way. I'm shaving 50ms down to 5ms in BGFX by just tweaking frame delay and pressing F3 to reset the game.

More info soon, I need to do some tests.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #126 on: July 28, 2019, 10:24:51 pm »
Ok, try this. Enable enhanced sync in the driver and launch the dwm version with:

-noka -noflt -notb -waitvsync -unevenstretch -throttle -syncrefresh -fd 0 shinobi

I'm getting consistent 18ms (or less with fd > 0) on BGFX

I was having weird inconsistent results sometimes 50 sometimes 4, it seems that DWM was giving random number of frame buffers to GM depending on if the frame time took longer than 16ms for example when F3 was pressed. What's more, when game was exactly 60Hz I had more lag, when game was a bit faster I had less. the good examples are:
shinobi - 60.000Hz
shinobi2 - 60.054Hz
My monitor's refresh is exactly 60.00Hz

So it is possible now, to have 4ms -18ms on BGFX, it's just a matter of figuring out if we can enable enhanced sync from within the code.

Oh and btw: in case you are wondering if there is any way of controlling the number of frames rendered ahead when you go through DWM... well, there was ... some lunatic from the MS decided to make it deprecated as well as many other useful presentation parameters. They are still there, but have no effect.

update: I'm gonna put my nvidia card in tomorrow, and see how it behaves on the other side of the fence.
« Last Edit: July 28, 2019, 10:37:26 pm by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #127 on: July 31, 2019, 12:27:25 pm »
Hi Oomek,

Thanks a lot for testing.

Quote
Freesync Off, 60Hz, -noka -noflt -notb -waitvsync -unevenstretch -throttle -syncrefresh -fd 0 shinobi

groovymame64_0211.017n
84.66 ms

groovymame64_0211.017n_d3d9ex_bgfx-mod
67.79 ms

groovymame64_0211.017n_bgfx-dwmflush.7z
51.35 ms


So it looks like with standard vsync, BGFX is still 1 frame behind D3DEx (both without fd). Eventhough this build shaves off 2 frames for BGFX which is remarkable, so I'll add this patch to GroovyMAME 212.

I can't replicate your results with enhanced vsync. If I enable it in AMD's control panel, them GM (last test build) runs at full speed with -syncrefresh -waitvsync. If I enable fd, then I can lower the speed as I increase the value of fd, but I can't leave it at 100%.

I'm testing this on my Vega 56, and CRT Emudriver based on Adrenaline 18.5. Maybe I'll try using a more current driver.

With regards to Freesync on CRTs, I've been testing the idea I had with another custom build, and although the concept kind of works, I'm afraid it won't be usable because the image is inherently unstable with this method. Now I can get a picture that doesn't jump too much, but you can still see a small "vibration" of the whole picture up and down one or two lines, it's like looking at an old TV that's about to break.

The idea was simple, passing a scanline number as an option to force GM sync on it. Desktop is set to 63 Hz, which barely corresponds to 250 scanlines. If you pass a higher number, say 262, the refresh will drop dynamically to 60 Hz, the higher the scanline number, the lower the refresh. Obviously in the final design GM would make this calculation for you.

This is what actually happens behind the scenes when you throttle using the cpu clock, although this method is much more exact. However, it's not exact enough to avoid all the instability.

Besides, with this method you modify the number of lines instead of the pixelclock, so the refresh rate granularity is terrible (similar problem to achieving dynamic refresh on the Pi).

To sum up, it's a very interesting experiment to understand how Freesync works, but I don't think it won't be usable on CRTs.
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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #128 on: July 31, 2019, 03:37:22 pm »
So it looks like with standard vsync, BGFX is still 1 frame behind D3DEx (both without fd). Eventhough this build shaves off 2 frames for BGFX which is remarkable, so I'll add this patch to GroovyMAME 212.

Congrats! Damn that one frame too much tho. Guess there's only Vulkan to really break through (hopefully some day in baseline)

To sum up, it's a very interesting experiment to understand how Freesync works, but I don't think it won't be usable on CRTs.
Some things are just too good to happen.  :dunno

PS: I'll add another of my absurd layman speculations; What if we could generate a 'dummy' fixed frame for the CRT within which the GPU would think it's working with a compatible FreeSync target display?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #129 on: July 31, 2019, 08:28:16 pm »
I read that each CRT is more or less tolerant to varying porch length. If you don't mind I would like to test your build with scan based timing on my B&O CRT.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #130 on: August 01, 2019, 01:52:32 pm »
I read that each CRT is more or less tolerant to varying porch length. If you don't mind I would like to test your build with scan based timing on my B&O CRT.

Here you have: https://drive.google.com/open?id=11iIEGg2sEsteCnlhDp9vCxohdgvNpkzx

Since this is a test I've just reused the -vsync_offset option so I didn't have to add another option, here -vsync_offset is just the scanline number we have to wait before presenting, e.g.

groovymame alexkidd -syncrefresh -vsync_offset 262

groovymame rtype2 -syncrefresh -vsync_offset 286

The scanline itself should define the refresh, based on a desktop resolution higher refresh (e.g. 61 or 63 Hz).

You can try with or without -syncfresh, since vsync is either way forced by this build. The difference is that -syncrefresh disables cpu throttling, which may be desired or not. You can always disable -throttle later in-game with F10. Also, -syncrefresh is required for frame_delay to work.

The odd thing about Freesync (which makes sense after all if you think of it) is that it's not always enabled, I mean it has its own range and outside of it the drivers have to turn it off and do something else, and this probably is not magic but needs some software logic in the driver. But how do the drivers know when we're inside the range? It depends on how often we send frames, so the drivers must keep some sort of stats. So when we launch a game in MAME, until we send some number of frames, probably Freesync is not doing its thing. That's the point of launching MAME with throttle on. But once Freesync is working, this throttling is an obstacle to raster-based synchronization, so we can turn it off.

As you see, it's a convoluted process to even figure out.
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #131 on: August 01, 2019, 02:38:33 pm »
This is how I understand it.

After sending the frame to the driver CRT starts a new scan, then it sits in the porch until you swap buffers. The crucial thing here is to keep consistent timing of swapping buffers, not the time when you start drawing frame as this takes time and it may be very random.  I don't know how big the spread is and how much it's affected by the specific game core. Maybe keeping some frame time statistics would help. it's the situation like with conventional frame delay, but instead relying on vsync you wait until specific scanline is reached and then you swap buffers, so you have full control over the refresh rate.

So the flow would be something like tihis:

1. swaping buffers
2. waiting for specified frame delay time
3. drawing frame
4. waiting for a specific scan line
5. swapping buffers




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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #132 on: August 01, 2019, 04:14:13 pm »
This is how I understand it.

After sending the frame to the driver CRT starts a new scan, then it sits in the porch until you swap buffers. The crucial thing here is to keep consistent timing of swapping buffers, not the time when you start drawing frame as this takes time and it may be very random.  I don't know how big the spread is and how much it's affected by the specific game core. Maybe keeping some frame time statistics would help. it's the situation like with conventional frame delay, but instead relying on vsync you wait until specific scanline is reached and then you swap buffers, so you have full control over the refresh rate.

So the flow would be something like tihis:

1. swaping buffers
2. waiting for specified frame delay time
3. drawing frame
4. waiting for a specific scan line
5. swapping buffers

Sure, that's it.

But the problem is (as far as I know) you can't dissociate the drawing operation from the swap operation, all is encapsulated in the unfortunate "Present" idea.

That's the specific problem I've been facing all these years. When I experimented with frame slicing this was the main issue. Flushing the GPU helped to some extent.

But you can't split the two operations just like it used to work in the old days of DirectDraw (Blit & Flip).

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #133 on: August 01, 2019, 05:37:12 pm »
I'm having problems with your latest test build. GM is freezing after 1-2 seconds.

gm211s -notb -noka -noflt -unevenstretch -nosyncrefresh -noswitchres -vsync_offset 286 alexkidd

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #134 on: August 02, 2019, 04:50:37 am »
Yes, that happens when you use a too high scanline number and you start without -throttle (syncrefresh disables throttle). Try starting with throttle, then disable it with F10 some seconds later. Also, 262 or so is good for 60 Hz.

Anyway, this test build works really bad.
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #135 on: August 02, 2019, 04:58:42 am »
gm211s -notb -noka -noflt -unevenstretch -nosyncrefresh -noswitchres -throttle -vsync_offset 262 alexkidd

is still freezing.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #136 on: August 02, 2019, 05:45:53 am »
Check a log to see what scaline number it shows when it gets stalled.
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #137 on: August 02, 2019, 08:08:32 am »
It doesn't show. I can only see m_scanline(0) flood when I set vsync_offset to 0
the last 3 lines were:

Code: [Select]
Starting Alex Kidd: The Lost Stars (set 2, unprotected)
hiscore: found hiscore.dat entry for alexkidd
hiscore: scores read FAIL

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #138 on: August 02, 2019, 08:59:54 am »
The build is hardwired for \\.\Display1, I'm afraid that's probably the issue.
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #139 on: August 02, 2019, 09:03:56 am »
Oooh, ok, that explains a lot. B tw you weren't using extended desktop were you?

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #140 on: August 02, 2019, 09:06:18 am »
No, extended desktop stops freesync here to, just like you said.
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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #141 on: August 04, 2019, 09:42:42 am »
I've polished the MAME LUA plugin while waiting for a batch of custom PCBs for my Input Lag Meter


keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1847
  • Last login:October 06, 2023, 10:20:39 pm
  • Web Developer.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #142 on: August 04, 2019, 01:05:06 pm »
Plugin looks great! I cant wait to try!

Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1558
  • Last login:Today at 02:59:27 am
  • Budgets are boring
    • newforum.arcadecontrols.com/index.php/topic,156267.0.html
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #143 on: August 04, 2019, 02:02:07 pm »
Damn that’s pretty cool.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #144 on: August 06, 2019, 05:51:39 am »
Stupid idea : what about increasing the USB poll time ? Not sure this can be done in Windows, but this can easily be done in Linux

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #145 on: August 06, 2019, 06:19:37 am »
The usb descriptor of my device is already set to 1000hz.

Wait, increasing the poll time or rate?

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #146 on: August 06, 2019, 07:39:25 am »
poll time : how often windows queries the device to get new data.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #147 on: August 06, 2019, 07:47:05 am »
Poll time - 1ms
Poll rate - 1000hz

Afaik you can't go lower(higher in hz) than that

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #148 on: August 06, 2019, 08:30:04 am »
You could take a page from CMOS camera sensors and employ multiple detectors that fire off in a staggered pattern within the 1ms window.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #149 on: August 06, 2019, 08:35:36 am »
It's not a matter of sensor's temporal resolution. I sample the sensor at maximum speed for Atmega32u4 which is 60us poll time which gives me 16.666kHz sensor poll rate. The limiting factor is the usb protocol. I send the key down event and it's somewhere in the 1ms window. That's why I take 1000 samples to overcome that.
« Last Edit: August 06, 2019, 08:38:12 am by oomek »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #150 on: August 06, 2019, 01:06:32 pm »
Mathematically speaking, sampling speed must be (at least) twice higher than max frequency of the event you wish to capture. This means that polling every 1ms, you can only guarantee something happening every 2ms (500Hz)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #151 on: August 06, 2019, 01:38:19 pm »
I'm still not sure what you're saying. I send the keyboard event which is polled with a rate of 1000hz by the emulator and then I start the timer and wait in the tight loop 16Khz until the sensor signal exceeds the threshold. USB events and sensor readings are not coupled. Nyquist frequency has nothing to do with this. Look at the graphs
http://forum.arcadecontrols.com/index.php/topic,160722.msg1692288.html#msg1692288
rising slope of both CRT and the LCD is very slow comparing to the sensor sampling rate.
« Last Edit: August 06, 2019, 01:43:01 pm by oomek »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #152 on: August 06, 2019, 02:39:20 pm »
Sorry for not writing down what's in my head ;)

Simply put, events happen this way : your device send  HID event, windows gets it, MAME notices it, the square is on, your sensor grabs it. Right ?

What I'm talking about is the USB latency and windows poll time. USB is not based on interrupts (which would have been god blessed for latency), but polling -> Windows checks data from the HID device. So, if windows default polling time is 125Hz (=8ms period, seems to be windows default value), you can get inputs that are no faster than 125/2=72.5 Hz, so each 16ms. So this brings us back to my very original question : what about windows polling time ? Can it/Could you set it to a high value ?

Sorry I couldn't understand your graphs : no units on both x and y axis, no marks on the x axis

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #153 on: August 06, 2019, 05:53:18 pm »
There is no need for any additional software. As I mentioned earlier I've modified Tennsy's HID descriptor to run at 1000Hz by setting bInterval to 1

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/usbspec/ns-usbspec-_usb_endpoint_descriptor

Regarding the graphs: It's showing the transition from black to white on LCD and CRT.
Axis Y is 10-bit sensor value in a 0-1023 range.
Axis X is time showing only 15ms range due to limited RAM on ATMEGA32U4
« Last Edit: August 06, 2019, 07:01:32 pm by oomek »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #154 on: August 12, 2019, 11:31:41 pm »
I was thinking again about how to measure core emulation lag; could a variation of the current test target a select sprite hitbox (the character or ship) and detect when it moves ?

Maybe sticking a black & white pattern over the targeted sprite hitbox, the photodiode would then be able to 'see' movement and use the state changes to measure ? (thought of that because I remember seeing a LUA plugin to make hitboxes appear on screen)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #155 on: August 13, 2019, 04:47:28 am »
I'm pretty sure it is doable, but would require per game lua scripting.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #156 on: August 13, 2019, 06:33:51 am »
Ouch.
Not even per-system ?
I've just seen the 'show hitboxes' one existed only for sf2, welp, indeed.

Would a straight attempt be working any then ? placing the photodiode directly on a sprite, and detect any brightness variation to register measurements.
But maybe a simple photodiode can't do that, I don't know what component could detect even the smallest variation of brightness/color instantly and reliably.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #157 on: August 13, 2019, 08:57:44 am »
Per system.. well that depends, maybe there is a chance to implement some sort of register sniffer like in cheat plugin, will look into it.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #158 on: August 13, 2019, 10:13:49 am »
Please don't hassle yourself too much with that, I am pretty much the only person to be that interested in knowing the core emulation base delay/times ^^ I've just been wondering about alternatives to the bothersome and controversial camera tests and since I have very little knowledge I think about random things that might be useless waste of time.

Still, it would be awesome if something like that or whatever other alternative existed, even if not of high precision, because combined with your current method, then, we would know pretty much everything, the whole truth about lag/delay in MAME.

I've been reading about various DIY motion sensor solutions but when anything beyond child-level electronics comes into play, like programming and emulators, I am completely lost.  :lol



Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #159 on: August 13, 2019, 10:28:14 am »
Just to make sure I understand : displaying a square in LUA is not rendered through the same "pipeline" as emulation stuff ? So oomek's data just measures the time it takes between pressing the button and displaying some acknowledgement square on the screen ? Which means "My rig has an input lag of XXms, which doesn't include emulation/natural emulated system lag" ? Which also means "This measured input lag is probably increased by the game itself, but we can't measure this yet". Am I right ?