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

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

  

Author Topic: GroovyMAME - Input Lag tests 2019 (new method)  (Read 5298 times)

0 Members and 1 Guest are viewing this topic.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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. ^^
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 ?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 1689
  • Last login:Today at 08:14:57 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 418
  • Last login:Yesterday at 07:23:17 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 418
  • Last login:Yesterday at 07:23:17 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: 418
  • Last login:Yesterday at 07:23:17 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 418
  • Last login:Yesterday at 07:23:17 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 ?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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!
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 539
  • Last login:Today at 05:17:42 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 741
  • Last login:Today at 07:15:28 pm
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 30
  • Last login:Today at 02:01:14 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 ?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 741
  • Last login:Today at 07:15:28 pm
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 18
  • Last login:July 25, 2019, 11:52:59 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 741
  • Last login:Today at 07:15:28 pm
  • 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: 124
  • Last login:Today at 04:14:21 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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...
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 124
  • Last login:Today at 04:14:21 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 124
  • Last login:Today at 04:14:21 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 30
  • Last login:Today at 02:01:14 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 185
  • Last login:Yesterday at 12:22:01 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: 30
  • Last login:Today at 02:01:14 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: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #80 on: July 26, 2019, 07:30:08 am »
So how can we get freesync to not stress our monitors to death when going out of sync?

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

Calamity

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

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

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

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

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

MAME:

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

GM:

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

Baseline MAME introduces a delay after the frame is emulated and before it's rendered, this moves away these 2 steps unnecesarily.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 124
  • Last login:Today at 04:14:21 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: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #83 on: July 26, 2019, 07:51:12 am »

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

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

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

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

MAME:

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

GM:

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

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

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

oomek

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

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 30
  • Last login:Today at 02:01:14 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: 6690
  • Last login:Yesterday at 08:00:16 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #86 on: July 26, 2019, 08:05:20 am »
With d3d9ex there's supposedly only one frame left on top of the game's, but by oomek's first posted test it looks like this is true in this case only if frame_delay is on (at minimum 1).

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

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

(While this is the best you can get with D3D9ex I believe newer APIs like Vulkan can optimize the frame queue even more.)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

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

schmerzkaufen

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

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

MrMikeZH

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

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

schmerzkaufen

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

MrMikeZH

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

Ok lets go rational now,

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





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



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

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 185
  • Last login:Yesterday at 12:22:01 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: 124
  • Last login:Today at 04:14:21 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: 6690
  • Last login:Yesterday at 08:00:16 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #95 on: July 26, 2019, 11:51:24 am »
I'm preparing now to redo the tests with the latest AMD driver and their Anti-Lag feature. I'm very curious about the results. FYI, it only works with DX11 though and in DX9 when you have a Navi card.

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


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

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

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #96 on: July 26, 2019, 12:17:41 pm »
FREESYNC ON, -notriplebuffer -nowaitvsync -throttle -nosyncrefresh -r 2560x1080@75



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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #97 on: July 26, 2019, 12:26:21 pm »
 :applaud:

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

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

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

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

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

Now I'd like to build baseline with this patch only and with and without the reordered main loop, to see if it makes a difference.
« Last Edit: July 26, 2019, 12:33:25 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

schmerzkaufen

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

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

oomek

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

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

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

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

Calamity

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

Ups, you're right...  it's BGFX+Freesync OFF what's relevant here, sorry.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

Calamity

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

That's 4 frames, but I guess the one that's removed is due to AMD's Anti-Lag rather than this patch.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #102 on: July 26, 2019, 01:08:53 pm »
No, the anti-lag needs to be explicitly enabled in the radeon overlay for the specific executable. So it was off

Calamity

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

Then it was the patch. But I wonder why it can't get even close to D3D9ex, when basically we're doing the same thing. And it's clearly the buffering since with Freesync BGFX doesn't lag more than D3D9ex.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

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

Calamity

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

Sure, you're right, it's the DWM, BFGX doesn't run in fullscreen exclusive mode.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #106 on: July 26, 2019, 01:37:18 pm »
Your device is a godsend, it's been so tedious to make these tests before.



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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #107 on: July 26, 2019, 01:40:22 pm »
 :notworthy: :notworthy: :notworthy:
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #108 on: July 26, 2019, 02:05:54 pm »
Enclosure, Teensy 2.0, TEMT6000 ordered, This particular OLED display I used is out of stock unfortunately, there are other very simillar, but I won't make a risk the possible dimension differences. I'll be keeping an eye on the stock.

Calamity

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

Thank you so much, this is the coolest device I can imagine.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

Substring

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

oomek

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

Arroyo

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

Arroyo

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

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

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

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


Calamity

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

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

Thanks! So that sounds quite simple, you just need to call DwmFlush() after Present?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #117 on: July 26, 2019, 04:55:20 pm »
Yes, you swap buffers with vsync off and then just call dwmflush() and it waits for vsync, but keep in mind that it depends what kind of borderless window bgfx opens. Some flags treat window as exclusive fullscreen and windows' fullscreen optimizations kick in. I've had a lot of issues with that until I got it right.

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

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

Calamity

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

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

It'd be interesting to see if it finally matches D3D9ex.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

schmerzkaufen

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

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 (?)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 1689
  • Last login:Today at 08:14:57 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: 741
  • Last login:Today at 07:15:28 pm
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 1639
  • Last login:Yesterday at 11:18:39 am
    • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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


GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 6690
  • Last login:Yesterday at 08:00:16 pm
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 or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 124
  • Last login:Today at 04:14:21 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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.  ;)
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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.
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 539
  • Last login:Today at 05:17:42 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 124
  • Last login:Today at 04:14:21 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: 234
  • Last login:Today at 04:58:41 am
  • 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: 112
  • Last login:Today at 10:10:06 am
  • I want to build my own arcade controls!
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: 234
  • Last login:Today at 04:58:41 am
  • 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: 503
  • Last login:Yesterday at 09:02:04 am
  • I want a large cream coffee
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 ?
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 234
  • Last login:Today at 04:58:41 am
  • 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: 234
  • Last login:Today at 04:58:41 am
  • 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: Yesterday at 12:43:43 pm by oomek »