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

0 Members and 1 Guest are viewing this topic.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #160 on: August 13, 2019, 10:49:50 am »
That's correct. My device is measuring the rendering backend.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #161 on: August 13, 2019, 10:55:55 am »
First batch (30 PCBs) is in production. I'll be taking orders in about a week.

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



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

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

I'm not advertising it anywhere outside this forum and AttractMode discord channel. So you guys have a chance to test it and send your thoughts ;)
« Last Edit: August 13, 2019, 11:06:18 am by oomek »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #163 on: August 13, 2019, 11:08:43 am »
The square is overlayed on top of the frame that is currently scheduled to be displayed, so it's accurate

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

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 148
  • Last login:Today at 05:31:22 pm
  • 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: 6737
  • Last login:Today at 09:21:12 am
  • Quote me with care
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #165 on: August 13, 2019, 04:48:19 pm »
Just for those skeptical, oomek's method is correct. Lua gets input just at the same time the emulated system does, and it uses the same video pipeline with its potential undesired buffering, etc. That's all we need to care. The game added latency is irrelevant for the measurement, indeed it's been an obstacle in the past, that's why we always looked for the few games known to be next frame responsive in order to perform the tests. By the way, high speed camera tests with a wired led are whatever you want except controversial. They're a pain in the ass to perform, but the results are unquestionable.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #167 on: August 13, 2019, 05:50:38 pm »
Another great advantage of having a database of absolute minimum lags for certain driver/video pipeline is that you know what the latency should be, and if it isn't you can start looking for devices in the chain that add to the lag ie display's processing, laggy input device, buffered video converters, you name it.
« Last Edit: August 13, 2019, 05:52:36 pm by oomek »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 148
  • Last login:Today at 05:31:22 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #169 on: August 13, 2019, 06:02:21 pm »
I'm pretty sure I already asked, but I'll repeat. Does RA support LUA? I couldn't find plugins folder anywhere.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 148
  • Last login:Today at 05:31:22 pm
  • 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: 137
  • Last login:Today at 05:44:38 am
  • 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: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #174 on: August 13, 2019, 07:26:39 pm »
Have more faith my friend. I'm 100% commited to the subject with 3 years spent on developing the most reliable method.

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

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #176 on: August 14, 2019, 05:08:04 am »
For checking game's internal delay Is pause, stick or button, shift+p method not reliable enough?

Then total game's delay = video chain lag from the tester + frames counted * frametime
« Last Edit: August 14, 2019, 05:11:25 am by oomek »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #178 on: August 14, 2019, 06:40:51 am »
I'm wondering about that random part. Couldn't it be caused by frame doubling when game is not run with synrefresh?

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 148
  • Last login:Today at 05:31:22 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #180 on: August 14, 2019, 08:02:07 am »
That was my second thought, most likely the case here. So reassuming, do we really need anything else? G.I.L.T + frame counting on pause and we know everything

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #182 on: August 14, 2019, 09:00:03 am »
G.I.L.T stands for Game Input Lag Tester  :) feel free to interpret it however you feel like ;)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #183 on: August 14, 2019, 09:01:49 am »
Is it really that hard to count from 0?

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #184 on: August 14, 2019, 09:31:52 am »

It's a shame that everything is called lag (input lag, display lag), much better if we talked about response times.  For me, lag is the difference between system under test and the original system response.  eg if your response time is 30ms and the original game was 30ms, that is zero lag.
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #186 on: August 14, 2019, 11:43:04 am »
This is retarded ;)

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #187 on: August 14, 2019, 12:13:37 pm »

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

On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #188 on: August 14, 2019, 01:10:08 pm »
oomek, having lost my 120fps camera, and getting bored of counting video frames anyway, I'm now thinking that it would be nice to use one of your GILTs.  But I would want to modify it, will you provide the code? I'm familiar with arduino coding but I've never output to a screen.

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

Also I would want it to either simulate a button press when attached to an arcade pcb, or to take buttons presses as inputs to start the timing.  I'm sure I can hack some wires, but a suggestion for mk2 would be a jack plug.
« Last Edit: August 14, 2019, 01:19:16 pm by jimmer »
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #190 on: August 14, 2019, 03:56:30 pm »

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

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

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

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #191 on: August 14, 2019, 08:25:52 pm »
oomek, I would be measuring a white laser shot appearing on a black background.

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

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

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

The more I think about it, I don't really need the built in display so I will probably just get a sensor and do my own thing. So, errr, thanks for the inspiration :)
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #192 on: August 14, 2019, 08:44:36 pm »
I don't see a need for black and white squares for calibration:  the black level is the constant backgound, and the white level is what appears shortly after pressing fire.
You need calibration to determine the threshold that specifies the lowest brightness level 2x above noise floor that is used to stop the timer. DAC levels are 0-1023. LCD black is not really black, and the white can vary from monitor to monitor. Without knowing that you get skewed results when you change the display device.
Quote

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

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

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

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

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #193 on: August 14, 2019, 08:54:27 pm »
Oh an one more thing. Don't get me wrong, I'm not trying to discourage you, but warn against some roadblocks I've already solved. Without a reference voltage circuit and proper PCB shielding layer you will get a noise floor on the sensor's low end in a ADC range of about 0-50, assuming your few pixels will achieve level of 100 imagine how bad the accuracy would be. One more thing, the default 10K resistor in the premade TEMT6000 boards is way to low to even register such small brightness.

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #194 on: August 14, 2019, 10:41:02 pm »

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

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

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

PS. I didn't comment before but your threshold level for spotting the white square looks like it might be a bit generous to the LCD. I can see you've set is as low as you can, but is that level visible to the human eye? And I don't mean visible if you stare at your rectangle, but more like if a white object (maybe a bullet) appeared somewhere on the screen at what brightness level would it be spotted. That might not be the right question exactly (but I think the answer will be close), what is actually relevant is how long does it take a human to spot the object (for different ramp ups in brightness). Plenty of discussion to be had there I think.
On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #195 on: August 15, 2019, 04:22:15 am »
I've already mentioned that, my results do not include a varying from brand to brand pixel response time of the monitor.

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 542
  • Last login:Today at 05:41:27 pm
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #196 on: August 15, 2019, 05:05:10 am »
I've already mentioned that, my results do not include a varying from brand to brand pixel response time of the monitor.

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

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

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

On forums jimmer speaks for himself as a Defender fan, not as proprietor of www.jbgaming.co.uk  << Is that advertising or disclosure ? or both ?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #197 on: August 15, 2019, 05:37:52 am »
This whole discussion got me thinking even before I read your recent post.

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

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:October 16, 2019, 06:16:48 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #198 on: August 15, 2019, 05:41:21 am »
P.s. Let's leave joysticks alone, you hear the click and that's your trigger. Human dexterity is not something that I'm interested in measuring ;)

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 540
  • Last login:Yesterday at 12:50:40 pm
  • 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