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 --- Bug Reports --- 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 6807 times)

0 Members and 1 Guest are viewing this topic.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #80 on: July 26, 2019, 07:30:08 am »
So how can we get freesync to not stress our monitors to death when going out of sync?

Are you talking about CRT or LCD? In LCD there is no stress. Mame games output throttled constant framerate. If this framerate is above below your current resolutions refresh rate freesync is enabled.
When it comes to CRT there is also no stress but a desync caused by low accuracy throttle timer as Calamity said.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #81 on: July 26, 2019, 07:42:50 am »
According to my tests the advantage of D3D9ex version only manifests with -fd 0.

That's expected. D3D9ex is faster only when we use "standard" vsync, because it allows us to control the frame queue size, while D3D9 just uses the default length. Your results show that, by default (vsync on, fd 0):

- D3D9 -> 3 frames of lag
- D3D9ex -> 2 frames of lag

Quote
Both versions are faster than baseline for freesync and with fd > 0  (<<< did you mean fd = 0?) This is a bit unexpected surprise to me.

I think this is due to the different way the GM and MAME organize the frame update loop.

MAME:

1.- Emulate frame
2.- Throttle
3.- Render
4.- Poll inputs

GM:

1.- Throttle
2.- Poll inputs
3.- Emulate frame
4.- Render

Baseline MAME introduces a delay after the frame is emulated and before it's rendered, this moves away these 2 steps unnecesarily.
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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 128
  • Last login:September 14, 2019, 10:12:53 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #82 on: July 26, 2019, 07:46:42 am »
Would love to see the delay with snes cores. They always were laggier than most cores.
With groovymame set to frame delay of 7 i get input lag on super mario world that is as close to the real thing.
With retroarch i have to "cheat" and use run-ahead to get input lag as close as that.

What's your RA configuration without run-ahead (video driver, hard GPU sync, video hard sync frames, video frame delay, video max swapchain images...)? Which SFC/SNES cores have you tried?
Video driver: opengl. Hard gpu sync is on. Hard sync frames = 0. Video frame delay =  Depends on the core, varies between 5-13 (though i suspect it doesn't really help with reducing lag. though on an nvidia shield the reduction in lag is noticeable. Max swapchain inages = i think 1. Not at home currently to check. Tried cores: bsnes-balanced, bsnes-mercury-balanced, beetle bsnes, snes9x.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #83 on: July 26, 2019, 07:51:12 am »

That's expected. D3D9ex is faster only when we use "standard" vsync, because it allows us to control the frame queue size, while D3D9 just uses the default length. Your results show that, by default (vsync on, fd 0):

- D3D9 -> 3 frames of lag
- D3D9ex -> 2 frames of lag

Quote
Both versions are faster than baseline for freesync and with fd > 0  (<<< did you mean fd = 0?) This is a bit unexpected surprise to me.
Wrong wording, it should be: According to my tests the advantage of D3D9ex version only manifests with -fd 0 and Freesync OFF. Both versions are faster than the baseline with Freesync ON and with with Freesync OFF when -fd > 0
Corrected my previous post.
Quote

I think this is due to the different way the GM and MAME organize the frame update loop.

MAME:

1.- Emulate frame
2.- Throttle
3.- Render
4.- Poll inputs

GM:

1.- Throttle
2.- Poll inputs
3.- Emulate frame
4.- Render

Baseline MAME introduces a delay after the frame is emulated and before it's rendered, this moves away these 2 steps unnecesarily.

That explains the results very clearly, thanks.
« Last Edit: July 26, 2019, 07:52:46 am by oomek »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #84 on: July 26, 2019, 07:56:04 am »
Are LUA plugins supported by Retroarch? I use LUA plugin to mesure the lag now, but can't find a plugins folder

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 30
  • Last login:September 10, 2019, 12:58:27 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #85 on: July 26, 2019, 07:59:45 am »
So how can we get freesync to not stress our monitors to death when going out of sync?

Are you talking about CRT or LCD? In LCD there is no stress. Mame games output throttled constant framerate. If this framerate is above below your current resolutions refresh rate freesync is enabled.
When it comes to CRT there is also no stress but a desync caused by low accuracy throttle timer as Calamity said.

Talking crt here, when you pause for examle gives you max desync and lets say background processes in windows force gm to render some frames at 40fps , thats kind of much lower accuracy then the best we can get ( which is not good enough like calamity said).

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #86 on: July 26, 2019, 08:05:20 am »
With d3d9ex there's supposedly only one frame left on top of the game's, but by oomek's first posted test it looks like this is true in this case only if frame_delay is on (at minimum 1).

I'm probably responsible for spreading this misinformation. What we do with D3D93x is to set the frame queue size to 1 (frame), but what this actually means is that when we send a new frame, the Present call returns right when the last frame is starting to be rasterized on the screen (beam on top). This means 2 actual frames of latency: the time it takes to complete the last frame (beam on bottom) and the whole new frame.

By using fd 1 we disable the buffering and start drawing directly on the screen. So yes, by simply enabling fd with the lowest value we're already shaving a whole frame. This contradicts what I've been saying and makes total sense now that I think of it.

(While this is the best you can get with D3D9ex I believe newer APIs like Vulkan can optimize the frame queue even more.)
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #87 on: July 26, 2019, 08:18:02 am »
I'm preparing now to redo the tests with the latest AMD driver and their Anti-Lag feature. I'm very curious about the results. FYI, it only works with DX11 though and in DX9 when you have a Navi card.
« Last Edit: July 26, 2019, 08:19:53 am by oomek »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:Yesterday at 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #88 on: July 26, 2019, 08:30:28 am »
@Calamity: Great it's cool that this misunderstanding's cleared now anyway, it's been bugging me. Trust me or not, a 1 or 2 frames difference may be a subtle feeling not everyone can easily notice, but I've been wondering about that a good number of times as in my hands default 9ex sure feels responsive, but anything with f_d ON has always felt like playing with a dead weight removed.

I have to check again which games were thrown unstable by even f_d 1 though, I remember that happening with some 3D games (iirc heavy drivers like STV and taitoGN) at least on my current PC.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 30
  • Last login:September 10, 2019, 12:58:27 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #89 on: July 26, 2019, 08:44:43 am »
Run ahead for itself is just the removeval of full legit delayed frames, done with savestates.
Nope, again it can eliminate both the extra we of course don't want, and the game's legit along if you set run-ahead too high. Both, that's the issue with it.


Can you explain that extra or anything beyond that run ahead is only shaving off frames with savestates ( thats how the lets say inventor explains)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #90 on: July 26, 2019, 09:05:08 am »
I'm preparing now to redo the tests with the latest AMD driver and their Anti-Lag feature. I'm very curious about the results. FYI, it only works with DX11 though and in DX9 when you have a Navi card.

Yup, Radeon's Anti-Lag feature shaves off 1 frame of lag in every BGFX DX11 test. Still not enough to treat BGFX seriously ;)

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:Yesterday at 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #91 on: July 26, 2019, 09:19:56 am »
Can you explain that extra or anything beyond that run ahead is only shaving off frames with savestates ( thats how the lets say inventor explains)
No definitely not 'only'. First there's the emulated hardware+game, if emulation is accurate the driver or core emulation produce more or less the same delay as the actual thing IRL.
Then in an emulator there's the matter of outputing video and polling inputs, potentially other side things like in MAME, but in general this side of the whole emulation package, and the options related to them (like flavours of vsync) produce an additional number of frames.
So they add up, core/game emulation + video,polling,etc, that's why people talk about 'lag chain' (not even counting the PC/OS, controller, and display's own there).
Run-ahead allows you to chew out the video/input/etc part, which is good, but it can go further by chewing out frames from the game's too, those that shouldn't be touched if anyone's concerned about aspects like emulation accuracy and fairness in competitive play. there's also the issue of that 'missing frames' feeling in cases.
A lot of the appeal of run-ahead unfortunately has been that: playing with even less input lag than the originals IRL.
Though again; it depends heavily on what you're playing and settings (as well as PC juice), you could sample 20 RA users and see they all have different understanding of what's going on and all of them different settings according to that, because there's so many variables in RA, it's literally a smörgåsbord of APIs and features borrowed to a ton of other emus and programs and it's possible to abuse proper emulation thanks to that, there is no safeguard.
The confusion and enthusiasm have also created an ideological polarization in the emu scene, with RA users who deny the issues, and for instance mamedev exaggerating them.
Personally I stick to Groovy and the wisemen here because I like the rational and scientific approach without the BS, it's tested, working, efficient without a doubt period.  8)
« Last Edit: July 26, 2019, 09:25:46 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 30
  • Last login:September 10, 2019, 12:58:27 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #92 on: July 26, 2019, 09:37:15 am »
Thank you Schmerzkaufen, i have a feeling you are the same guy with other nicknames on many forums, are you from hamburg?

Ok lets go rational now,

Can you explain that extra or anything beyond that run ahead is only shaving off frames with savestates ( thats how the lets say inventor explains)
No definitely not 'only'. First there's the emulated hardware+game, if emulation is accurate the driver or core emulation produce more or less the same delay as the actual thing IRL.
Then in an emulator there's the matter of outputing video and polling inputs, potentially other side things like in MAME, but in general this side of the whole emulation package, and the options related to them (like flavours of vsync) produce an additional number of frames.
So they add up, core/game emulation + video,polling,etc, that's why people talk about 'lag chain' (not even counting the PC/OS, controller, and display's own there).
Run-ahead allows you to chew out the video/input/etc part, which is good,





Explain why you say that run ahead is not only that further chewing ( the savesstates that are) like you say next.
How you know that  and if, what is it doing more than what fd or hardsync etc are doing.



but it can go further by chewing out frames from the game's too, those that shouldn't be touched if anyone's concerned about aspects like emulation accuracy and fairness in competitive play. there's also the issue of that 'missing frames' feeling in cases.
A lot of the appeal of run-ahead unfortunately has been that: playing with even less input lag than the originals IRL.
Though again; it depends heavily on what you're playing and settings (as well as PC juice), you could sample 20 RA users and see they all have different understanding of what's going on and all of them different settings according to that, because there's so many variables in RA, it's literally a smörgåsbord of APIs and features borrowed to a ton of other emus and programs and it's possible to abuse proper emulation thanks to that, there is no safeguard.
The confusion and enthusiasm have also created an ideological polarization in the emu scene, with RA users who deny the issues, and for instance mamedev exaggerating them.
Personally I stick to Groovy and the wisemen here because I like the rational and scientific approach without the BS, it's tested, working, efficient without a doubt period.  8)

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 185
  • Last login:September 08, 2019, 07:28:29 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #93 on: July 26, 2019, 10:20:54 am »
Personally I stick to Groovy and the wisemen here because I like the rational and scientific approach without the BS, it's tested, working, efficient without a doubt period.  8)

And its emulation of systems such as FC/NES, SFC/SNES, MCD, not to mention X68, 88SR, PC98... basically sucks.

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 128
  • Last login:September 14, 2019, 10:12:53 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #94 on: July 26, 2019, 11:50:59 am »
Are LUA plugins supported by Retroarch? I use LUA plugin to mesure the lag now, but can't find a plugins folder
I'm not sure about that.
This is the only thing i found about lua and retroarch https://www.libretro.com/index.php/tag/lua/

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #95 on: July 26, 2019, 11:51:24 am »
I'm preparing now to redo the tests with the latest AMD driver and their Anti-Lag feature. I'm very curious about the results. FYI, it only works with DX11 though and in DX9 when you have a Navi card.

Yup, Radeon's Anti-Lag feature shaves off 1 frame of lag in every BGFX DX11 test. Still not enough to treat BGFX seriously ;)


When you have a chance, please test again the bgfx backend + freesync with this new build:

https://drive.google.com/open?id=1EQI0SaIOyf7hjaDSxrqR3rIGpHko5jWW

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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #96 on: July 26, 2019, 12:17:41 pm »
FREESYNC ON, -notriplebuffer -nowaitvsync -throttle -nosyncrefresh -r 2560x1080@75



Is it a baseline with reordered execution? Or something different?
« Last Edit: July 26, 2019, 12:19:54 pm by oomek »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #97 on: July 26, 2019, 12:26:21 pm »
 :applaud:

It's something that should be submitted to MAMEdev. BGFX now allows setting max frame latency during initialization:

Code: [Select]
init.resolution.width = wdim.width();
init.resolution.height = wdim.height();
init.resolution.reset = BGFX_RESET_NONE;
init.resolution.numBackBuffers = 1;
init.resolution.maxFrameLatency = 1;

Baseline is not using this yet because the backend implementation was done before this feature was added.

Your device is a godsend, it's been so tedious to make these tests before.

EDIT: that build was current GM 211 with only those lines modified, so it also has the reordered main loop.

Now I'd like to build baseline with this patch only and with and without the reordered main loop, to see if it makes a difference.
« Last Edit: July 26, 2019, 12:33:25 pm by Calamity »
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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:Yesterday at 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #98 on: July 26, 2019, 12:52:47 pm »
It's something that should be submitted to MAMEdev. BGFX now allows setting max frame latency during initialization:
IIRC you've known that for quite a while and it seems it's even written in mame's docs, either no one there has paid attention or they have another reason not to use that...

Anyway, what results can we expect with sync though? the usual 3 frames?
« Last Edit: July 26, 2019, 12:54:55 pm by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #99 on: July 26, 2019, 12:56:05 pm »
:applaud:

It's something that should be submitted to MAMEdev. BGFX now allows setting max frame latency during initialization:

Ok, but tell me why you wanted me to test it with FS ON? On the chart only the baseline have 18ms latency. This build seems a full blown GM to me.

With FS OFF I get around 68ms with this build, just in case you wonder.
« Last Edit: July 26, 2019, 01:02:55 pm by oomek »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #100 on: July 26, 2019, 01:02:47 pm »
Ok, but tell me why you wanted me to test it with FS ON? On the chart only the baseline have 18ms latency. This build seems a full blown GM to me.

Ups, you're right...  it's BGFX+Freesync OFF what's relevant here, sorry.
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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #101 on: July 26, 2019, 01:05:37 pm »
With FS OFF I get around 68ms with this build, just in case you wonder.

That's 4 frames, but I guess the one that's removed is due to AMD's Anti-Lag rather than this patch.
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #102 on: July 26, 2019, 01:08:53 pm »
No, the anti-lag needs to be explicitly enabled in the radeon overlay for the specific executable. So it was off

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #103 on: July 26, 2019, 01:16:06 pm »
No, the anti-lag needs to be explicitly enabled in the radeon overlay for the specific executable. So it was off

Then it was the patch. But I wonder why it can't get even close to D3D9ex, when basically we're doing the same thing. And it's clearly the buffering since with Freesync BGFX doesn't lag more than D3D9ex.
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #104 on: July 26, 2019, 01:21:15 pm »
I tried the Anti-Lag with this build and it didn't change the results. Clearly the driver is doing exactly what your patch. It must be some extra buffering caused by the DWM in DX11

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #105 on: July 26, 2019, 01:34:36 pm »
I tried the Anti-Lag with this build and it didn't change the results. Clearly the driver is doing exactly what your patch. It must be some extra buffering caused by the DWM in DX11

Sure, you're right, it's the DWM, BFGX doesn't run in fullscreen exclusive mode.
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #106 on: July 26, 2019, 01:37:18 pm »
Your device is a godsend, it's been so tedious to make these tests before.



I've ordered another enclosure. I'm gonnna build you one.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #107 on: July 26, 2019, 01:40:22 pm »
 :notworthy: :notworthy: :notworthy:
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #108 on: July 26, 2019, 02:05:54 pm »
Enclosure, Teensy 2.0, TEMT6000 ordered, This particular OLED display I used is out of stock unfortunately, there are other very simillar, but I won't make a risk the possible dimension differences. I'll be keeping an eye on the stock.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #109 on: July 26, 2019, 02:12:05 pm »
Enclosure, Teensy 2.0, TEMT6000 ordered, This particular OLED display I used is out of stock unfortunately, there are other very simillar, but I won't make a risk the possible dimension differences. I'll be keeping an eye on the stock.

Thank you so much, this is the coolest device I can imagine.
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

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 03:26:55 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #110 on: July 26, 2019, 02:37:09 pm »
Soon oomek you'll have to add a little code to drive your device from the OS in order to run some big rounds of test batches  ;D

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #111 on: July 26, 2019, 02:39:56 pm »
Hehe, not a problem, Teensy also has raw hid protocol so I can push whatever data I need both ways.

Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 801
  • Last login:Today at 08:26:41 am
  • Budgets are boring
    • newforum.arcadecontrols.com/index.php/topic,156267.0.html
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #112 on: July 26, 2019, 02:51:37 pm »
Very excited to see what you guys come up with.  Seems like it might be possible to eliminate or severely close the gap on the emulation/PCB argument.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:Yesterday at 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #113 on: July 26, 2019, 03:18:12 pm »
Seems like it might be possible to eliminate or severely close the gap on the emulation/PCB argument.
Personally I had no doubt about Groovy's ability so for me it's been the case already for a long time. Now that proves it with hard figures (whether we're talking about frame_delay or FreeSync)
But we have nothing similar to bring out the drivers/games delay, and though that would be difficult to use I guess it would have to be a device based on movement detection. ^^
Something that might make it easier would be changing a targeted sprite onscreen into a black and white grid or mesh pattern (another LUA idea maybe?)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 801
  • Last login:Today at 08:26:41 am
  • Budgets are boring
    • newforum.arcadecontrols.com/index.php/topic,156267.0.html
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #114 on: July 26, 2019, 03:30:27 pm »
Personally I had no doubt about Groovy's ability so for me it's been the case already for a long time. Now that proves it with hard figures (whether we're talking about frame_delay or FreeSync)

Definitely, you summarized my sentiments better than I did in my last post. :applaud:

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #115 on: July 26, 2019, 03:53:24 pm »
I tried the Anti-Lag with this build and it didn't change the results. Clearly the driver is doing exactly what your patch. It must be some extra buffering caused by the DWM in DX11

Sure, you're right, it's the DWM, BFGX doesn't run in fullscreen exclusive mode.

In borderless vsync should be disabled and syncing should go through dwmflush() You may wanna check all my dwm related code in AttractMode, and my comments.

https://github.com/mickelson/attract/blob/master/src/fe_window.cpp


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #116 on: July 26, 2019, 04:49:50 pm »
In borderless vsync should be disabled and syncing should go through dwmflush() You may wanna check all my dwm related code in AttractMode, and my comments.

https://github.com/mickelson/attract/blob/master/src/fe_window.cpp

Thanks! So that sounds quite simple, you just need to call DwmFlush() after Present?
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: 236
  • Last login:Today at 07:18:03 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #117 on: July 26, 2019, 04:55:20 pm »
Yes, you swap buffers with vsync off and then just call dwmflush() and it waits for vsync, but keep in mind that it depends what kind of borderless window bgfx opens. Some flags treat window as exclusive fullscreen and windows' fullscreen optimizations kick in. I've had a lot of issues with that until I got it right.

There is also a part in AM where I set the number of prendered frames, but it's platform specific and relates to nvidia. The goal in Attract Mode was to increase it so the opposite of what we need here, I didn't have to deal with AMD api as it was ok on Radeons, anyway here's the part of the code that sets the frame queue size.

https://github.com/mickelson/attract/blob/master/extlibs/nvapi/nvapi.hpp

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 01:56:57 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #118 on: July 28, 2019, 01:05:33 pm »
Here's a new build using DwmFlush() for vsync on the BGFX backend:

https://drive.google.com/open?id=1NK2xaMud10SlUooStGqV_XbKvl36ESQ3

It'd be interesting to see if it finally matches D3D9ex.
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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:Yesterday at 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #119 on: July 28, 2019, 01:36:00 pm »
That would be a good thing because I think HLSL will get nuked some day.

About the other topic: how's your 15KHz FreeSync experience ?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15