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 64015 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 »