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

0 Members and 1 Guest are viewing this topic.

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
GroovyMAME - Input Lag tests 2019 (new method)
« on: July 19, 2019, 06:22:22 pm »
GroovyMAME lnput lag database link

Hi, after a long break I've finally decided to finish my project, a proper input lag tester for MAME. I did some testing of the latest GM 0.211 release and the results are just outstanding!

Here is the device:


Here you can watch it in action:


And here are the results of the windows 7,8,10 Version of GroovyMAME:



pc specs: Windows 10, i7 8700K, Radeon Vega, LG 29UM67-P Monitor
« Last Edit: July 26, 2019, 06:06:04 am 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 #1 on: July 20, 2019, 04:07:44 am »
Sleekest looking lag tester for sure! Correct me if I'm wrong though but it's like the other sensor-based testers around? basically revealing the video chain delay.

EDIT: 'video d3d' question: you're not using a d3d9ex build in this test ? Also for baseline MAME; why syncrefresh nothrottle and not vsync throttle ? (the latter is somewhat the default most people use I believe)

Someone's tested your monitors with the LB tester at less than 3ms https://www.reddit.com/r/hardware/comments/3cil6y/lg_29um67_display_lag_tested_freesync_29_inch/
Which would mean frame_delay 9 adds less than 2ms, and in FreeSync this monitor leaves virtually none.
For frame_delay those are the results I expected.

Some time ago iirc you had posted per-game results (LED testing method) on FreeSync that basically revealed the base delay of various drivers in Groovy.
The uploaded picture's gone though, any chance you still have it ? http://forum.arcadecontrols.com/index.php/topic,153434.msg1607689.html#msg1607689

I've been thinking about building a database of per-driver lag test (starting with the most popular at least) so the various emulated systems/games 'default' natural delay would be known.
That would help demystify some beliefs in regards to lag in emulators and show better what Groovy can do, but I don't believe sensor-based testers can help there, can they?
« Last Edit: July 20, 2019, 04:19:46 am by schmerzkaufen »

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 #2 on: July 20, 2019, 05:29:36 am »
Hi oomek,

This is amazing! Thanks for this.

If I understand it right your device simulates button strokes through the usb port, then you have some pluggin or mod that makes MAME show a color box on the corner in response to input.

Some ideas about your results:

- MAMEdev BGFX lags 5 frames vs MAMEdev D3D 3.5 frames. That's a lot.

- MAMEdev D3D lags a whole frame behind Groovy D3D fd 0. I'm pretty sure this was introduced in baseline with the osd overhaul a couple of years ago or so. The fix is quite simple and it has to do with how inputs are polled rather than the video API. This means I could probably push it into baseline and it would cut one frame of lag for every video backend. With the help of your device you can do fast and exact measurements of latency before and after an specific modification, this will be basic if we're willing to submit any change to baseline.

- I also miss this specific measurement: Groovy D3D fd 0 vs Groovy D3D9ex fd 0.




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 #3 on: July 20, 2019, 08:38:20 am »
Sleekest looking lag tester for sure! Correct me if I'm wrong though but it's like the other sensor-based testers around? basically revealing the video chain delay.
Didn't see the other one, but yes. It's based on a high performance TEMT600 sensor.
Quote
EDIT: 'video d3d' question: you're not using a d3d9ex build in this test ? Also for baseline MAME; why syncrefresh nothrottle and not vsync throttle ? (the latter is somewhat the default most people use I believe)
It's the d3d9ex version tested ("video d3d" is the entry in the mame.ini). Why syncrefresh? It's a requirement, I need to have no dropped frames when game's frequency does not match the monitor's. Since the rom I'm using works at 59.17Hz I speed it up to 101% so it matches 60Hz of the monitor. Otherwise the lag spread will be higher than the frame time + usb overhead and you get skewed results. Autosync in GM does exactly the same, the game runs in 60Hz.
Quote
Someone's tested your monitors with the LB tester at less than 3ms https://www.reddit.com/r/hardware/comments/3cil6y/lg_29um67_display_lag_tested_freesync_29_inch/
Which would mean frame_delay 9 adds less than 2ms, and in FreeSync this monitor leaves virtually none.
For frame_delay those are the results I expected.
I did test on one of my monitors which has the lowest lag. The tests are button2screen with the optimal conditions ( highest hid polling rate and lowest lag lcd) My meter is able to detect whether it runs on a LCD or CRT and adapt to the pulsing vertical scans. More tests on a CRT TV soon.
Quote
Some time ago iirc you had posted per-game results (LED testing method) on FreeSync that basically revealed the base delay of various drivers in Groovy.
The uploaded picture's gone though, any chance you still have it ? http://forum.arcadecontrols.com/index.php/topic,153434.msg1607689.html#msg1607689
I'm gonna take a look, but those test had lower time resolution. With my new device I sample the sensor every 60 Microseconds. I'll test more. Just give me a shout what configs are required.
Quote
I've been thinking about building a database of per-driver lag test (starting with the most popular at least) so the various emulated systems/games 'default' natural delay would be known.
That would help demystify some beliefs in regards to lag in emulators and show better what Groovy can do, but I don't believe sensor-based testers can help there, can they?
Good idea, I was thinking exactly the same. Let's go for it. I recently tested RPI on a CRT TV with RGB-PI cable and the resuls were unsuitable for my needs 50-70ms range is the norm on this platform. (lr-mame2003/2010)

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 #4 on: July 20, 2019, 08:50:28 am »
Hi oomek,

This is amazing! Thanks for this.
You are welcome mate, I'm sorry it took so long to complete. I got distracted with Attract Mode developement.
Quote
If I understand it right your device simulates button strokes through the usb port, then you have some pluggin or mod that makes MAME show a color box on the corner in response to input.
This is correct. I modded the thunderx rom's tiles so 0 is a full black square and 1 is white. To make it move to the corner I just offset the screen in the cfg file for this rom.
Quote
Some ideas about your results:

- MAMEdev BGFX lags 5 frames vs MAMEdev D3D 3.5 frames. That's a lot.
It is true, BGFX has too many buffering going on. I use only HLSL in my cab if I have to add some scanlines.
[/quote]
Quote
- MAMEdev D3D lags a whole frame behind Groovy D3D fd 0. I'm pretty sure this was introduced in baseline with the osd overhaul a couple of years ago or so. The fix is quite simple and it has to do with how inputs are polled rather than the video API. This means I could probably push it into baseline and it would cut one frame of lag for every video backend. With the help of your device you can do fast and exact measurements of latency before and after an specific modification, this will be basic if we're willing to submit any change to baseline.
Don't do it :P Only if they come to you when they se the comperhensive lag database and their position on the bottom end :)
Quote
- I also miss this specific measurement: Groovy D3D fd 0 vs Groovy D3D9ex fd 0.
Will do it today. You're talking about your 2 GM exe files you usualy release? I did testing on Win7,8,10 version, it's how it is called now, isn't it?
« Last Edit: July 20, 2019, 08:52:15 am 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 #5 on: July 20, 2019, 09:20:27 am »
Thanks for the details.

Other sensor-based testers: Leo Bodnar lag tester, Time Sleuth lag tester, OSSC built-in lag tester...
Their purpose is to test the delay chain but not including the running program's internal lag/time (which people typically use led+camera to find out)
The last one (OSSC) can work with whatever the source makes the screen sync on, not locked to 60Hz, the first to are 60 or 50Hz only iirc.

Which hardware the tests are run on isn't very important to me as long as the specifics (controller/display/os/etc) are know with precision since their times can be substracted afterwards. But yeah it's better to go straight for a fast setup like a low lag LCD or CRT.

Anyway what matters in the idea I have to find out the game's (or at least each system's in mame) default delay internally (w/ or w/out autosync+fd) neogeo, cps123, toaplan, psikyo taitof2/3, cave, etc and tens of others separately
I'm saying that but since I don't really understand how your test works I don't know if it's possible, sorry if I misunderstood.  ;D

« Last Edit: July 20, 2019, 11:06:11 am by schmerzkaufen »

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 #6 on: July 20, 2019, 09:40:25 am »
My device can measure in any framerate, but I take the readings in standard 60Hz.

The specs of my setup are in the first post.

Testing platforms is a completely different story. The aim of my tests is to measure the performance of the api used for drawing and input device polling. I chose Thunder Cross rom as it was easy to mod and because I knew that it's service screen does not have any sprite buffer active. If somehow we can mod the other mame platform's roms' or find an area of the screen that can switch from black to white by the press of a button it could be possible also to measure an additional overhead of different mame emulated platforms.

My device is simply acting as high polling rate keyboard and outputting KEY_LEFT commands. At first it measures the white levels min/max then black's min/max and based on that sets the threahold to black_max * 2 or 3 for the CRT. Then it starts the timer and sits in the loop sampling the sensor. I chose the threshold to be as low as possible to eliminate the display's pixel response time as much as I can. I can post the sourcecode on github so you can take a look.
« Last Edit: July 20, 2019, 09:46:16 am 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 #7 on: July 20, 2019, 09:46:55 am »
Thank. Sorry I am not nearly as techically savvy as you guys, I misunderstood the purpose.

What I'm looking at is reavealing is the various game's/mame's internal lag per game or driver, since we mostly already know the truth about the API's and the differences thanks to your tests (and well' know even more about now thanks to your new method!)

Seems like for the internal I'm stuck with the old led+camera method then. ^^

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 #8 on: July 20, 2019, 10:51:52 am »
I'm just wondering about one thing. Taking 1000 samples gives me the repeatability of the results within +/-0.2ms range. The more samples I take the more accurate the results are. I use a random delay in the frame time range to get an even spread by decoupling the key presses from the refresh rate. Still wondering how to increase the accuracy without leaving the meter on the screen for several hours, yes I know, I'm a little paranoid in this matter.
« Last Edit: July 20, 2019, 10:54:21 am 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 #9 on: July 20, 2019, 11:15:05 am »
Quote
- I also miss this specific measurement: Groovy D3D fd 0 vs Groovy D3D9ex fd 0.
Will do it today. You're talking about your 2 GM exe files you usualy release? I did testing on Win7,8,10 version, it's how it is called now, isn't it?

If you tested on the win_7_8_10 version then that's the D3D9x one, probably you should clarify this to avoid confusion.

If this is the case then it will invalidate my comment above, since the observed latency cut may be caused by D3D9x (Groovy) vs D3D (MAMEdev) alone, rather than the way inputs are polled in Groovy.
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 #10 on: July 20, 2019, 12:31:22 pm »
Just one question: I thought that when running a d3d9ex build without frame_delay (0) we got just 1 frame of lag for sync, but in oomek's measurements it seems frame_delay 1 is in fact still required to get that. Or am I reading that wrong ?

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 #11 on: July 20, 2019, 01:52:52 pm »
<troll>Curious to make the same tests with linux version :D</troll>

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 #12 on: July 20, 2019, 02:05:57 pm »
<troll>Curious to make the same tests with linux version :D</troll>

Funny! I was talking to mr oomek earlier about the same thing! Linux vs Windows for GM - the final answer on lag!

Thank you all again for hard work. :cheers:

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 #13 on: July 20, 2019, 02:12:31 pm »
Test's of GroovyArcade vs Windows will be posted as soon as I find a spare ssd. I assume you would like to see all 3 right? GA, Win10 GM, WinXP GM compared side by side? What framedelay settings?

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 #14 on: July 20, 2019, 03:54:09 pm »
A reseonnable and relevant frame delay ? Lol

I just remember some tests that were made 2 years ago on retroarch with a much more "homemade" system afair ... ALED wired to a pad that would turn on when a button is pressed + high speed camera. And of course, one couldn't avoid a windows/linux duel hahaha

In fact, I'm much more interested into your device ! Is it something you made yourself ? I find it just great, i'm curious to know what's under the hood.

The other question that comes to my mind is : should such tests also be run on a crt screen ? Can you evaluate the USB delay ? At which grey/white level does your device trigger ? Would turning things to maths help ? Like how to choose a monitor, what maximum response time is expected, etc ...

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 #15 on: July 20, 2019, 06:10:56 pm »
Is it something you made yourself ? I find it just great, i'm curious to know what's under the hood.
Yes, I bought the case for it like 2 years ago and it stayed in the drawer until 2 weeks ago.
It's based on the Teensy 2.0 Arduino compatible board, TEMT6000 phototransistor a SSD1306 compatible OLED display 128x64 pixels, 2 buttons and a universal pcb cut to shape, so not that complicated. The true magic is in the software I wrote in C++.



Quote
The other question that comes to my mind is : should such tests also be run on a crt screen ? Can you evaluate the USB delay ? At which grey/white level does your device trigger ? Would turning things to maths help ? Like how to choose a monitor, what maximum response time is expected, etc ...
My device can detect on which display is running and adapt thresholds accordingly. I did my tests on both CRT and LCD. On CRT only with Raspberry PI so far as I'm yet to connect my PC to my CRT TVs. Got hdmi2vga adapter this week, just need to solder a cable hga2scart and I'm ready to go. Some people are saying you can run freesync on a CRT, cant wait to test that theory.

The USB delay is in spread in 0-1ms range as I set the polling rate to 1000Hz in the HID descriptor.

I detect the reading ranges of black and white ie. black 0-8 white 700-710 The values are from the Arduino's analogRead() function which has a range of 0-1023 and then calculate the thresholds:
Code: [Select]
if (display_crt)
{
sensor_thr = sensor_off_max * 3;
sensor_thr_off = sensor_off_max * 2;
}
else
{
sensor_thr = sensor_off_max * 2;
sensor_thr_off = sensor_off_max * 3 / 2;
}

So for an LCD it will be 16/710 = 2.25% of the maximum brightness. For a CRT it's a bit higher as the rising slope is much quicker.



As you can see the thresholds I set are at a bare minimum so I take out of equation a pixel response time as much as I can.
« Last Edit: July 20, 2019, 06:46:01 pm by oomek »

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #16 on: July 20, 2019, 06:15:52 pm »
Personally I would only take CRT measurements as a valid approach for good reference and future comparison. With any new/old LCD/IPS type of screen the driver will for sure add some delay.

I am also curious about the Linux side ;-)

To avoid rom hacking and allow measurements with any game (in case of comparison with real hw) it is also possible to create a lua script that has the same behaviour as the black/with sprite on the top left hand corner.


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 #17 on: July 20, 2019, 06:19:44 pm »
As I wrote in my previous post the testing on CRT will happen in a day or 2.
I was considering lua, but I was too lazy to go through the vague documentation for it, or lack of it. If you have any link that explains how to draw on the screen and grab input events, drop it here, so I could use it as a starting point.
« Last Edit: July 20, 2019, 06:21:15 pm by oomek »

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #18 on: July 20, 2019, 06:21:04 pm »
I was considering lua, but I was to lazy to go through the vague documentation for it, or lack of it. If you have any link that explains how to draw on the screen and grab input events, drop it here, so I could use it as a starting point.
Let me see if I can get access to my remote system.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #19 on: July 20, 2019, 06:56:39 pm »
I was not able to put my hands on my script.

I remember someone did put a script on the forum a long time ago to display a frame counter on top of the picture. Atm I have only my phone to connect which makes the process of digging further a real pain. I will provide an update as soon as I have access to my pc.

If I am not mistaken Olin has also written a lua script displaying on screen frame information.

I am not of great help on this one.

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 #20 on: July 20, 2019, 07:02:27 pm »
If hypothetically I go with LUA there are 2 questions remaining:

1. Is LUA present in lr-mame2003?
2. Is input polling done at the same time and interval as for the game?
« Last Edit: July 20, 2019, 07:04:40 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 #21 on: July 20, 2019, 07:07:44 pm »
I have improved the lag results accuracy a bit. It turned out that when I wait in a loop that has a function to decouple the input from the framerate the sensor's impedance builds a charge and returns a bit higher values. I fixed that by sampling the sensor even during waiting. I think it's caused by me changing the resistor on TEMT6000 from 10k to 220k to boost the signal.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #22 on: July 20, 2019, 07:11:53 pm »


If hypothetically I go with LUA there are 2 questions remaining
1. Is LUA present in lr-mame2003?
2. Is input polling done at the same time and interval as for the game?

I can only answer your 2nd question. Yes, the onscreen is done at game refresh rate. You can also automate the input and have the game polling done in sync with the frame counter. Polling of the frame counter gives you control on the tick for events. LUA does not change the default game behavior.

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 #23 on: July 20, 2019, 07:16:08 pm »
Ok, thanks, let's dig into it once again.

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 #24 on: July 20, 2019, 10:08:46 pm »
This is what I've got so far:

Code: [Select]
-- license:BSD-3-Clause
-- copyright-holders:Radek Dutkiewicz
local exports = {}
exports.name = "inputlag"
exports.version = "1.0.0"
exports.description = "Input Lag Test"
exports.license = "The BSD 3-Clause License"
exports.author = { name = "Radek Dutkiewicz" }

local inputlag = exports

function inputlag.startplugin()
local scr = {}
local inp = {}
local pressed = false

local function draw_square()
local pressed = inp:code_pressed(inp:code_from_token("KEYCODE_LEFT"))
if pressed then
scr:draw_box(0, 0, scr:width() / 8, scr:height() / 8, 0xff000000, 0);
scr:draw_box(0, 0, scr:width() / 16, scr:height() / 16, 0xffffffff, 0);
else
scr:draw_box(0, 0, scr:width() / 8, scr:height() / 8, 0xff000000, 0);
end
end

emu.register_start(function()
scr = manager:machine().screens[":screen"]
inp = manager:machine():input()
emu.register_frame_done(draw_square)
end)
end

return exports

It's working, but I'm pretty sure I'm not getting the input of the game's core with any potential delays, just raw Mame engine's input. Also framedelay 1-9 isn't doing anything.
LUA isn't that bad, but I have to emphasise, documentation of the functions exposed by Mame for LUA is almost non existent.
« Last Edit: July 20, 2019, 11:54:00 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 #25 on: July 20, 2019, 11:34:34 pm »
There is one more thing that bothers me. I have sporadical tearing on 4-8 top rows when I set frame delay > 0 ( doesn't matter how big the number is )
Is there something wrong with my crt_range?
Code: [Select]
crt_range0                54048.00-81072.00,48.00-75.00,0.593,0.297,0.998,0.059,0.074,0.534,1,1,1080,1080,0,0
I use resolutions 2560x1080@75 for freesync and @60 for syncrefresh

This sometimes skews the results, but I can usually catch that because the lag spread in this case is around 30ms
« Last Edit: July 21, 2019, 06:24:56 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 #26 on: July 21, 2019, 05:32:58 am »
lr-mame2003 ? Does it mean you intend to test lag input in retroarch (and most probably a pi) ? Reminds me of an old troll regarding bluetooth input lag

Testing retroarch with linux, would be funny to compare KMSDRM video driver vs X11.

Now you've advertised your genius device, you'll get quite some tests queries lol

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 #27 on: July 21, 2019, 06:02:48 am »
I've already done tests on RPI with LCD and CRT and the results were unimpressive. Couldn't get the white sprite in some of mame versions to the top left corner except lr-mame2010, other emus don't have screen position sliders. That's why i was asking if lua works in LR. I did GL through Kms vs native Dispmanx and the second wins, but still in 50ms range

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 #28 on: July 21, 2019, 06:13:37 am »
I'm gonna take a look
Any luck with that ?

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 #29 on: July 21, 2019, 06:18:59 am »
I'm gonna take a look
Any luck with that ?

Link fixed by just changing the domain from postimg.org to postimg.cc

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 #30 on: July 21, 2019, 06:26:27 am »
Thank you, I wanted to see it again. Even in that old test the difference is striking!

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 #31 on: July 21, 2019, 03:46:44 pm »
There is one more thing that bothers me. I have sporadical tearing on 4-8 top rows when I set frame delay > 0 ( doesn't matter how big the number is )
Is there something wrong with my crt_range?
Code: [Select]
crt_range0                54048.00-81072.00,48.00-75.00,0.593,0.297,0.998,0.059,0.074,0.534,1,1,1080,1080,0,0
I use resolutions 2560x1080@75 for freesync and @60 for syncrefresh

This sometimes skews the results, but I can usually catch that because the lag spread in this case is around 30ms

There's always some jitter affecting direct retrace polling that is irrelevant for CRTs but gets evident on LCDs where the gpu has more work with scaling. Play with -vsync_offset, start with a low value until you get rid of the tearing. This will reduce the effectiveness of frame delay so just use a small value that works as a security buffer against jitter.
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 #32 on: July 21, 2019, 08:03:13 pm »
That worked, thanks, I was so used to freesync that I forgot about vsync_offset

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 #33 on: July 21, 2019, 08:07:42 pm »
Tomorrow I'm doing a crazy test

Radeon Vega->HDMI2VGA adapter->VGA2SCART cable->CTR TV

Freesync Enabled



« Last Edit: July 21, 2019, 08:15:48 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 #34 on: July 22, 2019, 02:15:00 am »
Just by curiosity if you find the time try a testing run on LCD with HLSL on (you might need to increase vsync_offest a bit).

Matter of confirming it doesn't really add delay as some have been concerned about.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #35 on: July 22, 2019, 09:30:12 am »
I'm just wondering about one thing. Taking 1000 samples gives me the repeatability of the results within +/-0.2ms range. The more samples I take the more accurate the results are. I use a random delay in the frame time range to get an even spread by decoupling the key presses from the refresh rate. Still wondering how to increase the accuracy without leaving the meter on the screen for several hours, yes I know, I'm a little paranoid in this matter.

You said it yourself: You want an even spread. Ie you want a uniform distribution across the time period. It happens that a random input will eventually approximate to a uniform distribution (if the random generator is good) but you can go straight to the uniform distribution.

You will be amazed how quickly you can get the same results that you've been getting with 1000 samples.

« Last Edit: July 22, 2019, 09:32:24 am by jimmer »
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 ?

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #36 on: July 22, 2019, 09:58:04 am »

By the way, Good work   :applaud:

That graph of sensor response for LCD vs CRT makes me a little sad.  If you have a fast TN panel I'd love to see the same graph for that.
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 ?

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 #37 on: July 23, 2019, 09:47:27 am »
Holy sh*t! It's really working! Freesync on a CRT




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 #38 on: July 23, 2019, 10:07:03 am »
Can you describe your setup and settings? :cheers:

Nice work!

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 #39 on: July 23, 2019, 10:15:49 am »
Radeon RX 460 -> hdmi2vga converter -> vga2scart cable
Defined resolution 2560x240@60 in CRU (no CRTemu driver installed)
Freesync ranges added 28-60
GM launched with everything off: triplebuffer, vsync, syncrefresh keepaspect
Tested 2 games shdancer 57.23Hz and thunderx 59.17Hz
All smooth, no stutter, or tearing, 100% emulation speed.

The photo of the adapter and the schematic of the cable is in my previous post.
Warning: scart2vga cable has different wiring. You have to make it yourself. I could not find any vga2scart on ebay only scart2vga
« Last Edit: July 24, 2019, 08:01:37 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 #40 on: July 23, 2019, 10:55:49 am »
Got 2 vga2scart : one I made myself with schematics close to yours but partially adapted to a Pi for testing under Recalbox

For groovyarcade, I bought a vga2scart from retrocables.es which worked fine for me

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 #41 on: July 23, 2019, 11:06:16 am »
It's the same schematic. When it comes to vga2scart hdmi2scart be careful. Some adapters output composite only through scart and some have a scaler. You need pure DAC without any buffering.
« Last Edit: July 23, 2019, 12:20:21 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 #42 on: July 23, 2019, 11:36:25 am »
Radeon RX 460 -> hdmi2vga converter -> vga2scart cable
Defined resolution 2560x240@60 in CRU (no CRTemu driver installed)
Freesync ranges added 28-60
GM launched with everything off: triplebuffer, vsync, syncrefresh keepaspect
Tested 2 games shdancer 54.7Hz and thunderx 59.17Hz
All smooth, no stutter, or tearing, 100% emulation speed.

The photo of the adapter and the schematic of the cable is in my previous post.
Warning: scart2vga cable has different wiring. You have to make it yourself. I could not find any vga2scart on ebay only scart2vga

That's awesome!

Do you have any issues with vertical centering? Freesync keeps adding extra blanking lines until the retrace is requested, this in theory might cause the picture to be shifted up on a CRT since these are not designed to ignore those extra blanking lines.

Also, how do you force Freesync enabled on a CRT? CRU?
« Last Edit: July 23, 2019, 11:42:17 am 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 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 #43 on: July 23, 2019, 11:42:38 am »
So far vertical pos seems ok, but I need to test more games to be sure. I just got one issue very occasional frame jumps, like it's loosing vsync pulse, maybe my cable is not properly shielded? And constant vertical desync when I pause the game, this one is weird, any ideas?

Update: when pause is pressed the screen goes out of syync vertically, but when I release pause it turns stable for 1/2 second, but in ntsc mode, then it goes back to full screen.
« Last Edit: July 23, 2019, 12:01:10 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 #44 on: July 23, 2019, 12:02:06 pm »
It's the same schematic. When it comes to vga2scart be careful. Some adapters output composite only through scart and some have a scaler. You need pure DAC without any buffering.
The cabke from retrocables.es is not much different from the schemalics we have, takes power from USB and has a male jack for sound, no fancy electronics for scaling, synchro or whatever else.

VGA already outputs analog RGB, why need a DAC ?

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 #45 on: July 23, 2019, 12:03:59 pm »
Hdmi2vga = DAC

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 #46 on: July 23, 2019, 12:07:13 pm »
So far vertical pos seems ok, but I need to test more games to be sure. I just got one issue very occasional frame jumps, like it's loosing vsync pulse, maybe my cable is not properly shielded? And constant vertical desync when I pause the game, this one is weird, any ideas?

That's normal since the screen is not updated while in pause. Also occasional desync is not surprising since you're basing all video timing on the CPU timer which is not fully reliable. To make this absolutely perfect we could use freesync in combination with direct raster polling, for lagless vsync (not sure if this makes sense, I need to think about it).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead 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 #47 on: July 23, 2019, 12:11:02 pm »
Thanks, that all make sense, you're aware that this is the holy grail when it comes to running mame on a CRT :) Still can't believe it actually worked, playing various games now with a big smile on my face :D

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 #48 on: July 23, 2019, 12:15:52 pm »
You think HPET would work for that? Tweaking now vertical timings now to see if it makes any difference.

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 #49 on: July 23, 2019, 12:23:18 pm »
One more thing I've noticed. When I set frame delay > 0 the screen goes black

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 #50 on: July 23, 2019, 12:29:47 pm »
Restoring the use of QueryPerformanceCounter for the timer rather than crappy standard library might improve things a bit but CPU clocks are not good enough for this, you need to poll the raster position.

Please tell me how you forced Freesync, I want to test it here.
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

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 #51 on: July 23, 2019, 12:31:02 pm »
One more thing I've noticed. When I set frame delay > 0 the screen goes black

Frame delay can't work without syncrefresh the way it is now.
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 #52 on: July 23, 2019, 12:41:52 pm »


gm211 -aspect 4:3 -nowaitvsync -notb -noka -unevenstretchx -intscaley 1 shdancer

Freesync does not work in extended desktop mode (at least with a CRT), so prepare to switch a lot with Windows+P. I also failed to force GM to switch to my resolution switchres doesn't see it for some reason, So I've set the res with this tool to 2560x240@60
http://tools.taubenkorb.at/change-screen-resolution/


UPDATE 1: Don't forget to enable Freesync in Radeon Settings for your hdmi2vga dongle display device.

UPDATE 2: Set the refresh rates in all 3 places to 63Hz instead of 60Hz, otherwise 60Hz games will have tearing.
« Last Edit: July 24, 2019, 07:45:10 am 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 #53 on: July 23, 2019, 04:36:47 pm »
What is the best desktop-like resolution I can get on RX 460 and a CRT without CRTEmu driver? Tried 576x480i but I think the pixel clock is too low. I don't actually understand what is the limiting factor, could you explain please?
« Last Edit: July 23, 2019, 04:42:03 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 #54 on: July 23, 2019, 05:29:28 pm »
(ordered a couple hdmi>vga dongles, I'm too curious about this, and it was time to put my 470 to test on CRT anyway)

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #55 on: July 23, 2019, 08:31:05 pm »
Wow thats again truly amazing, next milestone happening here. Much respect!

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 #56 on: July 24, 2019, 05:21:12 am »
Please tell me how you forced Freesync, I want to test it here.

How is it going mate?

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 #57 on: July 24, 2019, 07:23:01 am »
Here's an update of my observations. Games like shinobi (60Hz) have tearing. Bumping the superresolution and both Freesync ranges in CRU to 63Hz fixes it.

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 #58 on: July 24, 2019, 07:28:36 am »
Here's an update of my observations. Games like shinobi (60Hz) have tearing. Bumping the superresolution and both Freesync ranges in CRU to 63Hz fixes it.

Yeah, I was about to post about this, I'll update in a while...
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

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 #59 on: July 24, 2019, 02:06:01 pm »
Following Oomek's advice I've been successfully testing Freesync on a CRT using my new Ryzen 5 2400G, both by VGA and HDMI->VGA. My results so far show this can actually work with some effort. However once Freesync is enabled and MAME starts sending frames the screen starts to bounce up and down due to the random padding being applied. I haven't managed to get it stable. I'm testing this on a BVM. When tested on my regular PC CRT it just goes blank after a short period. I still need to compile a custom GM version that uses raster polling instead of the CPU clock to see if this makes it stable, hopefully in the next days.
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 #60 on: July 24, 2019, 03:34:00 pm »
Fingers crossed.
This thread took an unexpected turn, and I'll be glad if this goes well to have limited my used AMD cards acquisitions exclusively to models featuring FreeSync thinking 'you never know'.
Can all of them manage FreeSync via HDMI though ?

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 #61 on: July 24, 2019, 08:25:25 pm »
Oomek, did you mention what CRT display you are using?

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 #62 on: July 24, 2019, 10:54:36 pm »
It's Bang&Olufsen Beovision1

Torkyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 34
  • Last login:November 29, 2023, 07:12:04 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #63 on: July 25, 2019, 11:53:00 am »
I'm wondering if G-Sync card/ monitor may have some benefit in this potential custom GM version

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 #64 on: July 25, 2019, 09:10:16 pm »
I've added a link in the first post to the spreadsheet that I'll be constantly updating with new measurements.


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 #65 on: July 25, 2019, 11:38:36 pm »
URL no good in Tapatalk....

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #66 on: July 26, 2019, 04:46:11 am »
Are you planning to do a test for retroarch on windows too? Would be interesting.

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 #67 on: July 26, 2019, 04:47:51 am »
Sure, why not

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 #68 on: July 26, 2019, 05:10:05 am »
I've added a link in the first post to the spreadsheet that I'll be constantly updating with new measurements.
Oops, it's private, requires an account...

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 #69 on: July 26, 2019, 05:21:28 am »
Is the link working now?

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #70 on: July 26, 2019, 05:27:49 am »
Sure, why not
Looking forward for the results.
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.

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 #71 on: July 26, 2019, 05:30:18 am »
No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #72 on: July 26, 2019, 05:37:45 am »
No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core
I was under the impression that runahead compensates for input lag that is naturally occuring in the game itself, not the emulator.

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 #73 on: July 26, 2019, 05:54:12 am »
Is the link working now?
Yup!  ;)

No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core
There is no 'natural delay that comes with emulators', each and every case is a delay chain that can be explained taking into account the hardware/game that's emulated, then what's used for generating video and the options for sync. The issue with run-ahead isn't that it's not capable but rather that it doesn't mind any of that and is therefore often misused.
It gets much more complicated with arcades emulation where the many game's inherent lag figures aren't known (you won't find a reliable database with measurements, just random statements) and even more so when RetroArch is involved because of its several features other than run-ahead that can each play a part. Compared to Groovy that means many added variables, some people combine run-ahead (or try to) with other features like hard gpu sync, RA's own frame_delay, some even disable all vsync, some use Vulkan, etc etc.
Add to that the general confusion of it's massive pool of users and you know lag reduction with RetroArch works but is a complete black hole of a mess in terms of accuracy, if oomek starts measuring lag in RA then good luck to him taking all that into account.
Features like frame_delay however (at least as its implemented in Groovy) or FreeSync, are better known quantities - and even more so now thanks to oomek's work - that guarantee to not hamper accuracy at the very least (they eliminate lag that's on top of the emulated games, working on things like video sync buffer frames or inputs polling, not the game's inherent/natural delay which remains untouched)

I was under the impression that runahead compensates for input lag that is naturally occuring in the game itself, not the emulator.
As I've worded just up there, it completely depends on the (too-many in RA) settings that have an influence on the matter, run-ahead can either eliminate only the superfluous/eyesore delay, or be pushed further to eliminate the game's legit delay too.
If RA had a 'delay accuracy safeguard' optional program that takes everything into account, its choices for lag reduction wouldn't be so controversial.
Problem is a portion of the RA demographics argues that it's okay to eliminate even the legit delay (some go as far as deny it even exists), I guess that somehow supports the libretro devs into leaving things as they are...
« Last Edit: July 26, 2019, 06:24:52 am by schmerzkaufen »

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 #74 on: July 26, 2019, 06:42:38 am »
Run-Ahead is a hack and per core/game optimization. The aim of my tests is to measure the latency that only the graphics API introduces. If I start comparing Groovy to Libretro I'm not gonna be touching run-ahead, but only driver related settings.

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #75 on: July 26, 2019, 06:48:37 am »
Run ahead for itself is just the removeval of full legit delayed frames, done with savestates.
For me it feels wrong (not laggy just somehow wrong and not like it should feel) like with the lag compared with original hardware.
Only gm gives perfect feeling and its too bad if one can sense the smallest differences with input behavior.
Hell from my point of view (correct me anyone), the main thing for a good feel is that d3d9ex thing which is only used in gm so far right? The next thing would be freesync and theres no newd for more right?


Can one set the freesync range for each modeline? Like for 60hz modelines having a range 58-61hz, so when the timing goes off like a spike to 57hz or when you pause the emulation etc, the frames would be duplicated to keep 58hz and the picture would not shake or go crazy/blank?
« Last Edit: July 26, 2019, 06:54:40 am by MrMikeZH »

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 #76 on: July 26, 2019, 06:59:13 am »
I agree. The delay that is a part of a game core is not my concern. To be honest I still don't fully understand the exact mechanism of run-ahead, but I have a feeling that you miss some frames when an input is triggered.

According to my tests the advantage of D3D9ex version only manifests with -fd 0 and Freesync OFF. Both versions are faster than baseline with Freesync ON and with with Freesync OFF when -fd > 0 This is a bit unexpected surprise to me.

To use freesync you only make one resolution with a refresh rate that is bigger than the maximum games refresh rate. I have defined a resolution @75 hz and it covers all games that have lower refresh. When it's higher you get tearing as freesync is disabled in that case.
« Last Edit: July 26, 2019, 07:53:51 am 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 #77 on: July 26, 2019, 07:00:54 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.

Hell from my point of view (correct me anyone), the main thing for a good feel is that d3d9ex thing which is only used in gm so far right?
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).
But maybe I've read that wrong.
Then if you can push frame_delay high-enough even that frame gets shrinked bit-by-bit until there's like only 2ms left between you and the game.
Personally I'm already super happy with frame_delay at 5 and up (only about half-a-frame of delay left)

The next thing would be freesync and theres no newd for more right?
Holy Grail as oomek rightly said.
« Last Edit: July 26, 2019, 07:26:32 am by schmerzkaufen »

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #78 on: July 26, 2019, 07:23:15 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?

« Last Edit: July 26, 2019, 07:25:29 am by Recapnation »

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #79 on: July 26, 2019, 07:26:11 am »
I agree. The delay that is a part of a game core is not my concern. To be honest I still don't fully understand the exact mechanism of run-ahead, but I have a feeling that you miss some frames when an input is triggered.

According to my tests the advantage of D3D9ex version only manifests with -fd 0. Both versions are faster than baseline for freesync and with fd > 0 This is a bit unexpected surprise to me.

To use freesync you only make one resolution with a refresh rate that is bigger than the maximum games refresh rate. I have defined a resolution @75 hz and it covers all games that have lower refresh. When it's higher you get tearing as freesync is disabled in that case.


Interesting, so the odd feeling i got with run ahead could be the missing frames (the movement on the screen apart from your controlled sprite which dont move if legit delayed frames are missing).

So how can we get freesync to not stress our monitors to death when going out of sync?

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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 of pasting it.

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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • 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: 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 #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: 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 #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: 48
  • Last login:March 21, 2021, 04:41:43 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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
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.

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 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: 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 #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: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
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 »

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 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: 332
  • Last login:December 01, 2023, 07:39:55 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: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • 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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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 »

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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 of pasting it.

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

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 #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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 of pasting it.

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

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 #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: 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 #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
  • ***
  • 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 #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: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
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?)

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 #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: 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
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 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 #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 ?

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 ?

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 #160 on: August 13, 2019, 10:49:50 am »
That's correct. My device is measuring the rendering backend.

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 #161 on: August 13, 2019, 10:55:55 am »
First batch (30 PCBs) is in production. I'll be taking orders in about a week.

I've upgrqded the design by adding a reference voltage regulator for the ADC to minimize the noise coming from the phototransistor.



I have in plans to extend the functionality to measuring just the display lag (like Leo Bodnar), I'm going to write a separate app for that. I'm also thinking of making it able to measure conventional Windows games (3DMigoto or ReShade injector will be perfect for that)

There is a pinhole on the back to triger FW update in case I develop other testing modes.

I'm not advertising it anywhere outside this forum and AttractMode discord channel. So you guys have a chance to test it and send your thoughts ;)
« Last Edit: August 13, 2019, 11:06:18 am 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 #162 on: August 13, 2019, 11:01:11 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 ?

Indeed as he says oomek's test is for everything that affects delay on top of the game's emulation itself (afaik: video sync, input polling)

I don't know about the generated square's reliability, but the figures he got at the very least match the theory behind Groovy's use of d3d9ex and frame_delay very well.


But yeah for measuring the delay of an emulated game system itself, usually people use a LED wired to a button and record with a high-speed camera, etc, but it's bothersome and how to use and count varies with people, settings, hardware...

The drivers made by MAMEdev aim at accuracy, so if we could manage to more reliably and easily measure delay of the core emulation like that, taking out the other lag sources (OS, controls pcb, monitor, vsync, etc) the values collected should match the 'natural' original delay of the games running on the original arcade boards.
(or at least pretty close, MAME emulates in frames and is not 100% accurate, also sometimes it uses other emulated devices and other specialized drivers in conjunction with the game/system's core, which can add lag...I think? anyway that too would be revealed)

The many, many individual games/system's delay in MAME is one of the biggest black holes in the world of emulation, and at the source of a lot of confusion and conflicting narratives, it would be great if someday a testing method could shed enough light on this. A database of measurements could then be built and easily updated.
« Last Edit: August 13, 2019, 11:02:44 am by schmerzkaufen »

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 #163 on: August 13, 2019, 11:08:43 am »
The square is overlayed on top of the frame that is currently scheduled to be displayed, so it's accurate

P.S. I've updated my previous post.

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 #164 on: August 13, 2019, 02:17:15 pm »
Thank you both for the clarification.

Now, for emulation lag, here is an idea. Not perfect, not real time, but not the hardest to setup :
- record a ingame video with MAME (it MUST record the squares displayed by oomek's lua plugin)
- probably convert the video
- for each game, define the zone we expect to catch the result of the input (coin added so credits++, character jumped etc ...) + where the white square appeared
- use some image processing library. Python is very good at this

It sadly has the drawback of not knowing the rendering lag measured by oomek's device at processing (should be a simple addition) + if recording has an impact on emulation. But it's just software to setup. And multiplatform. Windows vs Linux war troll spotted  ;D

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 #165 on: August 13, 2019, 04:48:19 pm »
Just for those skeptical, oomek's method is correct. Lua gets input just at the same time the emulated system does, and it uses the same video pipeline with its potential undesired buffering, etc. That's all we need to care. The game added latency is irrelevant for the measurement, indeed it's been an obstacle in the past, that's why we always looked for the few games known to be next frame responsive in order to perform the tests. By the way, high speed camera tests with a wired led are whatever you want except controversial. They're a pain in the ass to perform, but the results are unquestionable.
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 #166 on: August 13, 2019, 05:29:59 pm »
Code: [Select]
[quote author=Calamity link=topic=160722.msg1694247#msg1694247 date=1565729299]
Just for those skeptical, oomek's method is correct.
Personally I haven't been since the first test result he posted. Substracting the lag of the monitor he used what's left matches what you were saying from the beginning.

By the way, high speed camera tests with a wired led are whatever you want except controversial. They're a pain in the ass to perform, but the results are unquestionable.
The variables I've mentioned are what makes the results controversial. I mean, if someone like you or the boys here did them I'd trust the results. Outside though I have seen too many inconsistent/untrusty stuff.
The difference a non-camera test with a dedicated device and software a la oomek's (or whatever else) would make is that it would take the uncertainties and inconsistencies out, just like now with the current test he created, and the easiness would allow to verify a ton of drivers rather quick.

It's the last dark area, last frontier of demistifying the total delay chain and it matters a huge deal to the whole world of emulation, just, people haven't realized how much yet (not for a little community like here where a handful of people don't need to know because they understand how it works, but for most of everyone else out there)

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 #167 on: August 13, 2019, 05:50:38 pm »
Another great advantage of having a database of absolute minimum lags for certain driver/video pipeline is that you know what the latency should be, and if it isn't you can start looking for devices in the chain that add to the lag ie display's processing, laggy input device, buffered video converters, you name it.
« Last Edit: August 13, 2019, 05:52:36 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 #168 on: August 13, 2019, 05:59:39 pm »
That's all we need to care. The game added latency is irrelevant for the measurement,

Well, to be honnest, I have a slightly different opinion. In common users' mind :
- there was no input lag on arcade/console/amiga/blablabla
- they care about "I press B, Mario jumps", and all that "Was playing better on my console" bragging

From a usual player point of view, they care about input lag, not "render lag", as it's being measured. Of course we can only be enthusiastic about oomek's results which proove the work done in groovymame is probably the best that any emulator could achieve. But still, players mostly care about "I press, Mario jumps", which implies much more than rendering a frame in time. Wish anyone luck explaining this to "commoners", so to say.

Beside lag being a never ending story, oomek's work is great and prooved that the rendering pipeline delay is neglectable compared to a frame (50 to 60 Hz), which means the rest is all about the game or driver emulation. In that meaning, I agree with you, mission accomplished. Too bad we can't compare yet against Retroarch.

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 #169 on: August 13, 2019, 06:02:21 pm »
I'm pretty sure I already asked, but I'll repeat. Does RA support LUA? I couldn't find plugins folder anywhere.

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 #170 on: August 13, 2019, 06:17:37 pm »
Does this help ?

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #171 on: August 13, 2019, 06:47:01 pm »
If you want to check internal lag of a specific game without including vsync and etc, why not just use mame's frame advance? Same method is used in retroarch.

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 #172 on: August 13, 2019, 06:49:48 pm »
That's all we need to care. The game added latency is irrelevant for the measurement,

Well, to be honnest, I have a slightly different opinion. In common users' mind :
- there was no input lag on arcade/console/amiga/blablabla
- they care about "I press B, Mario jumps", and all that "Was playing better on my console" bragging

From a usual player point of view, they care about input lag, not "render lag", as it's being measured. Of course we can only be enthusiastic about oomek's results which proove the work done in groovymame is probably the best that any emulator could achieve. But still, players mostly care about "I press, Mario jumps", which implies much more than rendering a frame in time. Wish anyone luck explaining this to "commoners", so to say.

Beside lag being a never ending story, oomek's work is great and prooved that the rendering pipeline delay is neglectable compared to a frame (50 to 60 Hz), which means the rest is all about the game or driver emulation. In that meaning, I agree with you, mission accomplished. Too bad we can't compare yet against Retroarch.
Yes for the niche of Groovy users who 'get it' : mission accomplished indeed. Or 'confirmed accomplished'.
And oomek's test will help developers in the future for dealing with any other backend lag questions and mitigation techniques.

For like over 9/10 people though...er, indeed it's very much as you say. The confusion between the various sources of delay, not understnding what adds up and how to deal with that right, it's all over the internet.

The interest of demystifying the various game driver's delay is out there, to bust the myths, bad measurements, unverified claims and overall confusion/misunderstanding that plagues the world of emulation (for which honestly mamedev didn't help at all in 20 years, and RetroArch only contributed to in bringing more chaos, confusion and bad practices)
Once that last obscure part of the total delay chain is finally brought to light, the whole lag saga will have come full circle.

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 #173 on: August 13, 2019, 07:06:14 pm »
If you want to check internal lag of a specific game without including vsync and etc, why not just use mame's frame advance? Same method is used in retroarch.
Personally; many years reading about different counts by different people with the same games over different emulators and versions, makes me say it's not a reliable-enough, final method.
With it, controversies about some games original driver delay have been going on for nearly 20 years with variations of +/-1 frame.
Maybe there's an end-way of executing it, but I have never read about confirmation of any, it would be cool if one day we'd finally know for sure, so here's why maybe an entirely different testing method is needed.
« Last Edit: August 14, 2019, 04:15:11 am by schmerzkaufen »

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 #174 on: August 13, 2019, 07:26:39 pm »
Have more faith my friend. I'm 100% commited to the subject with 3 years spent on developing the most reliable method.

Regarding LUA on RA, thanks for the link, I'll test it when the PCBs arrive, as my new PCB design has better SNR than my prototype

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 #175 on: August 14, 2019, 04:41:03 am »
Have more faith my friend. I'm 100% commited to the subject with 3 years spent on developing the most reliable method.
I have total faith.  8)

But really don't bother with a solution for measuring drivers delay if it ends up being too big of a hassle, I realize well it is facultative.


(PS: now I am thinking of that variant: button or stick + motion sensor both wired to the tester that records the time gap between action and motion of the targeted sprite: if the sensor is sensitive enough and with enough presses granularity, there wouldn't even be a need for specific LUA scripts. however for good or bad that method would include the driver + everything else's delay, not just the driver's. it is barely different from your current backend delay testing method, but it would at least eliminate the whole camera and video part)

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 #176 on: August 14, 2019, 05:08:04 am »
For checking game's internal delay Is pause, stick or button, shift+p method not reliable enough?

Then total game's delay = video chain lag from the tester + frames counted * frametime
« Last Edit: August 14, 2019, 05:11:25 am 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 #177 on: August 14, 2019, 06:38:33 am »
For checking game's internal delay Is pause, stick or button, shift+p method not reliable enough?

Well as I've posted above, that method always returned +/- 1 frame differences (sometimes more) across different builds, different emulators, and people counting (some count the exact number of presses, some substract -1 frame)

So is it really reliable ? ¯\(°_o)/¯

I've always wanted to see confrmation/validation by another method, a method that's not the camera one considering the many variables in testings there too (the tester himself and how he sets it all up returns wildly different figures)
In short: unquestionable, like your new test is for the video render part.

Again I am aware this is facultative, but a lot of science experimentation can be seen as nitpicking anyway, until one reveals something unexpected or demystifies some maybe erroneous beliefs. ;D

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 #178 on: August 14, 2019, 06:40:51 am »
I'm wondering about that random part. Couldn't it be caused by frame doubling when game is not run with synrefresh?

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 #179 on: August 14, 2019, 07:51:38 am »
or just people saying "1 press +1 frame since I' pressed on my button, makes 1 frame lag". Doh ... Mario won't jump on an already rendered frame. If the action occurs on the next frame, there's no delay

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 #180 on: August 14, 2019, 08:02:07 am »
That was my second thought, most likely the case here. So reassuming, do we really need anything else? G.I.L.T + frame counting on pause and we know everything

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 #181 on: August 14, 2019, 08:17:24 am »
G.I.L.T
guilt ?  ;D


Well, some people count then substract a frame, some count and retain all, it's always been like that.

Then differences between builds/emulators happen too.

Like this, for twenty years we could read "that game driver lags 2 frames in mame", "no 3", "no its 1", "here I count 4", "guys I get 3 in fba"... etc etc
« Last Edit: August 14, 2019, 08:21:01 am by schmerzkaufen »

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 #182 on: August 14, 2019, 09:00:03 am »
G.I.L.T stands for Game Input Lag Tester  :) feel free to interpret it however you feel like ;)

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 #183 on: August 14, 2019, 09:01:49 am »
Is it really that hard to count from 0?

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #184 on: August 14, 2019, 09:31:52 am »

It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times.  For me, lag is the difference between system under test and the original system response.  eg if your response time is 30ms and the original game was 30ms, that is zero lag.
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 ?

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 #185 on: August 14, 2019, 11:11:03 am »
Is it really that hard to count from 0?

Of course it is, especially when the internet has been singing different tunes for 20 years.

0 (paused frame) 1 2 3 (sprite moves) = 3 frames
0 (paused frame) 1 2 3 (sprite moves) = 4 frames  (counting either 0 or 4 as a frame)

For some it's even:

0 (paused frame) 1 2 3 (sprite moves) = 2 frames  (neither the paused frame nor the movement one count as in-game delay)
« Last Edit: August 14, 2019, 11:29:16 am by schmerzkaufen »

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 #186 on: August 14, 2019, 11:43:04 am »
This is retarded ;)

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #187 on: August 14, 2019, 12:13:37 pm »

I agree with schmerzkaufen that there is a variation of counting methods out there. But I agree with oomek that it doesn't have to be a problem. Just ignore the results of anyone who doesn't carefully define their method.

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 ?

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #188 on: August 14, 2019, 01:10:08 pm »
oomek, having lost my 120fps camera, and getting bored of counting video frames anyway, I'm now thinking that it would be nice to use one of your GILTs.  But I would want to modify it, will you provide the code? I'm familiar with arduino coding but I've never output to a screen.

I usually measure the shoot response time so I would stick it to the screen in front of the ship to catch the laser appearing. I'll have to alter the code to give a longer pause between button presses.

Also I would want it to either simulate a button press when attached to an arcade pcb, or to take buttons presses as inputs to start the timing.  I'm sure I can hack some wires, but a suggestion for mk2 would be a jack plug.
« Last Edit: August 14, 2019, 01:19:16 pm by jimmer »
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 ?

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 #189 on: August 14, 2019, 01:50:11 pm »
This is retarded ;)
This is reality, here we are on a forum where maybe 8/10 regular users are literate above-average in development and various technical areas related or not to emulation. But out there most people who play games with an emulator aren't engineers, programmers, or computovideo-sapiens.

I agree with schmerzkaufen that there is a variation of counting methods out there.
Only one is right, however over the many years I haven't heard the same - even coming from developers - I'm not shitting you.

I should run a blind poll for a couple of weeks across several emu/arcade communities, I bet the results would surprise some people.  ;)

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 #190 on: August 14, 2019, 03:56:30 pm »

I usually measure the shoot response time so I would stick it to the screen in front of the ship to catch the laser appearing. I'll have to alter the code to give a longer pause between button presses.

Also I would want it to either simulate a button press when attached to an arcade pcb, or to take buttons presses as inputs to start the timing.  I'm sure I can hack some wires, but a suggestion for mk2 would be a jack plug.

Adding a small header or port for button attachment is not a big deal. The only problem is how to force an arcade board to display black and white rectangle on button press

GILT is calibrating itself before taking measurements which allows to determine the screen refresh rate and sensor value threshold. I don't see any way how it could work without lua script or modified rom.
« Last Edit: August 14, 2019, 04:17:31 pm by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #191 on: August 14, 2019, 08:25:52 pm »
oomek, I would be measuring a white laser shot appearing on a black background.

I don't see a need for black and white squares for calibration:  the black level is the constant backgound, and the white level is what appears shortly after pressing fire.

Do you think it might be hard to sense the (4 LCD pixels high) laser shot ?

And I also don't see the need to know the framerate.  I guess you are using it to know how soon you can do the next sample?

The more I think about it, I don't really need the built in display so I will probably just get a sensor and do my own thing. So, errr, thanks for the inspiration :)
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 ?

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 #192 on: August 14, 2019, 08:44:36 pm »
I don't see a need for black and white squares for calibration:  the black level is the constant backgound, and the white level is what appears shortly after pressing fire.
You need calibration to determine the threshold that specifies the lowest brightness level 2x above noise floor that is used to stop the timer. DAC levels are 0-1023. LCD black is not really black, and the white can vary from monitor to monitor. Without knowing that you get skewed results when you change the display device.
Quote

Do you think it might be hard to sense the (4 LCD pixels high) laser shot ?
Let's assume 4 pixels are enough for the sensor (I don't know, havent tested it wit such small elements) without calibrating the sensor you will get wrong values or no trigger at all, or too early trigger caused by noise of the black. Also positioning the device on the screen with such small element would also affect the readings.
Quote

And I also don't see the need to know the framerate.  I guess you are using it to know how soon you can do the next sample?
I use the framerate for calculating the delay needed for decoupling usb polling rate from the display's framerate to have an even spread of button presses across the whole frame. It will be also needed to show the lag in ms and frames. ( i'm gonan add it later)
Quote

The more I think about it, I don't really need the built in display so I will probably just get a sensor and do my own thing. So, errr, thanks for the inspiration :)

Be warned, it's not that simple as it seems. Believe me, I've spent countless hours trying to get consistent and repeatable results.

If there was a way of achieving what you have in mind and what's important keeping the readings accurate I would have done it.

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 #193 on: August 14, 2019, 08:54:27 pm »
Oh an one more thing. Don't get me wrong, I'm not trying to discourage you, but warn against some roadblocks I've already solved. Without a reference voltage circuit and proper PCB shielding layer you will get a noise floor on the sensor's low end in a ADC range of about 0-50, assuming your few pixels will achieve level of 100 imagine how bad the accuracy would be. One more thing, the default 10K resistor in the premade TEMT6000 boards is way to low to even register such small brightness.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #194 on: August 14, 2019, 10:41:02 pm »

LOL, halfway through composing this message my current arduino project deleted it.

Anyway, thanks for the comments, and I'm not too discouraged. All I can do is fix the sensor to the screen and see what numbers I get out. If I can't spot the laser being fired then too bad.

I'm not looking for super accuracy, nearest ms is good enough for me.

PS. I didn't comment before but your threshold level for spotting the white square looks like it might be a bit generous to the LCD. I can see you've set is as low as you can, but is that level visible to the human eye? And I don't mean visible if you stare at your rectangle, but more like if a white object (maybe a bullet) appeared somewhere on the screen at what brightness level would it be spotted. That might not be the right question exactly (but I think the answer will be close), what is actually relevant is how long does it take a human to spot the object (for different ramp ups in brightness). Plenty of discussion to be had there I think.
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 ?

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 #195 on: August 15, 2019, 04:22:15 am »
I've already mentioned that, my results do not include a varying from brand to brand pixel response time of the monitor.

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #196 on: August 15, 2019, 05:05:10 am »
I've already mentioned that, my results do not include a varying from brand to brand pixel response time of the monitor.

I didn't mean to criticise your choice of threshold, I realise now that your choice is correct for your purpose of measuring the rendering engine or whatever we will call it.

I am always thinking in terms of overall system performance, so just pointing out to others that for system performance there is an extra bit of response time they need to add on to LCD results (but not CRT).

For completeness; there is also a human/mechanical response to add at the front of the process, eg if you have a loose joystick vs a precise joystick there is a longer response time between brain telling your muscle to move and the contacts closing.

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 ?

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 #197 on: August 15, 2019, 05:37:52 am »
This whole discussion got me thinking even before I read your recent post.

The whole purpose of building my device was to measure the performance of the rendering pipeline, but since people are interested in human percievable lag I can propose 2 modes of operation:

1. Mimimum detectable lag: as it's now measured in top left corner.
2. Percievable lag: measured in the middle of the screen that consists of average lag + pixel response time g2g

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 #198 on: August 15, 2019, 05:41:21 am »
P.s. Let's leave joysticks alone, you hear the click and that's your trigger. Human dexterity is not something that I'm interested in measuring ;)

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 #199 on: August 15, 2019, 06:38:49 am »
2. Percievable lag: measured in the middle of the screen that consists of average lag + pixel response time g2g
That one is pretty confusing to a lot of people, it's what several Tv and monitor reviews websites call 'input lag', though it's neither unwanted 'lag' nor obnoxious delay, just the normal time in the middle of the frame of which value depends on refresh and panel performance.
Sure it includes #1, but that confuses people who think for instance 'my monitor has 20ms lag at 60Hz' when in fact it's more like 12ms.

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 #200 on: August 15, 2019, 07:04:21 am »
It's easy.

1. Data reached the LCD screen matrix
2. Picture reached your eyes assuming your focal point is in the centre of the screen
« Last Edit: August 15, 2019, 07:07:41 am 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 #201 on: August 15, 2019, 07:10:16 am »
Sure, my point is just that a lot of people confuse #2 for #1 in the denomination.

EDIT: arguably they could be called;
# video delay (sync/IO/processing) or pre-frame lag, whatever
# mid-frame perceived delay, or mid-frame perceived response

It's just a thought, nevermind.
« Last Edit: August 15, 2019, 07:19:59 am by schmerzkaufen »

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 #202 on: August 15, 2019, 08:17:03 am »
Your point is 100% valid

How about making this a fridge sticker ;) ?

« Last Edit: August 15, 2019, 11:27:50 am by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #203 on: August 15, 2019, 09:33:00 am »

I like the concept.

Just for completeness I'd like to say that the ideal generalised measurement for the average would be time averaged over the input time frame (as you've been doing) and spacially averaged over the screen. Choosing the midpoint of the screen and the midframe time point for the trigger makes assumptions about the specific system.  I'm not saying they are bad assumptions.
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 ?

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 #204 on: August 15, 2019, 10:44:38 am »
That's why I take 1000 measurements and spread the input trigger evenly across the frametime to decouple the usb input rate from the refresh rate. With that I get very consistent results.

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 #205 on: August 15, 2019, 11:18:17 am »
There is still one crucial info left to pinpoint:

To make sure your video pipeline Input Lag measurements are valid you need as fast machine as possible and a display with the fastest input processing.
If you don't satisfy that criteria you take the Perceived Delay test which will be specific to your hardware setup.
« Last Edit: August 15, 2019, 11:26:56 am by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #206 on: August 15, 2019, 02:03:18 pm »
That's why I take 1000 measurements and spread the input trigger evenly across the frametime to decouple the usb input rate from the refresh rate. With that I get very consistent results.


Did you try my suggestion yet ?  you will get the same result with 50 or 100 measurements if you deliberately spread them uniformly. using random is a very inefficient way to get a uniform distribution.
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 ?

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 #207 on: August 15, 2019, 02:12:48 pm »
Yes I changed random delay to sequential and repeated set of delays with 1ms increments after each mesurement based on frametime calculated from detected framerate. I still take 1000 samples though as the hid polling rate cannot be controlled or timestamp of events detected. With just 100 samples I would get very poor temporal resolution.
« Last Edit: August 15, 2019, 02:14:44 pm by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #208 on: August 16, 2019, 08:52:55 am »
oomek, forgetting about the average response for a bit, let's look at the minimum response.

You are making life doubly hard by trying to capture a level close to the noisy floor that it also on a shallow part of the pixel response curve. You'll get better time accuracy on the steeper part of the curve eg at 100.  As you can measure the response curve it is valid to capture the time at 100 and then take off the appropriate delta to get back to the time point you are wanting to measure.

Next, you know there is a point somewhere in the frame window that is the best place to trigger the input. Your algorithm could search out that point and then dither around it for 10,20,30? samples to allow for the unknown polling timing. 




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 ?

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 #209 on: August 16, 2019, 09:10:46 am »
I know what you have in mind. I've tried that before, but since I was also displaying max and average I needed  an even spread. This now after separation of tests will possibly become redundant, but I still use the spread of values (max_lag-min_lag) to determine if there was a frameskip or doubled frames. If spread is > than frame_time + 1ms usb polling time I discard the test. I need to reimplement that method and see how it affects the spread. If I'll be balancing on an edge of 2 frames I should be still getting a decent spread. What you think?

Regarding setting bigger threshold. This does not make much sense to me, I offset the threshold but for what purpse? To subtract the unknown delta later? Each lcd has different pixel response time, letting alone crt. I'm not sure how you see a bigger threshold making any difference in capturing a closer min_lag. It all depends when you trigger the usb event, not how you capture the sensor data.

Update: i'm not really ballancing on a noise threshold, I've never had false positives if I set the threahold 3x the noise max value. But I'm going to add a fixed value on tuesday when the pcb's arrive. I've hopefully improved the snr significantly with a reference voltage circuit and that will make ie noise floor 0-8 becoming 0-2 or even 0-1, in that case multiilying the max nf value does not make sense anymore. I'll even try to increase the value again of the voltage divider on the sensor to get the black noisefloor never reaching 0 as I'll be clipping some data.
« Last Edit: August 16, 2019, 09:25:20 am by oomek »

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #210 on: August 16, 2019, 11:07:00 am »
Regarding setting bigger threshold. This does not make much sense to me, I offset the threshold but for what purpse? To subtract the unknown delta later? Each lcd has different pixel response time, letting alone crt. I'm not sure how you see a bigger threshold making any difference in capturing a closer min_lag. It all depends when you trigger the usb event, not how you capture the sensor data.

I was thinking that generally it's more accurate to capture a time on a steeper part of the response curve. It's hard to explain but I was imagining error bars on the sensor reading and then looking at the implied time spread that results. I could be wrong on that, or maybe it's not relevant for this sensor at this sampling rate.

And regarding the whole picture it's the polling end of the chain that is the troublesome area for accuracy.
 
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 ?

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #211 on: August 16, 2019, 11:37:10 am »
I know what you have in mind. I've tried that before, but since I was also displaying max and average I needed  an even spread. This now after separation of tests will possibly become redundant, but I still use the spread of values (max_lag-min_lag) to determine if there was a frameskip or doubled frames. If spread is > than frame_time + 1ms usb polling time I discard the test. I need to reimplement that method and see how it affects the spread. If I'll be balancing on an edge of 2 frames I should be still getting a decent spread. What you think?

I was going to ask: For your interest in the rendering pipeline, do you need anything apart from the minimum response time?

But I won't !  What you are measuring and why is probably different to what I want to do and why, so I'll stop bothering you :) and get on with my own projects.
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 ?

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 #212 on: August 16, 2019, 12:58:46 pm »
Regarding setting bigger threshold. This does not make much sense to me, I offset the threshold but for what purpse? To subtract the unknown delta later? Each lcd has different pixel response time, letting alone crt. I'm not sure how you see a bigger threshold making any difference in capturing a closer min_lag. It all depends when you trigger the usb event, not how you capture the sensor data.

I was thinking that generally it's more accurate to capture a time on a steeper part of the response curve. It's hard to explain but I was imagining error bars on the sensor reading and then looking at the implied time spread that results. I could be wrong on that, or maybe it's not relevant for this sensor at this sampling rate.

And regarding the whole picture it's the polling end of the chain that is the troublesome area for accuracy.

I'm interested in absolute minimum, so any added offset to the threshold will increase the latency.

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 #213 on: August 16, 2019, 01:01:59 pm »
I was going to ask: For your interest in the rendering pipeline, do you need anything apart from the minimum response time?

Now when I think of it, I will not, just I need to know the spread to detect fps variations.

Quote
But I won't !  What you are measuring and why is probably different to what I want to do and why, so I'll stop bothering you :) and get on with my own projects.

I'm pretty sure we're after the same values but we describe it in different words :P
« Last Edit: August 17, 2019, 03:46:57 am 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 #214 on: August 16, 2019, 06:39:12 pm »
oomek, having lost my 120fps camera, and getting bored of counting video frames anyway, I'm now thinking that it would be nice to use one of your GILTs.  But I would want to modify it, will you provide the code? I'm familiar with arduino coding but I've never output to a screen.

I usually measure the shoot response time so I would stick it to the screen in front of the ship to catch the laser appearing. I'll have to alter the code to give a longer pause between button presses.

Also I would want it to either simulate a button press when attached to an arcade pcb, or to take buttons presses as inputs to start the timing.  I'm sure I can hack some wires, but a suggestion for mk2 would be a jack plug.

I would like to come back to your desired way of measurement. I'm pretty sure you're aware that your results will significantly vary depending on what part of the screen you are putting the sensor on.

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 #215 on: August 19, 2019, 01:11:51 pm »
It's alive!



Just waiting now for cnc router to drill holes in the enclosure.

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #216 on: August 20, 2019, 12:39:47 am »
I'm very interested in your device. Are you going to take orders?

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 #217 on: August 20, 2019, 04:12:09 am »
I'm very interested in your device. Are you going to take orders?

Yes, you can pm me.

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 #218 on: August 20, 2019, 05:50:40 am »
No time yet to try lua in the mame libretro core ?

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 #219 on: August 20, 2019, 05:54:18 am »
I'll try to test my lua script today on RA

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 #220 on: August 20, 2019, 05:57:42 am »
By the way, is that still a thing ? http://www.bountysource.com/issues/53180296-1-frame-of-input-lag-in-the-ra-core

And can it affect oomek's test ?

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 #221 on: August 20, 2019, 06:22:01 am »
Here is a repo where all the supplementary software for G.I.L.T. will be stored. There is my LUA plugin inside if you want to take a look.
Tomorrow I'll upload my standalone display input lag test- yes just for displays and it showed that my LG 29UM67 has an internal lag of 1.99ms, Leo Bodnar was off by 0.8ms

https://github.com/oomek/GILT


By the way, is that still a thing ? http://www.bountysource.com/issues/53180296-1-frame-of-input-lag-in-the-ra-core

And can it affect oomek's test ?

Can't say until tests are made. To be sure I can compare the LUA results with modded rom.
« Last Edit: August 20, 2019, 06:25:09 am 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 #222 on: August 20, 2019, 06:34:02 am »
My standalone test will show the following things:
  • Display's Input Lag ( vsync off, pixel brightness threshold < 1%  ) measured top left corner of the screen
  • Pixel Response Time ( G2G ) with graph
  • Perceived Delay ( average ) = Display's Input Lag + Pixel Response Time + average polling delay of the controller + display scan delay measured in the middle of the screen (vsync + doublebuffering or freesync/gsync) pixel brightness threshold = 50%
« Last Edit: August 21, 2019, 12:43:43 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 #223 on: August 23, 2019, 07:43:40 am »
Hi, finally back in front of a keyboard, it looks like I've missed the party here.

It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times.  For me, lag is the difference between system under test and the original system response.  eg if your response time is 30ms and the original game was 30ms, that is zero lag.

That's exactly it.


I'd like to quote schmerzkaufen from other thread, since it'll help me illustrate something I wanted to clarify:

Garegga has about 3 frames of natural lag iirc, but that one you can't touch, Groovy can only eliminate the additional lag that's running on top.

i.e

MAME (official) BGFX -> bgaregga 3fr + vsync 5fr = 8 frames
MAME (official) d3d -> bgaregga 3fr + vsync 3fr = 6 frames

Groovy BGFX -> bgaregga 3fr + vsync 3fr = 6 frames
Groovy d3d9ex (default) -> bgaregga 3fr + vsync 2fr = 5 frames
Groovy d3d9ex w/ frame_delay 1 -> bgaregga 3fr + vsync 1fr = 4 frames
Groovy d3d9ex w/ frame_delay 5 -> bgaregga 3fr + vsync 0.5fr = 3.5 frames
Groovy d3d9ex w/ frame_delay 9 -> bgaregga 3fr + vsync 1.6ms = 3 frames + 1.6 miliseconds (1/10th of a frame)

I think it's important to clarify, so we can properly interpret oomek's results in the future.

When schmerzkaufen says fd 9 equals to 1/10th of a frame of lag, it's true but *only* if you consider the average value. In my opinion we shouldn't use average values, or only use them with care, because it leads to confusions.

Actually, fd 9 means that for 9 out of 10 button presses (90%), the lag is zero (matches original hardware, as jimmer says).

It's only for 1 out of 10 button presses (10%), that the lag is 1 frame, since the button press is not catched on time.

If you average the result, then it's when you get that 1/10th of a frame of lag, but that would lead to thinking that there's some lag associated to each button press while this is absolutely false. I.e. even for fd 7, most of the interaction matches the experience with original hardware.

And even so, this would be in a worst case scenario, where the pcb would poll the switches during vblank. On the other hand, if the pcb would read input let's say in the middle of the frame, then fd 5 would be enough to match the pcb responsiveness, this means zero lag.

Unfortunately we don't know where each pcb polled input, so assuming the worst case scenario is the best we can do. We'd need to test GM against a real pcb to know the actual lag (lag, again, by jimmer's sense), but it should be equal or less than the one considered by using this method.

In the same way, the value that oomek provides, e.g. 4.08 ms for fd 9, is telling us the latest button press that GM can catch.
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

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 #224 on: August 23, 2019, 09:51:35 am »

It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times.  For me, lag is the difference between system under test and the original system response.  eg if your response time is 30ms and the original game was 30ms, that is zero lag.

I think this is the goal.

I remember getting my first lcd, trying to play super mario on my snes, and just kept falling in the pits. It made me so upset.

This test could tell me how close my emulated system is to when I was a child playing these games.

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 #225 on: August 23, 2019, 10:08:26 am »

It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times.  For me, lag is the difference between system under test and the original system response.  eg if your response time is 30ms and the original game was 30ms, that is zero lag.

I agree and disagree. Every part of the chain has inputs and outputs:
game controller, pc(video pipeline), display controller lcd matrix so it's ok to call the sum as input lag. Pixel response time is an output so we should not add this to the input lag. Otherwise you are adding the input lag of your eyes and brain, or the device used for the measurement if the assumed threshold is for example 50%

Lets leave the comparison to the emulated hardware alone as it causes even more confusion by adding another interpretation to this term. Input lag is not soleley associated with emulation.


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 #226 on: August 23, 2019, 11:00:14 am »
@Calamity: thanks, I added something like "that doesn't mean 9 is the best setting" but there was no way I could explain that like you do. ^^

Personally since I've been using frame_delay I've had that feeling in my fingers that overall in many games I get the best response when I'm past 5.
For the games I play often and with my CPU I can't use 8 much and 9 is out of the question so I have no experience with those levels.
So currently 6~7 is my "half objective/half placebo" sweet spot that seems to work well.

Any chance devs who developed drivers could share some input there ? (no pun intended) or is that a technical information they are generally not aware of ?

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 #227 on: August 23, 2019, 11:23:18 am »
Any chance devs who developed drivers could share some input there ? (no pun intended) or is that a technical information they are generally not aware of ?

I guess even the devs don't know in most cases. They built the emulated hardware environment but it's actually the emulated code which will actually read the switches on its own. So you'd really have to study each game's code.

That's without even considering that most drivers' emulation is actually simplified, meaning that it may be accurate at frame level but not at sub-frame level, but this is another matter.
« Last Edit: August 23, 2019, 11:37:06 am 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 of pasting it.

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

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 #228 on: August 23, 2019, 11:36:33 am »
Lets leave the comparison to the emulated hardware alone as it causes even more confusion by adding another interpretation to this term. Input lag is not soleley associated with emulation.

From my overly biased point of view, the traditional source of confusion has been precisely the incorrect application of categories that belong to the general video game industry to the emulation area.

But yes, I get your point.

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

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: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #229 on: August 23, 2019, 12:52:19 pm »
I guess even the devs don't know in most cases. They built the emulated hardware environment but it's actually the emulated code which will actually read the switches on its own. So you'd really have to study each game's code.

So true.  Defender has an interrupt routine that is called 4 times a frame. The ROM code decides what to do each time based on some flags and where the scanline is.  I discovered that I'd been given a semi-bum steer by Mr Jarvis: The gameplay inputs are only analysed once a frame. Non-gameplay inputs are analysed at a different time (ie the code does do input polling twice a frame, but not the gameplay controls).
 
I was a bit slow at ordering a TEM6000 sensor, but with luck one will arrive tomorrow. Hopefully then I'll be able to get accurate response times and that will help me answer a lot of the questions I still have.

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 ?

dilarconon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 10
  • Last login:April 02, 2020, 03:27:34 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #230 on: September 06, 2019, 01:53:13 am »
Great test! Thank you so much for doing this.

So you get better result having Freesync on and have frame_delay 0?
What if you have Freesync on with "frame_delay 9"?

robbo43

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 20
  • Last login:April 04, 2021, 09:25:51 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #231 on: January 30, 2020, 08:40:39 pm »
Hi,

Did you get arounf to lag testing GroovyArcade?

Regards

Rob

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 #232 on: January 30, 2020, 08:45:35 pm »
Give a shout to keilmillerjr. He's the one who has GA setup and my device.

Zebra

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 619
  • Last login:August 19, 2021, 01:12:24 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #233 on: February 08, 2020, 02:06:42 pm »
Have you tried using the device to see if there is a difference in lag between older games and later more demanding titles?

I'm not usually bothered by lag as I game on a CRT and generally believe that a 10ms or 20ms difference is not perceivable. It's been bothering me on Area 51 recently though. I'm curious if the lag is inherent in the game or related to the quality of emulation or my PC specs.

It would also be interesting and probably more meaningful to compare groovymame with a game at native refresh VS the original PCB. That's the result that matters.

It seems like it would be really hard to compare lag on a direct view crt which updates one line at a time VS an HD flat screen updating a whole frame at a time.

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 #234 on: February 08, 2020, 02:30:17 pm »
G.I.L.T. Requires consistent framerate to do a measurement. Any frame dips will add up to the lag 16.6ms for 30fps average game's framerate.

The lag of 10-20 ms is perceivable when you're used to gaming on a 5ms setup and it will surely reflect on your scores.

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 #235 on: August 17, 2020, 12:03:27 pm »
So, upping this to re-ask a question; has anyone with a GILT tested Groovy's triplebuffer VS. baseline's ?

Default d3d9ex is faster than baseline when on syncrefresh, we already know that, but what about when autosync switches to triplebuffer?
Supposedly Groovy's is more like a double buffer or something, it woud be nice if that could be confirmed some day.

Also @ oomek an updated chart on the opening post would be nice, if hopefully you visit again. Thanks. ^^
(mostly to confirm the new figures from baseline since calamity introduced the 'low latency' option)

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 #236 on: August 17, 2020, 02:58:22 pm »
Hi, I'm a bit overflowed atm to do the tests. I'm finishing a new batch of G.I.L.T.s so if you're interested drop me a line to contact@gameinputlagtester.com

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 #237 on: August 19, 2020, 03:49:54 am »
Just did, I wasn't aware you had put up a website and taking orders already, despite the somewhat difficult times (some makers still have trouble with very overdue parts and components)
Also nevermind my second email I didn't realize this shipped from the UK.

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 #238 on: August 26, 2020, 10:51:21 am »
I have received the GILT thank you for the promptitude oomek!

I couldn't get anything to work yet though.  :lol

- I wasn't expecting to need a long Mini-USB cable, those are actually obsolete and became kind of a rare sight these days so I sort of struggled, but managed to borrow one.

- First thing I tried is to lag test my display, I set the size and aspect, but the GILT keeps asking me to place it on a "green rectangle" which is nowhere to be seen, I see only four white squares at the corners.
- I've tried placing it on the topleft white square then but get an error #4.

- Tried the LUA plugin, which I have activated via the mame.ini because for some reason the plugin.ini disappears after first boot of a fresh MAME install, anyway the UI plugin menu for the GILT shows. EDIT: then the plugin.ini is automatically re-generated. How bizarre. Nevermind.
- However the moment I turn the test ON in the UI, it crashes Groovy pretty hard (freeze, black screen, difficult to stop mame process)
- Tried doing it with displays properties on default then proper, same result.

- I thought maybe I needed to update the firmware first ? but pressing the back button with a paperclip only triggers a very brief USB disconnect of the device, and clicking the update.bat does nothing, on the command line console that pops up I can only read 'press a key to continue' but nothing happens.
« Last Edit: August 26, 2020, 11:04:46 am by schmerzkaufen »

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 #239 on: August 27, 2020, 05:57:51 am »
Hi, I did not get any notification of your post ( typical on this forum ), anyway, please try the following.

1. Connect GILT using a short cable
2. Open the Display Lag Test app
3. Set your displays parameters using the arrow keys: size in inches and the aspect ratio
4. Press the space bar
5. Press 0 on the numerical keyboard, Is the green rectangle visible?
6. Press 1 on the numerical keyboard, The green rectangle should disappear
7. Press the GILT button. Is the green rectangle visible?
8. Disconnect Gilt and use a long cable.
9. Press 1 on the numerical keyboard, The green rectangle should disappear
10. Go back to point nr 7.

Tell me on which point you're stuck please

Firmware is up to date v1.1 You can see the number by holding the GILT button while connecting it to the USB
« Last Edit: August 27, 2020, 06:16:21 am 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 #240 on: August 27, 2020, 06:38:45 am »
4. Press the space bar
5. Press 0 on the numerical keyboard, Is the green rectangle visible?
6. Press 1 on the numerical keyboard, The green rectangle should disappear
I wasn't aware of these key commands! ;D there are no such instructions on the leaflet nor the readme.

Quote
7. Press the GILT button. Is the green rectangle visible?
8. Disconnect Gilt and use a long cable.
9. Press 1 on the numerical keyboard, The green rectangle should disappear
10. Go back to point nr 7.
Okay that worked.

But then I've proceeded on doing the input lag test, and after it finds that it is a 60Hz LCD, I press to resume for the next step which I guess is the lag test proper, but after like 1 second I get error #3
I did it a few times, still #3 and once I got a #6
The display lag, and perceived lag tests give me mainly #6

My monitor is DC (not PWM) if that matters. Level around 255, noise 2~3.
W7 on desktop 60H, nothing special.
« Last Edit: August 27, 2020, 06:50:07 am by schmerzkaufen »

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 #241 on: August 27, 2020, 06:59:23 am »
The numpad buttons are not doccumented since it's how GILT is communicating with the software. It will be later replaced with the Raw HID commands.
The requirement of pressing a SPACE bar is displayed on the screen. Maybe I will scrap that and listen to GILT straight away if it's confusing.

Would you please provide a screenshots of the errors, do you see any numbers on the GILT's screen?
It will help me to narrow down the cause of the errors.

You can launch `GILT.exe -debug`to see a moving bar, when you press space and hold 6 on the numpad it should animate smoothly a green bar without stuttering.
When you press 7 and then hold 6 again you should see the same bar drawn very fast with tearing.




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 #242 on: August 27, 2020, 07:12:36 am »
Thanks for your tests btw, we're still in the beta phase and if you've hit some corner case your input will help to narrow it down.
« Last Edit: August 27, 2020, 09:10:02 am 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 #243 on: August 27, 2020, 10:05:46 am »
Doesn't seem to work any better if I try more times anyway.

Well you can thank me but of nothing because honestly, I wasn't aware I was signing for beta testing when I ordered. I ordered one even though I'm broke at the moment because I wanted to know about just two measurements but you said you were busy, so I didn't want to disturb you, and anyway I've long been waiting to see more emulators lag tests results compared, since the GILT has been a thing in fact.
Because there have been so little measurement results published even by you or Calamity even though you both have the devices, several case scenarios (like triplebuffer is only one of them I asked here long ago but didn't get attention) are still unmeasured, I thought if I can have a unit now I'll do the long awaited missing tests emulators lag myself, also update the current old, and finally share as much results as possible with the general public.

Anyway, I'll do what you ask but taking photos would be a chore right now so I'll write what I see:

input lag
ERROR #3
scur: 172
lmin: 167   lmax: 168
st: 172   sto: 170

display lag
ERROR #3
scur: 174
lmin: 167   lmax: 170
st: 174   sto: 172

perceived lag
ERROR #6
uneven framerate
frame time 25.84ms

The values fluctuate slightly with every try.

Quote
You can launch `GILT.exe -debug`
How exactly? if you expect me to use command line you'll have to explain step by step what need to do, since I am extremely uncomfortable with that.
EDIT: guess I plug the GILT, then bring up a console, then what to I enter (full input) ?
my console on w7 starts this way:
C:\Windows\System32>
do I have to enter the path of the gilt.exe location ? (guess it's yes)

Quote
The requirement of pressing a SPACE bar is displayed on the screen
I think I didn't notice it because I had to put put my monitor on the floor since my 'long' mini-usb cable is still rather short, and I'm working in an uncomfortable position.
Suggestion: if possible give up on Mini-USB, it is obsolete, the rare cables left around people are old (mine is), having to get one when you receive delivery of the GILT is an unpleasing surprise.
If I wanted a newer and longer Mini-USB cable now, or if I hadn't found one to borrow, I'd need to spend like 10€ on amazon and wait like a week or two if not more (many ship from HK !).
If you can't do without Mini-USB bc of the pcb design, then I'd suggest provide a long one in the box in place of the (very) short. You could maybe have them in bulk and that'd increase the individual GILT package sell price by only like 2~3 bucks and save the customer both money and trouble. Anyway it's only a suggestion.

Is there anything else I should try ? the GM/MAME ingame lag test is what I am interested in, but I get only crashes there so I guess it's a no-no ? Or ?...
« Last Edit: August 27, 2020, 11:30:32 am by schmerzkaufen »

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 #244 on: August 27, 2020, 10:12:47 am »
What is your GPU?
« Last Edit: August 27, 2020, 10:15:13 am 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 #245 on: August 27, 2020, 10:14:13 am »
Currently RX Vega 56 (rest is in my sig, only the GPU changed, and CPU is not OC'd at the moment)

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 #246 on: August 27, 2020, 10:14:50 am »
To open GILT in the debug mode just right click on the blank space in the folder where you have gilt.exe and choose Command Prompt.
then just type `gilt -debug` and press enter

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 #247 on: August 27, 2020, 10:20:57 am »
To open GILT in the debug mode just right click on the blank space in the folder where you have gilt.exe and choose Command Prompt.
then just type `gilt -debug` and press enter
Sorry my OS doesn't have that option on right click menu...

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 #248 on: August 27, 2020, 10:24:57 am »
Then copy the full path and type `cd ` in the cmd prompt and paste the path and then press enter, alternatively you can create a shortcut to gilt.exe and then in the properties in the shortcut tab add ` -debug` in target field, don't forget about the space. If you see quotemarks add it after.

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 #249 on: August 27, 2020, 10:40:42 am »
I suspect that the pixel response time of your monitor is the cause here, more precisely the fall time when it goes from white to black. All monitors I've tested so far were ok with those values, but let's see if it works for you. I've adjusted the timeout and testing it now.  I'll let you know when it's ready to download.

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 #250 on: August 27, 2020, 10:49:40 am »
For now I still couldn't get the debug thing to work, neither method works.
I don't know how to input command lines properly, I do it once a year or two at worst when I have no other choice and every time it is hell.
I hate this to death and will never get used to it, sorry.

For Groovy logs I have .bat that someone here gave me, I always use that without any issues, maybe if you write down one for me that would do.


The monitor; well it's not a high-end panel in a gaming monitor, but its is faster than than the average TV's IPS or VA for sure, and responses are certainly more homogenous than the latter's. Overdrive is always on the lowest setting if that matters.

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 #251 on: August 27, 2020, 10:50:03 am »
Regarding the cable, I'm still behind financially, all the tooling and parts costed me quite a bit, so I'm shaving the costs. Besides everyone has a different need of the lenght, so it was safer to leave the decission to the user. I could send you an usb extension cable, but it would cost x2 more for shipping. The extension cables on ebay cost £1.5 - £2.5 depending on the length.

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 #252 on: August 27, 2020, 10:51:40 am »
Overdrive needs to be off for GILT to work properly. It's a software trick that is definitely gonna confuse the sensor.

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 #253 on: August 27, 2020, 11:14:12 am »
No, no don't send me a cable lol!  ;D  It was just as a general recommendation.
lenght uder 1m shoul'nt be significantly diffent in price, actually sometimes the smaller ones are priced higher since they're more rare.
Anyway.


Overdrive: with overdrive OFF the GILT seems to get a few more seconds being able to do its measuring job on every test, but with all three tests I end up getting an ERROR #6 now.

It's a problem if you can't measure with overdrive ON, since most monitors these days are in use with constant overdrive, everyone has it on all the time, it's considered the norm since manufacturers balance the best performance with it on. Some TVs also force a bit of RTC and you can't turn that off, unlike monitors.
« Last Edit: August 27, 2020, 11:28:20 am by schmerzkaufen »

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #254 on: August 30, 2020, 10:53:42 pm »
This device looks absolutely incredible!  I've just sent an e-mail to see if I can purchase one (oomek?) since I'd love to see how much latency is in my setup.

I'm also a bit of a latency guy since I own a Leo Bodnar and also just assembled a Time Sleuth which works great.  However, I've also wondered the actual button-to-screen latency on my MAME setup (GroovyMAME + CRT Emudriver).

I've even started converting my MAME cabinet to MiSTer (FPGA console) but even though it's extremely impressive, it obviously doesn't support that many systems. (compared to MAME)

Anyways, I'd definitely be interesting in buying/assembling/testing one of these devices if they are available!

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 #255 on: August 31, 2020, 01:32:43 am »
Well, it's not controller button, you know some lag can still creep in there on the way before the input registers in the emu.

And regarding the 'perceived' test counting pixel response time is subjective for LCDs since it's really uneven territory, tftcentral cut the pixel response part in half because they say it's unfair to count it whole using the slowest black/white time (plus if we really have to shut overdrive off then we're definitely not seeing measurment for the display at its best)

You can't isolate and measure the emulated game's internal lag either, the GILT tests your display and everything besides the core emulation, if you want everything, the entire chain from controller to the moving sprite onscreen, you still need to perform a camera-type test.
(then, combined with the GILT you can finally deduce the core's)

Still, this is the deepest one of these handy lag testers has ever gone, the 3 different tests are the most relevant to us, and it aims at higher accuracy overall.
Price is also the best. So there's no contest.

Note though that it's still in beta, I wasn't aware of that and mine actually doesn't work with my setup. Oomek is looking into it and I'm waiting for his green light to try something new.

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 #256 on: August 31, 2020, 03:52:40 am »
I think you should take a look at the graph again. If you want to measure a pure software lag you just subtract your measured Display Lag from Input Lag.
http://www.gameinputlagtester.com/wp-content/uploads/2019/11/chart.png

The new firmware should be ready today.

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 #257 on: August 31, 2020, 04:21:57 am »
Ah? I stuck to what you were saying, that your device can only measure the API for output and input polling performances.
http://forum.arcadecontrols.com/index.php/topic,160722.msg1692248.html#msg1692248

If 'driver overhead' is the same thing I'm talking about (purely the game itself as emulated by the driver, without the input and video API on top) then it doesn't appear to me that it is measured entirely separately there.
I mean what I'm seeing in the graph even if we substract the display lag part is: draw + input polling + frame queue + driver overhead, so it's still a sum.

I guess on a VRR display we can eliminate the queue+polling portions as potential lag generators, and therefore get extremely close to the driver-level truth, or maybe exactly (?), and if not on VRR setup using frame_delay instead; somewhat close assuming ideal performance/setting, but the gap between the two situations is very small anyway.

The new firmware should be ready today.
Nice
« Last Edit: August 31, 2020, 04:23:58 am by schmerzkaufen »

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 #258 on: August 31, 2020, 05:02:40 am »
The driver overhead is the time spent waiting in SwapBuffers() function with vsync off. Gilt app sends that time back the device and compensates when Display Lag is measured. This is a very small value < 0.2- 0.5ms
Input polling is the time between the input sampling by the game and actually updating the next frame. Gilt does not measure any additionalinternal game's lag that is added by the rom. It measures the capabilities of the emulator and api used, bgfx, opengl, directx.

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 #259 on: August 31, 2020, 05:43:40 am »
Gilt does not measure any additionalinternal game's lag that is added by the rom. It measures the capabilities of the emulator and api used, bgfx, opengl, directx.
So yes that's what I thought and what I mean, GILT can't measure the game's internal 'natural' lag from the emulator (which is the same as the pcb's, a.k.a pcb-level lag, assuming mamedev's code is accurate enough)
For that we do need a camera test, the only way to measure the full chain, then compare with GILT.

PS: with a camera test (done right) and comparison vs. GILT results, the only possible things remaining in the way that could add lag would be a laggy controller pcb or something from the OS then, I assume.
« Last Edit: August 31, 2020, 05:57:31 am by schmerzkaufen »

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 #260 on: August 31, 2020, 05:50:17 am »
You do not need a camera to measure the lag added by the ROM itself. It's counted in full frames and can be measured by pressing P, holding some game related button and continue pressing shift+P until you see a change on the screen. Why would you want to test it anyway? Original hardware has it as well, and it's game specific, some has it some don't. I do not know the ratio.

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 #261 on: August 31, 2020, 06:49:19 am »
My mailserver is down again.

Would you please update the firmware to v1.1.1 and test with GILT.exe
If that works we will focus on the issue you're having with the LUA script.

https://github.com/oomek/GILT/releases/tag/v1.1.1

Could you please open an issue on Github for further discussion so we do not clutter this thread anymore?
Now everything is mixed here and it's difficult to keep track of separate issues.
« Last Edit: August 31, 2020, 07:09:22 am 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 #262 on: August 31, 2020, 08:25:30 am »
I'd rather use PM here. Anyway testing the new firmware will have to wait tonight or tomorrow, no time right now gotta go.

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 #263 on: August 31, 2020, 08:34:29 am »
The notification system on this forum is broken beyond repair. I often get a notification of the PM after a week. Why you're hesitant from using Github Issue tracker?

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #264 on: August 31, 2020, 02:16:57 pm »
oomek, I received your response to my e-mail this morning about purchasing a GILT, but when I try to send you another e-mail I'm seeing an error:

Code: [Select]
550 Verification failed for <redacted@gmail.com> Sender verify failed  (redacted to hide my e-mail address)

Is your e-mail server OK or is Gmail acting funny?

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 #265 on: August 31, 2020, 02:24:03 pm »
My email server is broken, need to change it. I'm sending you an email from my private account.

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #266 on: August 31, 2020, 02:29:36 pm »
No problem.  I received the e-mail from your private address and responded.

Thanks again!

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 #267 on: September 01, 2020, 12:44:41 am »
The notification system on this forum is broken beyond repair. I often get a notification of the PM after a week. Why you're hesitant from using Github Issue tracker?
It always worked fine for me. Still does.

I have successfully updated the firmware and tried it on my setup, and now laptop too. I got varied results, which I should write down and share, but...

Listen, I'd like to keep on cooperating, but before I do everything you want your way, remember I first came asking ONE question, the same like 3~4 times including email, that you have deliberately (no doubt now) all ignored like I never wrote a word of it.

So I repeat; can you please test the lag in triplebuffer mode in Groovy vs. baseline's and report ?
I have been very curious about it for long and was asked several times by other users I was helping actually, it matters to more of them than you might think.
If the GILT is working on your setup it should take you only a few minutes.

I told you I don't understand why you and Calamity have apparently both a GILT working with your setups, yet haven't updated the results nor shared any further measurements after the initial ones.
Why make such great things, lit a enthusiasm fire with a number of users...then go silent for months to years on?

So I am not happy that you refuse to talk about it, not a single word, when at the same time I have this uncomfortable feeling that you have deliberately omitted to show more to people and in place lured them to purchase a GILT and work as beta testers.

Quote
the issue you're having
The issue I am having ? the LUA plugin crahes on my laptop too just FYI, don't turn the meaning like the issue is only on my side with my sole setup and you'd be gracing me with support.
I think you have a problem, which is the GILT being far from ready to work globally on a safe-enough majority of displays, and your plan is to get people to pay for the device and then work for you testing and reporting.
That could be acceptable within certain limits, like if you tell them that clearly before they buy (wasn't my case), but don't you find a bit too convenient in my situation to, on top of it all, cherry pick what questions you answer or ignore, and tell me how and where to exchange ?

I can be really nice and go to great lenghts to help people that are frank, direct and honest, with me.
But some developers think we owe them everything unconditionally -with zero criticism nor requests- till the day we die, it's a rather widespread mentality in particular in the FOSS world, where people on the dev side think they got a sacred right to constantly rewrite ethics to their exclusive advantage.
Calamity took the wrong turn in attitude with me some day deciding to basically 'dump' me and very unfairly misjudge why I was even here, not actually joking he suggested I was using him - he evidently forgot about reality - the reality that I also spent insane amounts of time and money on his project, despite being a simple end-user trying my best because I have (had?) so much like and faith in his project. Of course contributing at my level isn't in the same league as what weighs on the shoulders of a developer, but still it's not just hours nor just a few bucks, it's much, MUCH more. And then from there, because I voiced my criticism and discontent, I was basically treated like crap by the rest of the BYOAC regulars.

SO here's the deal man, answer my questions, you'll make me happy, and I'll keep testing the GILT I paid, test as much as you require, on various setups and displays if you require, so you can keep on developing it and reduce the risk of it clashing with other potential 'unexpected behaviour displays'.
And ok I'll move to github too.

Seriously, MAMEdevs & Co. from the FOSS-values-clad crowd ever wonder why their relationship with end-users is deader than rotten fish and why everyone goes to RetroArch/Pie, mini consoles, FPGA etc ? or why crowdfunded projects get all the attention ?
I've seen cops and taxes workers have warmer and fairer attitude towards people, than emu devs and the other fosslike towards end-users.
Just comparing the communities activity tells it all period.
« Last Edit: September 01, 2020, 01:25:50 am by schmerzkaufen »

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 #268 on: September 01, 2020, 06:11:37 am »
Hey schmerzkaufen,

Testing triplebuffer on GÏLT is tricky because GILT measurements require perfect vsync while triplebuffer is asynchronous by design (it drops frames when required due to screen's vs game's refresh mismatch). GILT will notice this and fail with "uneven frame rate" error. The fact that GILT won't complete its measurement doesn't mean you can't get some valid lag figures from the time it keeps running, that will provide a valid estimate. For best results, I'd suggest using a game that runs at exact 60 Hz, such as 1942, and force -triplebuffer on it, either from command line or via mame.ini, by disabling -autosync and forcing -triplebuffer instead. The reason to use a 60 Hz game is it'll hopefully give you more time before a frame is dropped and GILT stops.


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 #269 on: September 01, 2020, 09:54:21 am »
The GILT instantly crashes Groovy when I try the LUA plugin (in normal autosync conditions, no matter if it's a 60.00 game or not) so I can't try what you say yet.

If you guys could try the method you describe on your own systems and tell what measurements you find, it would be the end of mystery of the triplebuffer lag time that was never confirmed. I've asked both you and oomek over a long time, I couldn't ask anyone else and it's the first time I get a word of reply in place of being totally ignored, so thank you, but I'm stuck...

EDIT: Ok, that's enough of this madness.
@oomek, I'm sending back the device.

EDIT: @oomek. Justsent the return tracking info in PM since your email doesn't work.
« Last Edit: September 02, 2020, 05:50:40 am by schmerzkaufen »

R-Typer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 143
  • Last login:Yesterday at 08:10:27 pm
  • C64 Rulez!!!!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #270 on: September 02, 2020, 09:24:11 am »
this is sad. we will never know the lag measurements now. they seem as if they are top secret stuff  :(

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 #271 on: September 06, 2020, 08:08:06 pm »
As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely. I'm sorry that doing tests for you is not on top of my list. Regarding the tests, I'm not sure why you need the triplebuffer, if your display supports VRR just use it. The only time GM may start tearing in VRR is when your desktop's refresh rate is lower than the game's resolution. Just make sure your monitor's RR is above 60 and that's it. You say you need tests just with triplebuffer, but that's not enough, there are more switches that can affect the lag, so you need as many combinations of commandline switches as possible to get a full picture (Yes I know you are illiterate in that matter, but GM overrides some ini settings, so you need to learn how to use commandline args whether you like it, or not)

As Calamity said GILT requires that game runs with syncrefresh, VRR, or in native RR of the monitor, otherwise the lag spread will become longer then the frametime, which in turn makes the tests meaningless with any device, or camera. You just need to make sure GM is not dropping/doubling frames (the integrated moving bar toggle in the LUA script serves that purpose)

@calamity The new firmware does not stop the test when frame drops are detected, it displays the information on the screen and continues the test. When you update the firmware make sure you also up to date with the software/script included in the zip file.
« Last Edit: September 06, 2020, 08:13:29 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 #272 on: September 07, 2020, 01:08:18 am »
Ok this is not right so I have no choice but to respond.
@Calamity: I'm not taking defamation without defending myself.

As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely.
You know I'm aware, you sent me a pic from the hospital after all, I told you to take all your time resting instead of taking care of the GILT issue. It would be petty of you to pretend I don't know or didn't care to make me look bad. You wouldn't do that, right ?

I'm sorry that doing tests for you is not on top of my list.
I've never asked for tons of measurements, just asked only for one, or two measurements exactly, since I'm curious how it compares to baseline. It should have take about 5~10 minutes in total.
I couldn't have guessed there were issues with what I asked since you kept being silent about it.
And anyway I accepted to purchase a GILT so you wouldn't have to be disturbed.
Remember that part ?
Or do you really want to make me look like I wanted to exploit your time without a care like an egoist ? and forget like I've paid for your device specically so I would measure myself ? (but you omitted to tell me I couldn't) did I protest or complain ? no I just paid and gladly.

The amount of lag in triplebuffer mode should be a more or less fixed amount of frames, supposedly inferior in GM vs. baseline, that's what Calamity said, but it was never confirmed.
Your test confirmed how a previous statement about the default lag with d3d9ex was wrong (frame_delay off), I was of course curious to know about the other statement about when it's switched to triplebuffer and finally learn the end of it.

Regarding the tests, I'm not sure why you need the triplebuffer, if your display supports VRR just use it.
- I don't use GM only on my primary setup, I also use it on other computers/displays that don't support VRR or Emudriver.
- Knowing how much triplebuffer lags matters in cases we don't/can't use syncrefresh and frame_delay.
- I was asked that question several times by other users, I'm not the only one curious, and many users don't have a setup fit for Emudriver/VRR anyway.
- I've told you all that already including in private, why pretend I didn't?
Anyway this is a 100% legitimate question coming from GM users, it's a whole part of it after all.
Pretending it doesn't matter is like when ppl here were pretending flat panels use doesn't matter so why bother? but this is what most people use, like it or not the world goes beyond the scarcely populated walls of BYAOC, and Calamity made Groovy competent for these displays, the best at it in fact, so it's useless after all he worked on to act like one aspect somehow doesn't exist/matter. It unfortunately still does until everyone on Earth is equipped with a gsync/freesync display (or finds a somewhat rare monitor like mine), which is still far away in the future.

The only time GM may start tearing in VRR is when your desktop's refresh rate is lower than the game's resolution. Just make sure your monitor's RR is above 60 and that's it. You say you need tests just with triplebuffer, but that's not enough, there are more switches that can affect the lag, so you need as many combinations of commandline switches as possible to get a full picture (Yes I know you are illiterate in that matter, but GM overrides some ini settings, so you need to learn how to use commandline args whether you like it, or not)

As Calamity said GILT requires that game runs with syncrefresh, VRR, or in native RR of the monitor, otherwise the lag spread will become longer then the frametime, which in turn makes the tests meaningless with any device, or camera. You just need to make sure GM is not dropping/doubling frames (the integrated moving bar toggle in the LUA script serves that purpose)
There was no tearing at all when I tried, even with frame_delay off and syncrefresh, the LUA plugin would crash immediately in all cases even with exactly 60.00Hz games, if it was still seeing uneven refresh under these conditions then the problem was elsewhere.
I bet this is related to this monitor being driven by Emudriver, which is a rather unique thing since AFAIK I'm the only one doing this (more people could but compatible monitor's aren't too common and ppl don't even imagine something like that is possible.
Maybe you could have found out if I'd kept reporting the errors to you, Id'have battled command line despite my illiteracy until it'd worked, but you weren't cool with me at all, so I've quit and anyway can't do anything anymore since I've sent back the device already, I gave you a tracking number.

It was simple, before telling me to buy a GILT you could simply have not ignored my question -repeatedly- and simply said this couldn't be measured by it or not without roundabout ways, and that it was still in beta and you needed testers anyway.
ONE sentence.
I would have accepted these conditions, in fact I accepted them afterwards anyway, and I would have done a ton of testing for you, but you still refused to talk about what I asked and started to have demands, which is why I stopped being friendly.

What I can't gut is that on top of having been dishonest, and seeing your post is a narrative to cover that and put all the blame on me, you had the nerve to complain to Calamity who threatened me of a ban.
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.

@Calamity; before you attempt to censor this post, someone made a narrative that's very unfair, even defaming to me so I'm responding on the same ground with nothing but the truth.
If you want to censor that and kick me out now, well that's between you and your conscience. I'd advise you wait until I got the refund at the very least, so I can confirm we're through.

You guys should know there is a simpler other way to get out of this cleanly, it's just a few words, but I'm betting it's more comfortable to nuke me, right?

Asking people to show honesty these days is too much, people systematically complain about people like me who refuse to act like a phony. I don't care if I'm disliked, but still, I don't let anyone dirty my purpose, intentions, words and actions, oomek's been completely unfair here, and that's wording it kindly, so it's my right to respond.
Come clean and I'll even edit/erase my posts in this thread if you want, and if you edit yours too, end of drama.

@calamity The new firmware does not stop the test when frame drops are detected, it displays the information on the screen and continues the test. When you update the firmware make sure you also up to date with the software/script included in the zip file.
In regards to the triplebuffer lag, whatever, if you guys don't ever share your finds I guess I can just hope someone with a GILT some day will let the cat out of the bag, or I'll finally get a good-enough camera and find out. *shrug*

It's just extremely sad that developers are SO BAD at dealing and communicating normally with average user people, that they give people no choice but to either give up, or wrestle them in the mud to the bitter end...when a simple few words sentence of honest reply at the beginning would have done it and avoided all the drama.
« Last Edit: September 07, 2020, 02:27:14 am by schmerzkaufen »

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 #273 on: September 07, 2020, 07:46:45 am »
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.

Indeed, I'm a poor sinner, whatever you blame me is probably well deserved.

Anyway, it wasn't Oomek who reported you.

On the other hand, I am to blame for not warning Oomek about the risks of interacting with you, but it all happened while I was on vacation.

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 #274 on: September 07, 2020, 09:14:11 am »
I think I'm gonna take my website down and continue building Gilts just for friends, I'm not planning to put up a big scale production. I've designed it for myself then I started to see an interest, so I wanted to share it with others. It's clearly unfinished for the general public as I am able to only test it on the devices I own. Besides I don't have the energy to deal with random people's demands, especially when someone starts blaming me for something I did not do.

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #275 on: September 07, 2020, 09:55:21 am »
Has Calimity ever censored any post or banned any member? 'Cause if he hasn't, I can see some very unfair, defaming narrative being developed here.

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 #276 on: September 07, 2020, 10:20:53 am »
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.
I am to blame for not warning Oomek about the risks of interacting with you, but it all happened while I was on vacation.
Who warns about the near-impossibility for petty users of interacting normally with you guys? *shrug*
Would you interact better with people who are too low level if you had logs of them?
People who complain about me here have no idea anyway, surely none of them really read through anything, they're just discontent bc they see negativity so they assume: bad guy, wrong, does not fit, we want him out.
This makes a fine warning for whoever as a simple end-user like me, gets too enthusiast for a developer's projects and ends up involving himself too much, not casually but with his time and money, just take care; as devs they only want to interact with you if your topic happens to have some interest for their current project at a given point, but neither personal opinions nor criticisms, or one too much question are welcome no matter how rationally or kindly you try to pass them at first, and definitely not if you end up losing your cool and shout them, goes without saying.
If you do that, be ready for ostracism, you're forever the bad ungrateful oddball and everyone wants you out. Unfair? nobody will hear you, you're not a dev, not even a respectable high profile member of the community, not a power-user bc your skills lacking; you talk to the hand.
Say, what are you waiting for Calamity, just ban me, problem solved, tell yourself it's debugging!
I don't use time doing fellow flat-panel user support anymore, and with your latest feature update hardly anyone using such displays will need any serious help (main problem was vsync_offset, you solved it), and I said I don't report my findings anymore (issues, performance-bench, remarks, oddities, whatever) I've stopped doing that some time in '19 so I'm not useful at all for anything anymore, it's practically full circle at this point.
Congrats on the achievement by the way, even if I've grabbed that you aim for even higher than that, and how incongruous the moment is to say bravo! lol.  ;D

@oomek; sorry I wasn't convenient. bad casting. like I said; warn people in advance the next time or at the very least pay attention what they're asking you about if you want to avoid misunderstandings, and meeting bad angry - legitimately in my particular case but who cares eh? - inflexible dudes like me. Good luck with your project, trust it is sincere words or don't; but I know it's really good.

@Recap: no indeed he hasn't, but this time he did warn me, although as I've detailed in lenghts I said I find that rich. So he could very well kick my butt out, maybe he will have his first kill as a mod.
Oh come one do it or not I don't care, it's not like anyone's taking me seriously, you're just annoyed. *shrug*
A fact that will please you is that I really don't have anything much more to exchange about on the topic, I mean the whole topic of GroovyMAME.
The few remaining minor questions and requests I had, (lag measurements, OC slider modification, some tutorials addendums maybe) I've already wrote them here and there. Anything else beyond that is really too much out of Groovy's territory, I think, so I will annoy other people elsewhere. ELSEWHERE! Celebrate!  8)
« Last Edit: September 07, 2020, 10:30:38 am by schmerzkaufen »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Today at 07:43:35 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #277 on: September 07, 2020, 03:11:15 pm »
Has Calimity ever censored any post or banned any member? 'Cause if he hasn't, I can see some very unfair, defaming narrative being developed here.

He never has, afaik.

Although some matters should not be taken into public places and should remain in their own private conversations.

@oomek: just a little word of advice.
When you put out a product people will think you're a big company like Amazon and start pretending the same service.
If you really want to make the GILT a commercial product, "hire" someone to deal with your customers and stay the hell away from them or they're going to drive you insane.
I'm not referring to schmerzkaufen, just a word of wisdom from someone who's seen it happen over and over again.

The "build on request" and only to friends and/or people you know well about is a very wise choice.
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

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #278 on: September 07, 2020, 04:43:38 pm »
I'm aware. Just tried to make him understand that seeing this:

As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely. I'm sorry that doing tests for you is not on top of my list.

...as "defamation" or a "very unfair narrative" is beyond any possible rationale, especially when you can then see that he's doing exactly that with Calamity, which wouldn't place him too well in this silly dramma. It's not material for this thread anyway, I agree (and I'm sure he agrees as well).


« Last Edit: September 07, 2020, 04:45:11 pm by Recapnation »

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 #279 on: September 07, 2020, 09:44:37 pm »
I was able to pinpoint the situation when the LUA script could cause an exception. This was only happening when the game was launched with an internal game selector. I was unaware that some people still use it. Anyway, it was just a matter of rearranging a few lines in the start_init() function. Fix pushed to github.
« Last Edit: September 07, 2020, 09:50:59 pm by oomek »

Josh128

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 28
  • Last login:January 09, 2021, 11:32:25 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #280 on: September 21, 2020, 08:16:00 am »
Guys, curious as to why the higher frame delay setting in GroovyMAME actually reduces lag according to the OPs tests?  Shouldnt increasing frame delay add lag?  Im obviously ignorant about something, please educate me.

*EDIT - Did some digging and understand now.  So I guess the question is, is frame delay the only option in GM to reduce input lag?  Any other tips / tricks that might help?  Ive read certain versions of Direct3D 9 such as Direct3D9 Ex have certain lag reducing features enabled by default or something?  Any clues?
« Last Edit: September 21, 2020, 10:25:36 am by Josh128 »

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 #281 on: September 23, 2020, 08:05:56 am »
Groovy has been using D3D9EX for years as its default backend. You don't even have to write anything under 'video' in the mame.ini
Calamity attempted a switch to BGFX but it turned out still too laggy, so back to 9EX until further developments.

And there's no need for other lag reduction features when frame_delay's efficiency is tested and proven, with it we can drop delay down to pcb-level or close.
(in most games with few exceptions, and depending how good is your PC, of course)

edit: it could be replaced by a different method in the future, like the obscure frame_slice. who knows about the likeliness tho? not me.

If you seek to reduce even the game's built-in natural delay (breaking emulation accuracy and gameplay legitimacy though) see with RetroArch and its often nonsensitical mishmash of backends and features that include the lossy Run-Ahead.
« Last Edit: September 23, 2020, 08:26:37 am by schmerzkaufen »

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:March 22, 2024, 06:30:47 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #282 on: April 17, 2022, 07:33:39 am »
I've set up a primative DIY input lag tester:

Crt
Led light tapped to the crt glass linked to super gun button 1
1000fps camera and manually count the frames.
(Oh how I wish the GILT was for sale...)


Hooked up final fight 1 pcb and measured
Hooked up cps2 xmen vs street fighter pcb and measured
Hooked up umk3 pcb and measured.

Then tested the same games on a pc running mane and groovymame to the super gun using jpac

I get no difference with groovymame vs normal mame. Frame delay does nothing for me?

Can anybody help with the mame.ini settings test see the best possible input lag for groovymame?

There is no definitive documentation on this and lots of incorrect information.