I measured some input lag on original PCBs

[Buffi]

I have a lot of PCBs and was bored, so here's some input lag measurements: http://inputlag.buffis.com/
Will put more stuff here as I have time

I describe the method + what I mean by "frames of lag" on that page. There's also raw data for all games, incl 240fps video with several inputs triggered if you want to double check yourself.

Some random takeaways:
- Cave games on everything but PGM is 2 frames, PGM and PGM2 games are 1 frame
- Early Psikyo Games (68k hardware) have two more frames of latency than later games (SH2 hardware)
- Batrider surprisingly has 4 frames of lag (on S1). Garegga seems to have 3 frames of lag for me on S1, but according to MOF this will vary between 3 and 4 on CPU usage.

[PC Engine Fan X!]

So there's two frames of lag on the Cave Hitachi SH-3 powered pcbs including DDP-DFK, DDP-DFK BL & SDOJ? If so, that's new news to me.

Is the Psikyo Gunbird 2 pcb SH-2 based to begin with?

PC Engine Fan X! ^_~

[Buffi]

So there's two frames of lag on the Cave Hitachi SH-3 powered pcbs including DDP-DFK, DDP-DFK BL & SDOJ? If so, that's new news to me.

Is the Psikyo Gunbird 2 pcb SH-2 based to begin with?

PC Engine Fan X! ^_~

Yes the SH3 Cave games are 2 frames of lag.
Gunbird 2 is SH-2 yes.

[Tatsuya79]

That's a lot for atomiswave, I didn't think it was that bad on real hardware.

[Buffi]

That's a lot for atomiswave, I didn't think it was that bad on real hardware.

I can check some other games as well. I have most AW carts, excluding driving and lightgun games.

[XtraSmiley]

That's a lot for atomiswave, I didn't think it was that bad on real hardware.

I can check some other games as well. I have most AW carts, excluding driving and lightgun games.

How and to what are your AW games hooked up? I wonder if the lag is different depending on the resolution?

[RobHimself]

This is fantastic work. Thanks for doing it and sharing. Very interesting about the Raizing titles.

Curious if you could do measurements on Garegga Rev 2016 PS4 with latency reduction turned on. That there's weird synchronization behavior with monitor refresh and PCB according to that tweet, I wonder if that explains how Garegga on PS4 seems to have some consistent choppiness you notice the backgrounds don't smoothly transition at certain time intervals. This doesn't exist when playing on MAME.

[Bassa-Bassa]

Guilty Gear X 1.5 for an Atomiswave game feeling less laggy than Dolphin Blue.

[Sumez]

To abstract away these factors, I will use the following constant definition of “Frames of input lag". For further reading, also see the site inputlag.science, which uses a similar standard.

Input lag = Count of frames of inaction between an "input frame" and a visible "output frame"
This means that if an input is triggered during a frame, and immediately visible the frame after it, there will be an input lag of 0 frames. Click measurements below for details.

Finally someone using a sensible metric!

Time sleuth be damned

Mushihimesama: 2 frames (Likely the same for other Cave CV1000 games)

So the rumors of PCB Futari being laggy is possibly a dud based on poor testing? (it sure doesn't feel it to me, but I'm also pretty sure I wouldn't notice 4 frames of lag. 5 would be pushing it)

[Lethe]

To abstract away these factors, I will use the following constant definition of “Frames of input lag". For further reading, also see the site inputlag.science, which uses a similar standard.

Input lag = Count of frames of inaction between an "input frame" and a visible "output frame"
This means that if an input is triggered during a frame, and immediately visible the frame after it, there will be an input lag of 0 frames. Click measurements below for details.

Finally someone using a sensible metric!

16ms wait on 60hz game = "zero frames"
8ms wait on 120hz game = also "zero frames" or "half of zero frames"
Yup, perfectly sensible.

[Sumez]

If a game logically cannot possibly display the result of an input faster than the time it takes to display the frame, what is the purpose of labeling that delay as "lag"?

Or more precisely, if you say a game has two additional frames of lag because you had an unfortunate input timing, and your ingame avatar is in the way bottom of the screen, that says absolutely nothing about how the game in question works, it's just noise that serves no purpose in a comparison.

None of the games tested measure a "zero", but if they did, you'd be able to get a delay super close to 0ms.
In practice that would be a massive waste of cpu power however.

[Buffi]

Mushihimesama: 2 frames (Likely the same for other Cave CV1000 games)

So the rumors of PCB Futari being laggy is possibly a dud based on poor testing? (it sure doesn't feel it to me, but I'm also pretty sure I wouldn't notice 4 frames of lag. 5 would be pushing it)

I have never heard that rumor, and doubt that a lot.
If not talking of slowdown input latency of course. When theres slowdown, there will be more.

That's a lot for atomiswave, I didn't think it was that bad on real hardware.

I can check some other games as well. I have most AW carts, excluding driving and lightgun games.

How and to what are your AW games hooked up? I wonder if the lag is different depending on the resolution?

15khz mode over Jamma, see pic: http://img.buffis.com/aw.jpg

This is fantastic work. Thanks for doing it and sharing. Very interesting about the Raizing titles.

Curious if you could do measurements on Garegga Rev 2016 PS4 with latency reduction turned on. That there's weird synchronization behavior with monitor refresh and PCB according to that tweet, I wonder if that explains how Garegga on PS4 seems to have some consistent choppiness you notice the backgrounds don't smoothly transition at certain time intervals. This doesn't exist when playing on MAME.

Sorry, dont think I'll do measurements on ports.

Guilty Gear X 1.5 for an Atomiswave game feeling less laggy than Dolphin Blue.

I can measure that later this week. I have that cart too actually!

To abstract away these factors, I will use the following constant definition of “Frames of input lag". For further reading, also see the site inputlag.science, which uses a similar standard.

Input lag = Count of frames of inaction between an "input frame" and a visible "output frame"
This means that if an input is triggered during a frame, and immediately visible the frame after it, there will be an input lag of 0 frames. Click measurements below for details.

Finally someone using a sensible metric!

16ms wait on 60hz game = "zero frames"
8ms wait on 120hz game = also "zero frames" or "half of zero frames"
Yup, perfectly sensible.

It should be pretty clear that this is only refering to input latency for analog video arcade games. This means 120hz is not relevant.
Measuring in millis is pretty tricky, since you will need to compute an average which will have quite high variance... and the reason for that variance is when in the frame input was triggered + sprite position. So best to just calculate the "frames of delay between best case scenarios" imo.

That said, people are very welcome to have their own opinion about that, and use whatever metric they want. Thats why I provide all source data incl video and split out images. If you prefer to count "average delay from exact movement of input trigger, to sprite in middle of screen", instead of "frames of inaction after an input frame" then you can just add +1 to measurements basically.

[Lethe]

If a game logically cannot possibly display the result of an input faster than the time it takes to display the frame, what is the purpose of labeling that delay as "lag"?

Or more precisely, if you say a game has two additional frames of lag because you had an unfortunate input timing, and your ingame avatar is in the way bottom of the screen, that says absolutely nothing about how the game in question works, it's just noise that serves no purpose in a comparison.

What I'm getting at is that the zero-frame nomenclature isn't going to be any less confusing (more sensible) to people who'd also end up misinterpreting other ways of describing it. People don't understand how this works, they see a 0 and think that means instant.
All the previous tests I've seen have used a 1-frame baseline, and if you account for that, they arrive at very similar numbers. But then all of those tests were less rigorous than these ones are, so it'd be appropriate to find a consensus here. (These days, a ~33ms response time feels pretty soupy to me when under the right circumstances)

It should be pretty clear that this is only refering to input latency for analog video arcade games. This means 120hz is not relevant.
Measuring in millis is pretty tricky, since you will need to compute an average which will have quite high variance... and the reason for that variance is when in the frame input was triggered + sprite position. So best to just calculate the "frames of delay between best case scenarios" imo.

Yeah I know, and that's all sensible. It's only a semantic issue.

[Buffi]

I agree 100% about it being confusing, and people not being clear on what they are measuring which is why I try to be as clear as possible.

And as you are mentioning, its just a question of baseline. If:
- Input is pressed during frame0
- Output is visible the next frame (frame1)

Is that 0 or 1 frames of lag?
I’m using 0 in these values. If you prefer to use 1 as baseline, add 1. Neither is incorrect really but different things are measured (engine lag in frames vs aprox response time to sprite movement)

[Buffi]

Guilty Gear X 1.5 for an Atomiswave game feeling less laggy than Dolphin Blue.

Ok, checked this and Metal Slug 6, and yes.
GGX1.5 is 3 frame, so one less than Dolphin Blue.
... however Metal Slug 6 is 5 frames of lag, and is the slowest game I've checked so far.

both have video + images at the site now.

Let me know if there's any particular games people are curious about. I have a lot of pcbs + Darksoft multis for many systems.

[Steven]

Definitely want lag testing on all Toaplan PCBs. Doesn't matter if it's Out Zone or Teki-Paki or Get Star or Enma Daiou or Genkai Chousen Distopia or whatever.

[Buffi]

Definitely want lag testing on all Toaplan PCBs. Doesn't matter if it's Out Zone or Teki-Paki or Get Star or Enma Daiou or Genkai Chousen Distopia or whatever.

Unfortunately Toaplan is really not my thing, so can't really check much there

edit: I have Batsugun and will add that some time later though. IIRC it's two frames when I checked it earlier before making the site

[DMC]

Great work, Buffi! I'd be very interested in Dimahoo input lag.

[PC Engine Fan X!]

What's the lag on the classic CPS2 stgs of Dimahoo, GigaWing & Mars Matrix?

And on the Taito G-Net stgs of Psyvariar Medium Unit, Psyvariar Revision, XII Stag, Shikigami No Shiro, Night Raid, etc.?

Would the classic Capcom jamma pcb of Hyper Dyne Sidearms (circa 1986) have lag as well?

PC Engine Fan X! ^_~

[Buffi]

I dont have Hyperdyne. I do however have Darksoft multis for cps1, cps2 and cps3 ao can check anything there. Will check Dimahoo and the other later.

Also have a hacked g-net so can so that too

[Bassa-Bassa]

Guilty Gear X 1.5 for an Atomiswave game feeling less laggy than Dolphin Blue.

Ok, checked this and Metal Slug 6, and yes.
GGX1.5 is 3 frame, so one less than Dolphin Blue.
... however Metal Slug 6 is 5 frames of lag, and is the slowest game I've checked so far.

both have video + images at the site now.

Thanks for confirming, you're fast. Didn't expect it to be just 1 frame of difference, I'm usually quite sensitive to this but I don't really think 1 frame can be noticed. Though my experience with them is through the DC conversions, which are basically the same code but indeed the input mapping is obviously altered, so who knows.

A bit unrelated - since you have the PCBs, do you have a list of particular CPU % tweaks for the CV-1000 games in Mame to couple with your blitter changes, now they are officially added?

[Buffi]

A bit unrelated - since you have the PCBs, do you have a list of particular CPU % tweaks for the CV-1000 games in Mame to couple with your blitter changes, now they are officially added?

That's completely different from this yes, but the CPU MAME slider just downclocks the CPU, which is pretty different from the actual SH3 waitstates on hardware, so there wont really exist a "best" or accurate value across scenarios. Just pick something that feels ok.

[Rastan78]

This is cool. Thanks for putting out this info buffi. I'm curious about Taito F3 and Seibu SPI if those happen to be ones you have laying around.

[Sumez]

I'm gonna try to do a setup identical to this on my cab to get some tests down as well, no reason not to help build a good database of this stuff that's previously just been flying around as halfway nonsupported speculation most of the time.

I got a few older PCBs worth testing. Also F3, but none of the shooters for it and also no Multi, but I'm sure Buffi has that covered.

[donluca]

Outstanding work, thank you so much for doing this and sharing it.

[Buffi]

This is cool. Thanks for putting out this info buffi. I'm curious about Taito F3 and Seibu SPI if those happen to be ones you have laying around.

I have a Taito F3 with darksoft multi. No Seibu SPI though.

[Mortificator]

If a game logically cannot possibly display the result of an input faster than the time it takes to display the frame, what is the purpose of labeling that delay as "lag"?

lol

"I have one kid," I say, having both a son and a daughter, since if you're measuring children you can't possibly have less then one so there's no purpose in labeling the 1st as the 1st.

Spoiler

No one counts like this

[Bassa-Bassa]

I agree with differenciating actual lag from response time no matter what others have been doing, but it's an issue which solves as easy as using added lag as the term here.

That's completely different from this yes, but the CPU MAME slider just downclocks the CPU, which is pretty different from the actual SH3 waitstates on hardware, so there wont really exist a "best" or accurate value across scenarios. Just pick something that feels ok.

I'd love to know what PCB owners/experts would pick though, but indeed there's a thread for that already. Thanks.

[Buffi]

If a game logically cannot possibly display the result of an input faster than the time it takes to display the frame, what is the purpose of labeling that delay as "lag"?

lol

"I have one kid," I say, having both a son and a daughter, since if you're measuring children you can't possibly have less then one so there's no purpose in labeling the 1st as the 1st.

Spoiler

No one counts like this

As mentioned, if you prefer to measure ”average response time for a sprite at center of screen”, just add 1 (since delay from input to sampling will average half a frame, and half a frame will be spent reaching the sprite). Neither is incorrect, they just measure different things. No point in arguing about which value is ”better”. They measure different things, and having a clear presentation of the source data makes it easy to realize what is meant.

[Sumez]

"I have one kid," I say, having both a son and a daughter, since if you're measuring children you can't possibly have less then one so there's no purpose in labeling the 1st as the 1st.

Spoiler

No one counts like this

If your kids are standing so close they are leaning against eachother, are they 0cm from each other, or the width of both kids from eachother?

Spoiler

yes, people measure like that

Either way, when I say Buffi's method is sensible, it has nothing to do with his choice to use 0-index, but his choice of discounting CRT raster time, which says absolutely nothing about the inherent lag of a computer game.