-A Gaming reacts to 8 frame of input lags
- Thread starter Tripon
- Start date
I prefer think of it as an unfair disadvantage for PS4 players, more than the other way around. 8 frames is way too much, this isn't just the natural result of not being able to turn off vsync on PS4, it's too laggy.
PC players would still be able to lower it even more, but I feel like the difference would be lower in practical terms when you can still react to any move that you should be able to react to on PS4. Not to mention PS4 players can just filter out PC players if they think it's still unfair. The problem with looking at it from a "PC players have an unfair advantage" point of view, at least right now, is that it doesn't put pressure on Capcom to fix what's unacceptable on PS4, it instead tries to equate to hacking something that is absolutely normal for PC games and has been used forever, in multiple games. If anything, they should offer the option on PS4 to turn it off, instead of trying to demonize it on PC.
Nvidia is about to launch new drivers that will allow what they call FastSync (it's essentially just real triple buffering), it has more lag than v-sync off, but way less than v-sync on. This will essentially, by that logic, turn every Nvidia user into a cheater. Without using L0WH4CKS to turn off vsync or anything like that. Even players who don't have any idea of what's going on will become "cheaters". The real issue is that this game has unacceptable amounts of lag. Even when you turn vsync off, it's not as low as other games with vsync off. It's a game issue.
Laurel_McFang
Member
yeah I see your point it's being portrayed as hacking when it's just what pc players do. Better performance on ps4 is the real issue.
I dont know why they didnt just use GGPO. Their own rollback code is garbage.
Aye, I ended up writing the Red Bull piece on this a few weeks ago, it goes a bit in depth on my own conclusions about it with input from guys like Fourwude in there: https://www.redbull.com/us/en/espor...9/input-latency-is-affecting-street-fighter-v
Self plug over, but it does have quite a bit in there going over the subject. A will make a quick note about overheads in the game though. They aren't slower due to input latency more than likely. There's a much higher chance that overheads are slower because they have a much higher impact in this game than something like SF4 due to the new stun rules and the defensive restrictions that were introduced. If they had been made slower due to latency, then it makes no sense for things like dashes to be so fast or the throw window to be so small. It just isn't consistent design if you you look at it is as being influenced by the delay. That part of the argument doesn't really hold up in his vid, the rest of it is kind of solid. His reaction time isn't taking into account things like identifying and reacting to different stimuli out of multiple results, but eh whatever reaction times are highly variable. I do like that he says calling it "just an excuse" makes it very hard to have an actual conversation about how we approach it as a problem.
It is mysterious why the delay is here though so I can't blame the speculation, but it doesn't line up at all as something that is intentional. The netcode solution isn't even delay based so that is another weird reason why intentional delay is a bit wonky.
Self plug over, but it does have quite a bit in there going over the subject. A will make a quick note about overheads in the game though. They aren't slower due to input latency more than likely. There's a much higher chance that overheads are slower because they have a much higher impact in this game than something like SF4 due to the new stun rules and the defensive restrictions that were introduced. If they had been made slower due to latency, then it makes no sense for things like dashes to be so fast or the throw window to be so small. It just isn't consistent design if you you look at it is as being influenced by the delay. That part of the argument doesn't really hold up in his vid, the rest of it is kind of solid. His reaction time isn't taking into account things like identifying and reacting to different stimuli out of multiple results, but eh whatever reaction times are highly variable. I do like that he says calling it "just an excuse" makes it very hard to have an actual conversation about how we approach it as a problem.
It is mysterious why the delay is here though so I can't blame the speculation, but it doesn't line up at all as something that is intentional. The netcode solution isn't even delay based so that is another weird reason why intentional delay is a bit wonky.
The lag is only the time it takes for a button press to register. If you press a button 20 times, each of those 20 presses will be 4 frames slow, but they'll come every 50 ms, or whatever the sampling rate of SF is (which is different than refresh rate which is different than input lag).
SixMachine
Member
I think your beginning comparison doesn't make sense. You can have as many inputs as you possibly can get within 60 frames, even simultaneous or consecutive ones, they just execute 8 frames later. Your number of commands executed is not capped or effected by the input lag.
There are 2 components to the input lag:
1) Input buffer. This is the intended input lag created by buffering input. This has its uses for interpreting input, animations, and smooth online play.
2) VSync frame buffer. This is unintended input lag and serves no practical purpose.
People are disabling Vsync to reduce the input lag. With Vsync off, the frame buffer is displayed directly so the frame displayed on the monitor is always as new as possible. With Vsync on, there are several frames being swapped in and out of the frame buffer, the frame being displayed is likely several frames old.
With double buffered vsync, the displayed frame is only 1 frame late in the worst case.
With triple buffered vsync, it's my experience that the displayed frame can be several frames later. I'm not an expert in the matter, but I think there are probably different buffering implementations that can result in varying amounts of frame delay.
Besides GSync and FastSync, which are currently only possible on PC, the only possible fix on console would be to disable Vsync altogether (trivial, but IQ will suffer) or optimize the triple buffering solution (non-trivial).
Durante probably knows a lot more about this. Would be awesome if he could chime in.
I've experienced games with varying amounts of input lag when VSync, so I'm sure the buffering implementation in the engine is key. But it's still a science that seems to elude most developers. I don't know if it's game developers or perhaps video card driver developers that are to blame.
I've seen in mentioned here and there, but how much of this is because of the rollback netcode? I know all of those have a frame delay setting.
(Good article)
If SF4 had 4-5 frames input delay without rollback netcode and they had to add the 2-3 frames because of it, would that be an explanation?
I would imagine they would then keep it like that for offline aswell, because the difference in timing would feel awful. The slow overheads in this game kind of fit that theory.
(Good article)
If SF4 had 4-5 frames input delay without rollback netcode and they had to add the 2-3 frames because of it, would that be an explanation?
I would imagine they would then keep it like that for offline aswell, because the difference in timing would feel awful. The slow overheads in this game kind of fit that theory.
.Reading this made me realize that Gsync players would also be considered "cheaters" by the logic that tries to justify the input lag.
Some of the very same people who are totally ok with saying "buy a new monitor if yours is laggy" are now calling people with the best possible monitors for that "cheaters". Just further reinforces how it's absolutely a game issue.
As I said before, if Capcom feels like the game should be played in such a way to allow people to get away with murder, they can tweak the framedata and keep that playstyle, even with lower vsync. Not being able to block or punish something because the game wasn't fast enough, and not you, doesn't make it feel like a different game, it just feels unresponsive. You don't have to adapt to a move now being safe, you have to adapt to not trusting your own ability, you know you can react to that, but you have to stop yourself from doing so. It's much better if the framedata just makes it impossible to react to, in that case you'll just naturally learn you can't react to that, instead of learning you can, and then having to teach yourself that you actually can't.
I remember Mike Z talking about his work as a game dev somewhere (can't provide you a link at the moment, since I don't remember exactly where it was), and he would mention that he would be the only person in the team that actually cared about that. No one would even bother to measure and try to fix the lag, he would bring his own camera and test it to see what could be done to make it better.
So I think it's more than likely the game devs.
I'm guessing that this is a by-product of V-Sync being on by default for Unreal Engine 4. I mean, Capcom could turn it off with a patch, but it could introduce a whole slew of other issues (such as screen-tearing).
At this point, it'd be best if Capcom waits until after the Capcom Cup to fix it, seeing as most people are getting used to the input lag by now.
At this point, it'd be best if Capcom waits until after the Capcom Cup to fix it, seeing as most people are getting used to the input lag by now.
With that I can agree with, but they should at least talk about it as soon as possible.
I've seen in mentioned here and there, but how much of this is because of the rollback netcode? I know all of those have a frame delay setting.
(Good article)
If SF4 had 4-5 frames input delay without rollback netcode and they had to add the 2-3 frames because of it, would that be an explanation?
I would imagine they would then keep it like that for offline aswell, because the difference in timing would feel awful. The slow overheads in this game kind of fit that theory.
That could be the case, but then it's a stupid decision all around. Rollback netcodes usually allow you to set a delay according to the connection. This forces a huge delay even on connections that don't really need that much, if anything, and still add rollback on top of that, when delay in rollback-based netcodes is used exactly to avoid the rollbacks.
Forcing it for offline play is also an incredibly stupid decision.
About overheads, as said before in the thread, I don't think it's consistent. Overheads are slow, sure, but dashes and throws aren't, they're really damn fast. Ryu's HK and tatsu framedata is also similar to SF IV, so they didn't compensate for the lag there, you can block it in one game but not the other.
Of course they tested their game, and took the input lag they had while testing into consideration, so it's possible they just thought it was fine to have those moves unblockable on reaction for this game, even though they weren't in the previous one, but that's still working against the theory that slow overheads are indication that they made everything slower to compensate for input lag and make it the same in the end.
Hmmm.
At first, before I watched the video, I was all like "Oh shaddap, ChrisG!" but this video was actually pretty interesting.
I was always just in the mind frame that "you just get used to the lag" when thinking about the higher lag of say... the PS3 version of SFIV and for whatever stick/monitor you were using (I mean, isn't this why tournaments let you know what monitors they'll be using? So you can use the same and get used to it?).
I never would've thought that input lag could be intentional as a game design decision.
At first, before I watched the video, I was all like "Oh shaddap, ChrisG!" but this video was actually pretty interesting.
I was always just in the mind frame that "you just get used to the lag" when thinking about the higher lag of say... the PS3 version of SFIV and for whatever stick/monitor you were using (I mean, isn't this why tournaments let you know what monitors they'll be using? So you can use the same and get used to it?).
I never would've thought that input lag could be intentional as a game design decision.
Interesting. Bookmarked to read a little later.
Another note about V-Sync on PC. It actually introduces a difference between online and offline play if this early test is correct.
Which is a bad thing, too.
Which is a bad thing, too.
You don't need that to measure physical input lag, why would you?
V-Sync introduces input lag. Across games, it isn't the same amount of lag but v-sync off is common settings for competitive csgo and other fps shooters.
The amount of lag introduced by v-sync might be able to be reduced, it seems higher than other games.
V-sync on is intentional, maybe no one cared or noticed the amount of lag it added or it was something that was changed last minute before shipping that wasn't tested thoroughly.
The amount of lag introduced by v-sync might be able to be reduced, it seems higher than other games.
V-sync on is intentional, maybe no one cared or noticed the amount of lag it added or it was something that was changed last minute before shipping that wasn't tested thoroughly.
SapientWolf
Trucker Sexologist
8 frames of input lag is unacceptable for a AAA fighting game, IMHO. Although more testing is warranted. I'd like to see the results at 144hz on a Gsync monitor. Sure doesn't feel like 8 to me on that setup.
sixteen-bit
Member
Was this posted regarding online play?
https://twitter.com/mauvecow/status/737776499583909888
https://twitter.com/mauvecow/status/737776499583909888
The Spoony Hou
Member
Of course it is. Sucks to be those with the inferior version, I guess.
Finally
https://twitter.com/teamspooky/status/743076357039497217
https://twitter.com/teamspooky/status/743076452078227461
The netplay stuff is just Spook'ys assumption though, it doesn't seem like Sugiyama actually said anything about netplay? Still seems like a safe bet.
https://twitter.com/teamspooky/status/743076357039497217
https://twitter.com/teamspooky/status/743076452078227461
Team Spooky ‏@teamspooky 2h2 hours ago
Sugiyama just stated on the @topangajapan stream that the 8f delay was an intentional design choice. My assumption here is they attempted
Sugiyama just stated on the @topangajapan stream that the 8f delay was an intentional design choice. My assumption here is they attempted
Team Spooky ‏@teamspooky 2h2 hours ago
To copy Bandai Namco and Tekken's innate buffer, which is meant to help smooth netplay.
To copy Bandai Namco and Tekken's innate buffer, which is meant to help smooth netplay.
The netplay stuff is just Spook'ys assumption though, it doesn't seem like Sugiyama actually said anything about netplay? Still seems like a safe bet.
Rabid Dwarf 76
Member
Really? Damn it Capcom.
yes. They are automatons designed to do one thing. Be gud at fighting games.