Super Turbo Offline Setup Guide & Lag Rating

KuroppiKuroppi くろっぴJoined: Posts: 891
DGV (Dark Gaiden & Vintage) along with Papasi have been working on a Offline Setup Guide to assist players who are looking to find an offline setup that best suits them. A lot of research, testing and other work went into making this chart so a special thanks to DGV and Papasi along with Zaspacer for creating the chart.

http://www.strevival.com/strategy/offlinesetupguide

ST_setups_offline_072013.png

Shhh... ST in da house!

www.strevival.com | STR Facebook | Twitter
«1

Comments

  • delatroydelatroy My Blue Boat Joined: Posts: 293
    Cheers fellas! Out of curiosity, how did you measure the input lag on the CRT / LCDs? Was it assumed based on the manufactrurer listed response time and / or refresh rate or was it physically tested somehow?

    There's also this thing called "micro stutter" which affects Vista/7/8 but does not affect XP which definitely has an impact on how it "feels".
  • zaspacerzaspacer Joined: Posts: 553
    Big thanks to Rufus as well. And also thanks to all the other people who have contributed to testing and discussing this issue over the years.
    streetfighterdojo.com - video library of top players
  • oldschool_BRoldschool_BR Projectile spammer Joined: Posts: 2,442
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    Those numbers are higher than the results I got:
    Input lag:
    Arcade 2.5 frames average (all speeds)
    Dreacast 3.5-4.5 frames average (higher turbo=lower lag)
    Xbox 360 4.5-4.8 frames average (higher turbo=lower lag)
    PS3 5.3-5.7 frames average (higher turbo=lower lag)
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • hanasuhanasu Joined: Posts: 130
    Thanks Papasi!

    (and DGV)
    _______________________________________________________________
    STRevival

    Twitter | Twitch | Youtube
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    edited July 2013
    Thanks for mentioning the default USB polling rate as a source of input lag.

    It's relatively easy to manually set the polling rate for a USB mouse. Let see if the TE S+ can handle 250Hz polling.

    I'm not sure how to check if it's working correctly at that rate.Any ideas?
    SSF4T on GGPO is very fun.
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    @Rufus it's impossible that the game would have less than 4 frames of lag (66.6 ms) since it runs at a 60 Hz refresh rate.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    edited July 2013
    Moonchilde wrote: »
    @Rufus it's impossible that the game would have less than 4 frames of lag (66.6 ms) since it runs at a 60 Hz refresh rate.

    What are you taking about? A frame can be displayed per refresh making the theoretical minimum input lag the next refresh, which happens 60 times per second.
    SSF4T on GGPO is very fun.
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    It means the fastest possible response is 4 frames from the time you hit a button to the time you see it on screen on a game that is 60 hz. That's the bare minimum, you can't go lower than that it's physically impossible. You can have an input come out on any frame of a game, but that all that means is that you've pressed the button 4 frames earlier. An input can be done at any point during the refresh however, it still takes 4 frames for it to happen.

    On a game that runs at 120 Hz it takes 2 frames. On a game that runs at 30 Hz it takes 8 frames.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    edited July 2013
    Moonchilde wrote: »
    @Rufus it's impossible that the game would have less than 4 frames of lag (66.6 ms) since it runs at a 60 Hz refresh rate.
    What are you taking about? A frame can be displayed per refresh making the theoretical minimum input lag the next refresh, which happens 60 times per second.

    In theory, the next 'pixel' could be changed when a button is pushed, though Street Fighter won't do that.
    On a game that runs at 120 Hz it takes 2 frames. On a game that runs at 30 Hz it takes 8 frames.
    "Those words. I do not think they mean what you think they mean."
    -- Fezzig, The Princess Bride (paraphrased)

    There's some confusion here. The CPS-2 A board runs on a Motorolla 68000 chip with a 16Mhz clock. (That's 16000000Hz.) When people talk about the game running at 60hz, they're really only referring to the vsync of the display. (It's a little sloppy for other reasons too -- SF2T is interlaced, so what people refer to as a frame is really a field, and it's not actually 60hz, but 59.94 nominal, and so on.)

    I don't want to get too far off track, but I'm a little curious to know what the explanation for requiring four frames of lag is.

    Regarding the OP:
    I understand that there are differences due to how people count, but I don't know how something like this could be 6-7 frames:
    http://www.pedantic.org/~nate/HDR/misc/delay/turbodelay1.html

    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    Moonchilde wrote: »
    It means the fastest possible response is 4 frames from the time you hit a button to the time you see it on screen on a game that is 60 hz. That's the bare minimum, you can't go lower than that it's physically impossible. You can have an input come out on any frame of a game, but that all that means is that you've pressed the button 4 frames earlier. An input can be done at any point during the refresh however, it still takes 4 frames for it to happen.

    On a game that runs at 120 Hz it takes 2 frames. On a game that runs at 30 Hz it takes 8 frames.

    The total input lag is the time required after input for 1) game to process the input and generate the next frame 2) monitor lag 3) vsync 4) cache ahead buffering

    I have a feeling vsync and cache ahead buffering is what you are talking about as that's causing the 4 frame lag on a 60Hz screen.
    SSF4T on GGPO is very fun.
  • DarksakulDarksakul Your lack of faith disturbs me Joined: Posts: 24,301
    Kuroppi wrote: »

    So other than reposting a chart, how do we know any of this data is valid?
    What process or technique was used to gather this data?
    What is the significance of these numbers? Are there arbitrarily chosen or do they represent frame rate?

    Also the Poll rate for USB devices when it comes to game pads /joysticks can be misleading, specially to those who don't understand USB polling.
    “Strong people don't put others down... They lift them up.”
    - Darth Vader, Philanthropist
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    Darksakul wrote: »
    Kuroppi wrote: »

    So other than reposting a chart, how do we know any of this data is valid?
    What process or technique was used to gather this data?
    What is the significance of these numbers? Are there arbitrarily chosen or do they represent frame rate?

    Also the Poll rate for USB devices when it comes to game pads /joysticks can be misleading, specially to those who don't understand USB polling.

    I pour a couple hours looking into that issue. The conclusion is that USB poll rate doesn't matter on arcade sticks and gamepads. USB polling really only matter for the mouse. Also, the keyboard has the worst input delay by far, on the order of 20-30 ms before an input is even registered by the machine.
    SSF4T on GGPO is very fun.
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    So other than reposting a chart, how do we know any of this data is valid?
    What process or technique was used to gather this data?

    In this thread:
    http://forums.shoryuken.com/discussion/comment/7447877'

    My testing method is too hook a wire from the button to the video signal and then to record the mixed signal with an Canopus ADVC 100 or 110 which produces full frame rate DV video. There are opto-isolaters involved, but the change in the video signal should be effectively instant on the time scales we're talking about

    For the supergun testing, the video signal was modified on the JAMMA side of the video converter to control for converter lag. Xbox 360, PS3 and Dreamcast testing was done using composite out. Dreamcast was with a toodles CD, Xbox 360 and PS3 with HDR remixed in training mode.

    I can't recall the number of samples offhand, I think I got on the order of 100 for the Xbox 360 and 20-50 for the others.

    Here's some stuff about how I counted frames:
    http://www.pedantic.org/~nate/HDR/misc/delay/turbodelay1.html
    http://www.pedantic.org/~nate/HDR/misc/delay/righttest.html

    If you have other questions, feel free to ask.

    As for the numbers themselves, I can't independantly verify my own results.
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    It's a good chart. I wonder what is causing that controller lag for your setup.

    I looked into increasing polling rate for my Xbox Madcatz TE S+ but further research into the issue reveals that for a game controller, the controller should be polling as fast as the game is asking for the state of the controller.
    SSF4T on GGPO is very fun.
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    edited July 2013
    MaxGrit wrote: »
    It's a good chart. I wonder what is causing that controller lag for your setup.

    I looked into increasing polling rate for my Xbox Madcatz TE S+ but further research into the issue reveals that for a game controller, the controller should be polling as fast as the game is asking for the state of the controller.

    I've posted this elsewhere, but SRK search leaves something to be desired so:

    Let's assume, for the sake of discussion, that on the PS3 and the XBox 360 the sampling rates for the game and the controller aren't synchronized.

    Let's assume that the time between an input change and when the controller controller gets sampled is randomly distributed over the length of the sampling cycle. So, for example, if the controller is sampled every 8 ms, then the time varies from 0-8ms, average 4ms, and if the controller is sampled every ms, then the time varies from 0-1ms, average 0.5 ms. That means that the controller which gets sampled every 8ms has - on average - 3.5ms more lag than the one that gets sampled every 1ms.

    Now, typical USB 1 sampling rates include 125Hz (every 8ms) and 1000Hz (every 1ms) so if some sticks are sampled at 125 and others are sampled at 1000, then we would expect to see an average difference of 3.5 ms in lag between the two.

    Now, I wired a button on my 1st generation Xbox360 MadCatz SE and a button on a first generation PS360 together so that they are activated simulataneously, and counted how often I got double hits, how often the SE stick interrupted the PS360 stick, and how often the PS360 interrupted the SE. I don't recall the exact results, but they were something like:
    PS360 first: 9
    Double hit: 41
    SE stick: 0
    (The actual figures are buried in tech talk, and this experiment has been reported on by others there.)

    If the SE samples every 8 ms, and the PS360 samples every 1 ms, we would expect the SE to win 3.5/16.68=.209 of the time which is extremely consistent with the experimental results.

    I also got approximately the same 3.5 ms delay differences when I did video-recorder based lag testing of the PS360 and SE stick on my Xbox360.

    I don't have the sophistication to check the actual sampling rates, and I've given away my Xbox, but USB sampling rate seems like a very plausible explanation for that difference in the input lag.

    Edit: I do suspect that the chart overstates the effect of input lag.
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • Dark GaidenDark Gaiden Joined: Posts: 284
    edited July 2013
    -MaxGrit:

    I can confirm that the USB poll rate does in fact have an influence on an arcade joysticks (PS3 based sticks only). The difference between playing with 125ms (standard USB setting) and 1000mz is pretty noticeable. 360 joysticks are unfortunately not supported by the poll rate modifying programs as of yet.

  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    edited July 2013
    Rufus wrote: »
    What are you taking about? A frame can be displayed per refresh making the theoretical minimum input lag the next refresh, which happens 60 times per second.

    In theory, the next 'pixel' could be changed when a button is pushed, though Street Fighter won't do that.
    On a game that runs at 120 Hz it takes 2 frames. On a game that runs at 30 Hz it takes 8 frames.
    "Those words. I do not think they mean what you think they mean."
    -- Fezzig, The Princess Bride (paraphrased)

    There's some confusion here. The CPS-2 A board runs on a Motorolla 68000 chip with a 16Mhz clock. (That's 16000000Hz.) When people talk about the game running at 60hz, they're really only referring to the vsync of the display. (It's a little sloppy for other reasons too -- SF2T is interlaced, so what people refer to as a frame is really a field, and it's not actually 60hz, but 59.94 nominal, and so on.)

    I don't want to get too far off track, but I'm a little curious to know what the explanation for requiring four frames of lag is.

    Regarding the OP:
    I understand that there are differences due to how people count, but I don't know how something like this could be 6-7 frames:
    http://www.pedantic.org/~nate/HDR/misc/delay/turbodelay1.html

    Unfortunately game programmers have confirmed what I wrote and testing has proven that the speed the game updates indeed affects the input lag as I specified. It's why games running without vsync at at higher refresh rates can process inputs faster than games running at lower refresh rates. Games refreshing at 30 fps (for 3D games) have 7 to 8 (most of the time 8 minimum, and often higher because of post) frames of lag native to the frame rate. Additional post or additional CPU/GPU overhead will cause more frames of lag. Killzone 2 is a great example of lots of post adding a bunch of extra lag.

    If you really want to read the article, you can. The quotes are direct from a game programmer, in case you don't want to take my word for it.
    As Neversoft itself is responsible for most of the latest Guitar Hero games, where latency is hugely important, it is perhaps not surprising that Mick West took such an interest in this subject, and his conclusions are intriguing.

    - The lowest latencies a video game can have is 50ms (three frames) - the PS3 XMB runs at this rate, but few games reach it. (My note: 50 ms is actually the start of the 4th frame, so it isn't 3 frames at that point)

    - Most 60FPS games have a 66.67ms latency - Ridge Racer 7, for example.

    - 30FPS games have a minimum potential lag of 100ms, but many exceed this.

    Source: http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article

    I'm more inclined to believe someone who codes games for a living which are response time intensive.

    I'm also quite aware of the fact the game's processor isn't 60 Hz and well aware that's the refresh, there isn't any confusion there. The game is also progressive from what I recall, as you can clearly see scanlines which you won't see on an interlaced image since each field is alternating the scanlines to make a solid picture. R-Cade Gaming and I had a huge discussion about this and I learned a lot from him. So, it's actually updating a progressive signal at 60 Hz, not interlaced fields.

    There is also a reason action games like DMC (not DmC) and Street Fighter target 60 fps, because of the natively lower input delay.

    No game software and hardware will ever have instant input delay. However, the faster you render the game the faster the inputs can be, which is why many twitch shooter gamers will lower the graphics, turn off vsync, and run at 120 Hz because of the native faster input delay.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    -MaxGrit:

    I can confirm that the USB poll rate does in fact have an influence on an arcade joysticks (PS3 based sticks only). The difference between playing with 125ms (standard USB setting) and 1000mz is pretty noticeable. 360 joysticks are unfortunately not supported by the poll rate modifying programs as of yet.

    Heyo, can you tell me your testing method? I'd like to see it.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    edited July 2013
    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.
    3.4 Input Handling
    GLFW supports three channels of user input: keyboard input, mouse input and joystick input.
    Keyboard and mouse input can be treated either as events, using callback functions, or as state, using
    functions for polling specific keyboard and mouse states. Regardless of which method is used, all
    keyboard and mouse input is collected using window event polling.
    Joystick input is asynchronous to the keyboard and mouse input, and does not require event polling for
    keeping up to date joystick information. Also, joystick input is independent of any window, so a
    window does not have to be opened for joystick input to be used.
    SSF4T on GGPO is very fun.
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    Moonchilde wrote: »
    ....
    Thanks for the link to the article. Some interesting reading.
    ...I'm more inclined to believe someone who codes games for a living which are response time intensive...
    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.
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    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.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • Hyphen-atedHyphen-ated Joined: Posts: 39
    edited July 2013
    Moonchilde wrote: »
    The quote was from Mike West, a programmer at Neversoft, not Richard.
    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 latencies a video game can have is 50ms (three frames) - the PS3 XMB runs at this rate, but few games reach it
    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.
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    edited July 2013
    http://www.gamasutra.com/view/feature/130359/programming_responsiveness.php

    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.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    edited July 2013
    Moonchilde wrote: »
    The quote was from Mike West, a programmer at Neversoft, not Richard.
    Mick's article is here: http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php
    ...

    That article links to this one where Mick does make the 50 ms claim:
    http://www.gamasutra.com/view/feature/130359/programming_responsiveness.php?page=1
    ...
    Sometime in Frame 1, the player presses a button to fire a gun. Since the input processing has already been done for that frame, this input is read in Frame 2. Frame 2 updates the logic state based on this button press (a shot is fired).

    Also in Frame 2, the CPU side of rendering is performed with this new logic state. Then in Frame 3, the GPU performs the actual rendering of this new logic state. Finally at the start of Frame 4, the newly rendered frame is presented to the user by flipping the frame buffers.
    ...
    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.)
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • Hyphen-atedHyphen-ated Joined: Posts: 39
    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.
  • DarksakulDarksakul Your lack of faith disturbs me Joined: Posts: 24,301
    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.
    “Strong people don't put others down... They lift them up.”
    - Darth Vader, Philanthropist
  • MoonchildeMoonchilde Resident tech talk double poster Joined: Posts: 4,838
    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.
    Disclaimer: I work for Paradise Arcade Shop. My posts are probably biased. Take that into consideration. Bye!
  • undamnedundamned Wake up! Time to die! Joined: Posts: 1,687
    It's getting hot up in here! In fact, MaxGrit is taking off his clothes!
    -ud
  • Hyphen-atedHyphen-ated Joined: Posts: 39
    Moonchilde wrote: »
    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.
    Those things can all happen during a single update; they don't have to each happen on their own frames!
    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.
    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?


  • papasipapasi N Ken is the truth Joined: Posts: 1,568
    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.
    eltrouble "I doubt that ST will be on the main stream ever again."
    OhNuki: Real men play ST!!
    James Chen: there is something special about playing ST on a cab. It just feels so goooooood.
    Super Turbo Hitbox & safe jump guide http://www.strevival.com/hitbox/
  • papasipapasi N Ken is the truth Joined: Posts: 1,568
    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.
    eltrouble "I doubt that ST will be on the main stream ever again."
    OhNuki: Real men play ST!!
    James Chen: there is something special about playing ST on a cab. It just feels so goooooood.
    Super Turbo Hitbox & safe jump guide http://www.strevival.com/hitbox/
  • undamnedundamned Wake up! Time to die! Joined: Posts: 1,687
    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
  • oldschool_BRoldschool_BR Projectile spammer Joined: Posts: 2,442
    undamned wrote: »
    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
    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.
  • papasipapasi N Ken is the truth Joined: Posts: 1,568
    edited July 2013
    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)
    eltrouble "I doubt that ST will be on the main stream ever again."
    OhNuki: Real men play ST!!
    James Chen: there is something special about playing ST on a cab. It just feels so goooooood.
    Super Turbo Hitbox & safe jump guide http://www.strevival.com/hitbox/
  • RufusRufus An unexpected database error has occurred. Joined: Posts: 1,966
    edited August 2013
    undamned wrote: »
    ...in-game lag was actually longer than in the Test menu...

    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. :/

    Edit: Found them -
    http://www.pedantic.org/~nate/SF2T/lag/turbo3/
    Post edited by Rufus on
    Hitboxes http://www.pedantic.org/~nate/HDR/
    "You don't know what you're talking about as much as I do." -- Unknown
  • Hyphen-atedHyphen-ated Joined: Posts: 39
    papasi wrote:
    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.
    Naw, that's exactly the correct definition of "input lag" in this context; the column header is fine.
    papasi wrote: »
    i used the rh test only because that's what NKI used in his original video.
    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)
    papasi wrote: »
    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".
    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.
    papasi wrote: »
    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.
    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.
  • MaxGritMaxGrit Master Baiter Joined: Posts: 291
    edited August 2013
    undamned wrote: »
    It's getting hot up in here! In fact, MaxGrit is taking off his clothes!
    -ud

    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. . .
    SSF4T on GGPO is very fun.
  • undamnedundamned Wake up! Time to die! Joined: Posts: 1,687
    I haven't read through it all, but here's an older discussion on timing between different flavours of ST: http://forums.shoryuken.com/discussion/81717/comparison-of-hdr-versions-ps3-360-dc-cps2/p1
    -ud
  • zaspacerzaspacer Joined: Posts: 553
    edited August 2013
    Darksakul wrote: »
    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.

    Good catch.

    With regards to HDR, we will change the chart from "Super Street Fighter Turbo HD Remix" to "Super Street Fighter Turbo HD Remix: Classic Mode". (it was never intended to list non-Classic Mode, this was a labeling mistake on our part)

    With regards to "arcade perfect" vs. ports, we will add a Note indicating which versions are "ports" and what that means in a general sense.


    streetfighterdojo.com - video library of top players
«1
Sign In or Register to comment.