I measured some input lag on original PCBs

[Buffi]

Was bored so filmed some extremely legit CPS2 games.
http://img.buffis.com/cps2.jpg

Pics and videos are now on http://inputlag.buffis.com/ . The stuff I checked:


Super Street Fighter II Turbo (CPS2): 2 frames
Dimahoo / Grand Mahou Daisakusen (CPS2): 2 frames
Progear no Arashi (CPS2): 2 frames
1944: The Loop Master (CPS2): 2 frames
Gigawing (CPS2): 3 frames
Mars Matrix (CPS2): 3 frames

TL;DR: Takumi are kindof bad at coding I guess. All non-Takumi games I checked were 2 frames, Takumis stuff is 3

[Buffi]

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

All of the G-NET stuff I tested were very responsive, and seemed to have the same delay

Night Raid (G-NET): 2 frames
XII Stag (G-NET): 2 frames
Shikigami no Shiro (G-NET): 2 frames
Psyvariar : Medium Unit (G-NET): 2 frames
Psyvariar : Revision (G-NET): 2 frames

Pics and videos on the site

(lol http://img.buffis.com/gnet.jpg )

[el_rika]

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?

Use my CPU numbers here (it is a more organised post than my older ones):
https://neo-source.com/index.php?topic=3934.0

I will definity test the new improved blitter method thoroughly, once the code gets ported to fbneo. Thanks for all your hard work buffi!

Small question: is there any change in Cpu requirements compared to the old code, or is it about the same?

[Buffi]

Use my CPU numbers here (it is a more organised post than my older ones):
https://neo-source.com/index.php?topic=3934.0

Small question: is there any change in Cpu requirements compared to the old code, or is it about the same?

This is completely unrelated to this thread, so maybe good to do it elsewhere.

... that said...

There is no point in trying to tune CPU numbers to that exact values (less than a percent), it doesn't really reflect the real SH3 hardware CPU slowdown anyways, so might as well just use 45% or 50% or whatever for all games (something that feels vaguely right).

While some games probably miss the cache more frequently than others due to how their engine works, using the CPU slider to approximate wait state behavior is still just a massive hack, so no real reason to overthink it.

Anyways... input lag huh...

[el_rika]

Anyways... input lag huh...

Is cps1 hw 1 frame of lag?

Sf2 is the snappiest vs game i ever played.

[Sumez]

The hardware in old pcbs like this don't have any inherent lag. (no input/output buffers or such)
They all share the common trait however that inputs are typically polled at the start of a frame, with all the game logic being performed while that frame is drawn, and based on this logic, memory and registers for the graphics hardware are altered just before it starts drawing the next frame.

As such you could say that a cps1 game will optimally have 1 frame of lag, yeah, with additional ones being the result of software quirks. None will ever have 0, which Is why I find it hard enough have an issue with Buffi counting from that.

[Buffi]

The hardware in old pcbs like this don't have any inherent lag. (no input/output buffers or such)
They all share the common trait however that inputs are typically polled at the start of a frame, with all the game logic being performed while that frame is drawn, and based on this logic, memory and registers for the graphics hardware are altered just before it starts drawing the next frame.

As such you could say that a cps1 game will optimally have 1 frame of lag, yeah, with additional ones being the result of software quirks. None will ever have 0, which Is why I find it hard enough have an issue with Buffi counting from that.

Dunno about cps1 but output buffers are definitely a thing in some newer arcade hardware at least.

Edit: I can check some cps1 though. Have the multi

Edit2: removed a misunderstanding from this post

[Sumez]

Dunno about cps1 but output buffers are definitely a thing in some newer arcade hardware at least.

Oh for sure! But hard to imagine on an 80s system relying on hardware sprites and background tilemaps to fill a screen with graphics

[jd213]

I wonder if ports or official emulation of these have less lag.

I remember reading how the Saturn port of Battle Garegga has no (?) input lag compared to the 1 or so frame of the PCB.

[Buffi]

I wonder if ports or official emulation of these have less lag.

I remember reading how the Saturn port of Battle Garegga has no (?) input lag compared to the 1 or so frame of the PCB.

As mentioned on the page, Garegga has 3+ frames of lag on pcb (is supposedly 4 sometimes, but 3 in s1).

Dunno what the Saturn port has, but "no lag" makes no sense really.

[jd213]

Ah, missed Garegga or forgot about it since it was listed along with Batrider.

I doubt the Saturn port truly has 0 frames of lag either, but having less lag seems plausible. This was the post that I was thinking of : https://shmups.system11.org/viewtopic.p ... 44#p876544
Some other discussion on lag here: https://shmups.system11.org/viewtopic.php?f=1&t=70816

I've only played the Saturn port myself.

[alamone]

Thanks for this testing. I'm not sure if you are aware but I'm also doing a similar project, with also upscaler compatibility tested as well:

https://docs.google.com/spreadsheets/d/ ... sp=sharing

I've been kinda neglecting it lately but I might get around to completing it out in a bit after I finish setting up all my RGB gear.

[Buffi]

Thanks for this testing. I'm not sure if you are aware but I'm also doing a similar project, with also upscaler compatibility tested as well:

https://docs.google.com/spreadsheets/d/ ... sp=sharing

I've been kinda neglecting it lately but I might get around to completing it out in a bit after I finish setting up all my RGB gear.

Hi!

I think this is a nice spreadsheet since you pretty clearly describe how you are measuring things, and the upscaler compatibility sections are very nice.

That said, some comments:
- For the lag measurements, I'd really recommend cutting out upscalers and monitors completely and just going on the raw signals, since that excludes external factors.
- Measuring milliseconds from light-up to sprite movement will differ by up to a 16+ milliseconds depending on where on the screen the sprite is located, since sprites drawn at the bottom will be drawn about 16 millis later than sprites at the top.
- While the numbers represented are not wrong, since they are accurately representing delays as measured by your method, they are also a bit unclear in terms of representing the lag of the games imo. Lets take an example with Strikers 1945

The way lag works in this game is that after an input has been triggered, it will be sampled after the next VBLANK interrupt. After three frames of non-movement, the next frame will then be output ("3 frames of input lag" by the definition on my page).

Depending on when in the "input frame" the button was pressed there will be a variance of a full frame of delay, which will average out to 0.5 frames across many measurements. In addition to this, there will be the delay of the raster reaching the sprite from the top of screen. This means that "3.84" seems like a reasonable value measured given the small amount of samples.

- Since using 240fps camera (which I also use), the accuracy of "milliseconds" from input to output will be very low. 240fps means that you will have a gap of 0.25 frames between each image. This means that you will have quite high variance in the averages. BUT, you do report this as "Average lag ms/frames", which is accurate so just good to be aware of.


Overall, this is a good spreadsheet though, and especially the compatibility section is nice. I keep a XRGB-Mini around for recording stuff my OSSC wont handle.

[alamone]

That said, some comments:
- For the lag measurements, I'd really recommend cutting out upscalers and monitors completely and just going on the raw signals, since that excludes external factors.
- Measuring milliseconds from light-up to sprite movement will differ by up to a 16+ milliseconds depending on where on the screen the sprite is located, since sprites drawn at the bottom will be drawn about 16 millis later than sprites at the top.
- While the numbers represented are not wrong, since they are accurately representing delays as measured by your method, they are also a bit unclear in terms of representing the lag of the games imo. Lets take an example with Strikers 1945

- I'll be retesting using CRTs for future readings, but I think the latency that the LG monitor and OSSC add are pretty much negligible anyway.
- I guess this could be mitigated by always trying to measure when the player ship is at the upper part of the screen (for horizontal) or the left side of the screen (for vertical)?
- What would be your suggestion for adjusting the lag values to better represent actual in-game lag?

[Buffi]

That said, some comments:
- For the lag measurements, I'd really recommend cutting out upscalers and monitors completely and just going on the raw signals, since that excludes external factors.
- Measuring milliseconds from light-up to sprite movement will differ by up to a 16+ milliseconds depending on where on the screen the sprite is located, since sprites drawn at the bottom will be drawn about 16 millis later than sprites at the top.
- While the numbers represented are not wrong, since they are accurately representing delays as measured by your method, they are also a bit unclear in terms of representing the lag of the games imo. Lets take an example with Strikers 1945

- I'll be retesting using CRTs for future readings, but I think the latency that the LG monitor and OSSC add are pretty much negligible anyway.

> Yeah, I think there's not going to be too much latency introduced by those. One a pretty big benefit on testing on a CRT (other than not having to worry about digitization related delays) is that you can easily see the raster scan as it travels across the screen. Makes it easy to understand exactly what happens.

- I guess this could be mitigated by always trying to measure when the player ship is at the upper part of the screen (for horizontal) or the left side of the screen (for vertical)?

> Yes, ideally you'd want the sprite to be close to the first drawn lines in all games for consistency, if measuring milliseconds.

- What would be your suggestion for adjusting the lag values to better represent actual in-game lag?

> Depends on what you want to measure really, see below:

The first thing to keep in mind is, how do you define "0 frames of lag".

As per the definition on my page, zero frames of lag would be that right after the input sampling (typically around VBLANK), the output is drawn on the immediate frame afterwards. In practice, this would mean that the entire frames processing + write to VRAM would have to happen during VBLANK which is not realistic, so no game will ever do this, and the minimum you will see is one frame.

As per your definition, 0 would be "output changes on the same image as the LED lights up", which is obviously even more unrealistic, since it's possible that the input has not even been read by the game until close to a frame later, depending on time of button press.

The way I describe on my page tries to eliminate two factors:
- Timing of button press during input frame (since this will always introduce variance of up to one second)
- Sprite position of output frame

Byt only measuring the "non movement frames" between input and output.

Meassuring "milliseconds from LED button press to sprite movement" is perfectly valid as well, but will have very high variance, since especially the button press will cause big differences in the output.

If you want to do that I'd look into:
- Try to keep sprite as close to first drawn line as possible
- Ideally move up to a high fps camera. There's quite a few 960fps options now in phones even. Make 100% sure that the camera has real 960fps, and not using interpolation for faux 960fps.
- Use more than 4 samples. This isn't really enough to give a good average.

[Sumez]

In practice, this would mean that the entire frames processing + write to VRAM would have to happen during VBLANK which is not realistic, so no game will ever do this, and the minimum you will see is one frame.

Oh boy, let me tell you about the Atari 2600!
I wonder how many games on that system actually score a 0 frame lag using this method.

[alamone]

If you want to do that I'd look into:
- Try to keep sprite as close to first drawn line as possible
- Ideally move up to a high fps camera. There's quite a few 960fps options now in phones even. Make 100% sure that the camera has real 960fps, and not using interpolation for faux 960fps.
- Use more than 4 samples. This isn't really enough to give a good average.

- Yes, will be doing that by moving the player sprite close to the first line as mentioned above
- It seems like the majority of "960 fps" smartphones are doing software interpolation, which means that they are no better than an iPhone 240fps recording anyway. Are there any verified true 960fps smartphones, otherwise this is just vaporware?
- Will be doing 8 samples

[Buffi]

If you want to do that I'd look into:
- Try to keep sprite as close to first drawn line as possible
- Ideally move up to a high fps camera. There's quite a few 960fps options now in phones even. Make 100% sure that the camera has real 960fps, and not using interpolation for faux 960fps.
- Use more than 4 samples. This isn't really enough to give a good average.

- Yes, will be doing that by moving the player sprite close to the first line as mentioned above
- It seems like the majority of "960 fps" smartphones are doing software interpolation, which means that they are no better than an iPhone 240fps recording anyway. Are there any verified true 960fps smartphones, otherwise this is just vaporware?
- Will be doing 8 samples

There are some phones with native non-interpolated 960fps, but when I looked it up now, it looks like they can only record about half a second of video with it, which will make timing inputs awkward. Probably not a good idea then

[alamone]

Yeah, half a second is too short of a window, if it were at least a few seconds that would be viable... guess we just have to wait until slo-mo camera tech becomes more mainstream. Professional slo-mo video cameras cost thousands of dollars... while the cheaper ones have the short capture time issue as well.

[PC Engine Fan X!]

For Buffi or alamone,

Just out of curiosity, how many frames of lag on the classic Cave x86000 based arcade pcbs like Donpachi, Dodonpachi, ESP.ra.de, Guwange, Uo Poko and Dangun Feveron (aka Fever SOS)?

The same above listed question applied to the Cave/IGS based arcade pcbs like Dodonpachi Dai-Ou-Jou WL and BL, Ketsui and ESPgaluda?

And finally the same above listed question applied towards the Cave SH-3 based arcade pcbs like Ibara, Ibara Kuro, Dodonpachi Dai-Fukkatsu v1.5, Dodonpachi Dai-Fukkatsu Black Label, Dodonpachi Sai-Dai-Ou-Jou, etc?

PC Engine Fan X! ^_~

[Sumez]

Those questions are all answered in the first post of this thread