Super Turbo Offline Setup Guide & Lag Rating

Classic Fighting Games Super Street Fighter II Turbo
21

The light data might be wrong in experimental design. Let me explain why I think so:

One assumption I made: In looking up polling data, I assumed that the TE S+ to have similar polling rate design as the wired gamepad and went from there as both are official controllers for the Xbox360.

What lead me to believe that polling rate doesn’t matter is that I found a document on how GLFW controller input is recognized. The document shows that it’s up to the program to ask for the state of the controller (which buttons are pressed and analog stick data) at program determined points of time.

Your experiment was designed to test how often a controller would send its state to the computer automatically. It didn’t include the fact that in addition to the automatic polls, additional controller states are requested by GLFW programs.

22

Thanks for the link to the article. Some interesting reading.

Richard Leadbetter (the article’s author) is a professional game journalist, and not a coder.

The use of ‘frames’ as units of time is quite sloppy since there are game frames, frames of camera footage, and notional frames as 1/60 of a second.
(The same issue probably applies to “2 frames at 120Hz” which I read as 1/60 of a second, but was probably intended to mean 2/60 of a second.)

50ms is pretty much exactly NTSC frames: 16.683ms*3=50.049ms.

I strongly suspect that this business of 50ms lag referred to in the article is a technical feature of the Playstation 3. Specifically that the PS3 has a 3 (video) frame
display pipe line, so it has to chew through three screens worth of old data before the new data can be shown. (This would also explain why the PS3 is generally laggier
than the xbox 360.)

I can assure you that (1) there is no universal 50 ms minimum lag for video games, and (2) that SF2T on CPS2 hardware has less than 50ms lag.

23

The quote was from Mike West, a programmer at Neversoft, not Richard. Richard just wrote the article based on the information and quotes from Mike West and then proceeded to test them himself and shared his test results on the site.

1 game frame at 60 fps = 1 video frame at 60 fps = 1 refresh at 60 Hz. As long as you’re keeping all that in mind, then it’s easy to compare frames.

1 game frame at 30 fps = 2 video frames at 60 fps = 2 refresh at 60 Hz. So when a 30 fps game is being played, it has what is equivalent to 7 or 8 frames in a 60 fps game. That’s why you’ll never see a serious fighting game at 30 fps, because it would be ass.

Games that run at 120 fps/Hz vsynced will have what is equivalent to 2 frames of lag in a 60 fps game, at least from what I’ve read, but have not seen serious testing on this.

We measure everything in 1/60th frames because most displays are 60 Hz and are designed to update 60 times a second, it was a standard for many years and even modern HDTV is standardized to 60 Hz.

Also, if you do the math for the frame rate, 16.7*4 = 66.8 ms. However the math is giving you the very end of the frame, not the start.

0 to 16.7 is the first frame
16.8 to 33.4 is the second
33.5 to 50.1 is the third
50.2 to 66.8 is the fourth.

Anything with 50 ms of lag is already starting the 4th frame, which puts it into the 4 frames of lag territory since the 4th frame is when you’ll first see any action you do. In fact, red, green, and blue phosphors all have different decay rates so it’s possible that the green phosphors are already starting the next frame while the blue are still finishing the last. But that’s way off topic, lol! The bare minimum a 60 fps game can do is 50 ms as long as the software has pure access to the hardware. The PS3 XMB has nothing between it and the hardware and it updates at 60 fps / 60 Hz vsynced and that is why it can have a response of 4 frames. XMB has nothing to do with games like SF4 running 2 frames behind the Xbox version. Other 60 fps games on PS3 are hitting 4 to 5 frames as they normally would. PC games that will update to 60 Hz and maintain a consistent 60 fps will have an input lag of 4 frames. 2D games like NES, SNES, arcade games, and so on updated at 60 Hz and they will have a bare minimum 4 frames, and they were updated by Hz and not FPS because they didn’t render in frames. This is why CPS2 games are 4 frames of input lag. It can’t go lower, because that’s the nature of the beast. The information from Mike West matches Papasi’s and DGV’s tests of CPS2 hardware and other people’s tests of CPS2 hardware, 4 frames is it.

24

Mick’s article is here: http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php
This quote isn’t in it. The quote is Richard summarizing Mick West and getting things wrong.

The lowest latency a video game can have is one frame, like Rufus said. Maybe the PS3 can’t do it, but that’s a fact about the hardware and software in the PS3, not a fact about video games.

I don’t understand where you’re getting this idea that 4 frames of lag is “the nature of the beast” Moonchilde.

25

Read this please. Basically, once a game starts to update less frequently, it gets laggier. So if a game operates at 30 fps or updates at 30 Hz (I don’t know of any 2D game that ever updated at 30 Hz but they may exist) it doubles in lag over a game that updates in 60 fps or 60 Hz. He also illustrates the best case scenario is 4 frames at 60 fps / Hz. The frame you make the input on, the processing of the input, the rendering of the image, and the outcome on the 4th frame. This is his explanation of best case scenario on a game that is 60 frames per second He goes on to explain on the next page that 30 fps effectively doubles that.

I’m not even sure it’s theoretically possible but it might. If a game updates 240 times per second then that means it would get your input 1/240th (1/4 of 1/60th of a second, or a quarter of a frame for a 60 fps game) process it on the next 1/240 of a second, render it on the 3rd, and then output on the 4th which would all be within 1 frame of a 60 Hz update. So maybe it’s possible. But you can see why this isn’t a real world scenario and why it isn’t applicable to CPS2 games that update at 60 Hz.

26

That article links to this one where Mick does make the 50 ms claim:

But Mick makes assuptions here that don’t apply to all video games (or even all fighting games). For example, he assumes that the ‘CPU side of rendering’ and the ‘GPU rendering’ have to happen on separate frames. (I doubt that CPS-2 systems even have something that he’d consider to be a GPU.)

27

That is a good article.
If you have a game with a 4-step pipeline like “button press, game logic, rendering, send to display”, then yes, 4 frames of delay is the minimum.
That is not the only possible pipeline. Maybe it’s the smallest pipeline you can get on a system with a discrete gpu like a modern console.

If you can do logic, rendering, and sending to the display all during a single update, then you can get down to one frame of delay. Are existing gaming systems capable of this? I don’t know. I just googled and found some guy on the internet claiming to have done tests with a SNES that showed only 1-2 frames of delay.

28

I do also want to point out that to be truly fair, the same game should be used for comparison.

**Super Street Fighter X For matching Service **is no-way the same game as Super Street Fighter Turbo HD Remix.
And neither of those 2 games exist as format they are on the CPS2.

29

Regardless of modern console or not, ALL systems have a CPU and a video chip of some sort. Even back to the NES days, there was a CPU and a GPU capable of showing x amount of colors, x amount of sprites, smoother scrolling, VRAM for tile storage, and the likes. So, you still at some point have a CPU that is going to receive and input, process it, output video, and then we see it on a screen.

I think it’s safe to say based on the information we have that games that run at 60 fps or update at 60 Hz will generally have 4 frames of lag. Testing of 2D arcade hardware is showing this, 3D games with consistent frame rates are showing this, game programmers are saying this, and other people’s testing has shown this to be relatively accurate.

Is it possible you can get less than 4 frames? Maybe. But right now, the information we have concludes a general rule of thumb. If there is any repeatable testing out there that can prove otherwise, or even exceptions to the rule, then that would be fantastic. I haven’t seen any yet, though. If I had time I’d love to do some testing myself but I have other upcoming projects that I’d rather put my attention to than to spend time setting up cameras, recording my CRT monitor, editing video, and all that just to settle a debate on the internet when there is already plenty of information on the subject. However, I’d love to see testing that shows otherwise if anyone already has some.

Regardless, SF2 is not 2 frames of lag, it’s 4 frames, and several people’s testing has proven this, and at the moment that’s what matters most.

30

It’s getting hot up in here! In fact, MaxGrit is taking off his clothes!
-ud

31

Those things can all happen during a single update; they don’t have to each happen on their own frames!

Well, Rufus’s testing showed 2-3 frames of lag for SF2 on CPS2. Who are the several people whose testing has proven it’s 4 frames, and what were their methods? Were their methods better or worse than Rufus’s methods? Are they measuring the same thing?

32

don’t get confused with the “press the HK button => wait for round house animation” as the `lag’ of cps2.
that’s not it.

if you want to measure the absolute minimal input processing / game logic processing / video processing of the cps2 board, you have to write your own test program that only does that, flash it to a eprom and try it out.

i used the rh test only because that’s what NKI used in his original video.

every normal has different frame data and animation sprites and they don’t all start at the same frame.

in fact in the original NKI thread he also had a test for sim’s HP throw. that animation changes faster than the cr rh. same goes for ken’s fierce dp, etc.

33

I guess when terry made that chart, he used the “input lag” term as the column header, but that’s not accurate.

it should be “from the time you press the HK button, to when RH animation shows up on the screen” but that’s very long winded and not as easy to understand.

if we use “input lag” as the column header, we should have subtracted all numbers by the cps2 baseline.

i.e. cps2 is 0, it has no lag.

but i see you guys are already deep into another discussion altogether with ps3/snes/cps2 etc.

you guys are talking about the technical details of the minimal frames required for game input processing / game logic / video output etc etc.

well unless you are experts in the each of those systems, or you have dev setup that you can write minimal test cases to verify your claim, it’s rather pointless to speculate.

34

I think it was Rufus I was talking to a while back about using the Test menu on CPS2 to determine system lag. They were saying that the Test menu wasn’t a good timing bench mark because, although the Test menu is verifying the things we care about (screen updating based on inputs made), in-game lag was actually longer than in the Test menu.
-ud

35

It makes sense. But one gotta take that grounded normal move delay into account, that is, normals take longer to come out if you’re grounded.

36

that is probable but you still need hacker to reverse engineer that piece to be 100% sure that they don’t have any unnecessary programming logic to make it less responsive than necessary.

the requirement of the test menu is simply “respond to button press and show 1/0”, there is no requirement to “display 1/0 with absolutely no delay”

also to gamers / st players, they just want to know the console port is as responsive as the arcade cab.
arcade cab is the baseline. the games don’t care if arcade cab has 1 or 2 frames of minimal “processing”.

same for sf4 on xbox / ps3 and arcade.

if both xbox and arcade have additional 1 frame of lag like ps3, I think people might not complained at EVO (though some moves might not be as effective)

37

I think I said in-game lag might be different.

I tried to track down the old test video, but it looks like it got tossed in a quest for disk space. :confused:

Edit: Found them -
http://www.pedantic.org/~nate/SF2T/lag/turbo3/

38

Naw, that’s exactly the correct definition of “input lag” in this context; the column header is fine.

Aha, I found the video you’re talking about


This test shows arcade SF2 having 3 frames of lag. The video calls it 4 frames because he counts them wrong. (sorry nki. according to nki’s counting methods, if the game responds to your button press on the exact same frame that you made the press with no delay whatsoever, using perhaps some form of time travel, that counts as a delay of “one”. that just ain’t right)

Arcade is the baseline, but we should have accurate absolute numbers for what the baseline is, especially if people are going to test their setups at home and compare.

Yeah we got into that discussion because Rufus reported 2.5 frames of delay on arcade SF2 and Moonchilde disputed his numbers, saying it is physically impossible for any videogame to have input delay below 4 frames. My claim is “there is no such lower limit” and it can be verified by showing less lag than that on any setup for any game.

39

Lol. I wear only my underwear when I’m at home. I doubt taking my underwear off will help deal with the heat. I just might do it if it gets too hot!

Although that might turn up the heat even more. Hmm. . .

40

I haven’t read through it all, but here’s an older discussion on timing between different flavours of ST: Comparison of HDR Versions (PS3, 360, DC, CPS2)
-ud