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

0 Members and 1 Guest are viewing this topic.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #200 on: August 15, 2019, 07:04:21 am »
It's easy.

1. Data reached the LCD screen matrix
2. Picture reached your eyes assuming your focal point is in the centre of the screen
« Last Edit: August 15, 2019, 07:07:41 am by oomek »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:September 15, 2019, 05:12:03 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #202 on: August 15, 2019, 08:17:03 am »
Your point is 100% valid

How about making this a fridge sticker ;) ?

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 541
  • Last login:Today at 05:50:26 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #204 on: August 15, 2019, 10:44:38 am »
That's why I take 1000 measurements and spread the input trigger evenly across the frametime to decouple the usb input rate from the refresh rate. With that I get very consistent results.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #205 on: August 15, 2019, 11:18:17 am »
There is still one crucial info left to pinpoint:

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 541
  • Last login:Today at 05:50:26 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #207 on: August 15, 2019, 02:12:48 pm »
Yes I changed random delay to sequential and repeated set of delays with 1ms increments after each mesurement based on frametime calculated from detected framerate. I still take 1000 samples though as the hid polling rate cannot be controlled or timestamp of events detected. With just 100 samples I would get very poor temporal resolution.
« Last Edit: August 15, 2019, 02:14:44 pm by oomek »

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 541
  • Last login:Today at 05:50:26 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #209 on: August 16, 2019, 09:10:46 am »
I know what you have in mind. I've tried that before, but since I was also displaying max and average I needed  an even spread. This now after separation of tests will possibly become redundant, but I still use the spread of values (max_lag-min_lag) to determine if there was a frameskip or doubled frames. If spread is > than frame_time + 1ms usb polling time I discard the test. I need to reimplement that method and see how it affects the spread. If I'll be balancing on an edge of 2 frames I should be still getting a decent spread. What you think?

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

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 541
  • Last login:Today at 05:50:26 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: 541
  • Last login:Today at 05:50:26 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #212 on: August 16, 2019, 12:58:46 pm »
Regarding setting bigger threshold. This does not make much sense to me, I offset the threshold but for what purpse? To subtract the unknown delta later? Each lcd has different pixel response time, letting alone crt. I'm not sure how you see a bigger threshold making any difference in capturing a closer min_lag. It all depends when you trigger the usb event, not how you capture the sensor data.

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

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

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #213 on: August 16, 2019, 01:01:59 pm »
I was going to ask: For your interest in the rendering pipeline, do you need anything apart from the minimum response time?

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

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

I'm pretty sure we're after the same values but we describe it in different words :P
« Last Edit: August 17, 2019, 03:46:57 am by oomek »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #214 on: August 16, 2019, 06:39:12 pm »
oomek, having lost my 120fps camera, and getting bored of counting video frames anyway, I'm now thinking that it would be nice to use one of your GILTs.  But I would want to modify it, will you provide the code? I'm familiar with arduino coding but I've never output to a screen.

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

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

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #215 on: August 19, 2019, 01:11:51 pm »
It's alive!



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

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 128
  • Last login:Yesterday at 02:40:02 am
  • 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #217 on: August 20, 2019, 04:12:09 am »
I'm very interested in your device. Are you going to take orders?

Yes, you can pm me.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
  • Last login:Today at 08:44:07 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #219 on: August 20, 2019, 05:54:18 am »
I'll try to test my lua script today on RA

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:September 15, 2019, 05:12:03 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: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #221 on: August 20, 2019, 06:22:01 am »
Here is a repo where all the supplementary software for G.I.L.T. will be stored. There is my LUA plugin inside if you want to take a look.
Tomorrow I'll upload my standalone display input lag test- yes just for displays and it showed that my LG 29UM67 has an internal lag of 1.99ms, Leo Bodnar was off by 0.8ms

https://github.com/oomek/GILT


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

And can it affect oomek's test ?

Can't say until tests are made. To be sure I can compare the LUA results with modded rom.
« Last Edit: August 20, 2019, 06:25:09 am by oomek »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #222 on: August 20, 2019, 06:34:02 am »
My standalone test will show the following things:
  • Display's Input Lag ( vsync off, pixel brightness threshold < 1%  ) measured top left corner of the screen
  • Pixel Response Time ( G2G ) with graph
  • Perceived Delay ( average ) = Display's Input Lag + Pixel Response Time + average polling delay of the controller + display scan delay measured in the middle of the screen (vsync + doublebuffering or freesync/gsync) pixel brightness threshold = 50%
« Last Edit: August 21, 2019, 12:43:43 pm by oomek »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 02:06:03 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #223 on: August 23, 2019, 07:43:40 am »
Hi, finally back in front of a keyboard, it looks like I've missed the party here.

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

That's exactly it.


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

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

i.e

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

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

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

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

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

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

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

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

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

In the same way, the value that oomek provides, e.g. 4.08 ms for fd 9, is telling us the latest button press that GM can catch.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1709
  • Last login:Yesterday at 05:59:12 pm
  • Web Developer.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #224 on: August 23, 2019, 09:51:35 am »

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

I think this is the goal.

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

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 236
  • Last login:September 16, 2019, 06:48:44 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #225 on: August 23, 2019, 10:08:26 am »

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

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

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


schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 517
  • Last login:September 15, 2019, 05:12:03 am
  • I want a large cream coffee
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #226 on: August 23, 2019, 11:00:14 am »
@Calamity: thanks, I added something like "that doesn't mean 9 is the best setting" but there was no way I could explain that like you do. ^^

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

Any chance devs who developed drivers could share some input there ? (no pun intended) or is that a technical information they are generally not aware of ?
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: 6723
  • Last login:Today at 02:06:03 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #227 on: August 23, 2019, 11:23:18 am »
Any chance devs who developed drivers could share some input there ? (no pun intended) or is that a technical information they are generally not aware of ?

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

That's without even considering that most drivers' emulation is actually simplified, meaning that it may be accurate at frame level but not at sub-frame level, but this is another matter.
« Last Edit: August 23, 2019, 11:37:06 am by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6723
  • Last login:Today at 02:06:03 am
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #228 on: August 23, 2019, 11:36:33 am »
Lets leave the comparison to the emulated hardware alone as it causes even more confusion by adding another interpretation to this term. Input lag is not soleley associated with emulation.

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

But yes, I get your point.

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

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

jimmer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 541
  • Last login:Today at 05:50:26 am
  • I want to play Defender like at the arcade.
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #229 on: August 23, 2019, 12:52:19 pm »
I guess even the devs don't know in most cases. They built the emulated hardware environment but it's actually the emulated code which will actually read the switches on its own. So you'd really have to study each game's code.

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

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

dilarconon

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 9
  • Last login:September 14, 2019, 05:29:00 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #230 on: September 06, 2019, 01:53:13 am »
Great test! Thank you so much for doing this.

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