Measuring Input Latency In Console Games 160
The Digital Foundry blog has an article about measuring an important but often nebulous aspect of console gameplay: input lag. Using a video camera and a custom input monitor made by console modder Ben Heck, and after calibrating for display lag, they tested a variety of games to an accuracy of one video frame in order to determine the latency between pressing a button and seeing its effect on the screen. Quoting:
"If a proven methodology can be put into place, games reviewers can better inform their readers, but more importantly developers can benefit in helping to eliminate unwanted lag from their code. ... It's fair to say that players today have become conditioned to what the truly hardcore PC gamers would consider to be almost unacceptably high levels of latency to the point where cloud gaming services such as OnLive and Gaikai rely heavily upon it. The average videogame runs at 30fps, and appears to have an average lag in the region of 133ms. On top of that is additional delay from the display itself, bringing the overall latency to around 166ms. Assuming that the most ultra-PC gaming set-up has a latency less than one third of that, this is good news for cloud gaming in that there's a good 80ms or so window for game video to be transmitted from client to server."
Re:DDR? (Score:5, Insightful)
DDR or any rhythm/timing based game will be perfectly fine with a fair amount of lag so long as the lag is consistent. The game isn't based much on reaction times, more hitting the pads at the right intervals. Once you get accustomed to the lag (which should happen naturally as you dance) the actual amount won't matter so much - you just have to move 160ms before the arrow hits the circle or whatever, something you will have been doing already, moving to land on the beat, rather than waiting for the beat and then moving. This differs from, say, a shooter like counter-strike, where you have to react as fast as possible to what is a non-rhythmic, supposedly non-predictable event (unless the opposing team comes out in synchronized swimming formation).
Inconsistency in lag would be a killer here, as it is everywhere, as it would be essentially adding a random component to your timing that you have no control over. But any time you do rhythmic work you're doing predictable lag compensation already - eg clapping on the beat requires you to start the motion before the beat happens rather than react to it.
Re:Reality check (Score:1, Insightful)
there are 2 different lags.
1. Something happens in screen, small lag, you press a key.
2. you press a key, small lag, something happens in screen.
Later one is very very detectable, while first one doesn't matter so much.
Re:DDR? (Score:4, Insightful)
I'm sorry, perhaps I'm misunderstanding you, but in the world of music 500 BPM is far from "low". Most "danceable" music generally is somewhere between 120 and 130 BPM, Drum-and-bass (which most people would consider quite fast) is about 170-180 BPM. Finding anything over 200 BPM is uncommon and usually for novelty sake. Perhaps the measurement you're talking about is something else than Beats Per Minute?
Re:Transfers to PC Game Ports too... (Score:3, Insightful)
1) Input is often sampled only once per frame. That is why quake at 120fps feels more responsive, the time between you pressing a button and the game noticing you pressed the button is reduced.
2) Input and actions are often determined on a per-frame basis. Meaning the fastest delay you can get is a single frame. Consoles tend to have games that run at a target frame rate (30, 24, 60) that determines how much visual flavor the game can have (60hz leaves less time to draw and update stuff than 30hz). So, at 30Hz, the fastest you can hope to see an action is 1 frame after the game detects it. That amounts to 33ms-66ms depending on your timing of the press in relation to the frame processing (we are asynchronous to the technology after all).
3) After a game renders a frame, it is usually buffered, so it has to swap and display the buffer. With V-Sync (consoles tend to v-sync automatically) that means it has to wait the 16ms for a 60Hz screen to refresh. But it only attempts to swap once a frame, introducing an aditional frames worth of delay in the display.
This is where the 99ms minimum response for a 30FPS game came from. 48ms for a 60FPS game.
Then you have to take into account that because of threading and networking, there are often more buffers in the game that only swap once a frame. This can introduce additional frames worth of delays as developers attempt to use the hardware to its limits.
Real reality check (Score:1, Insightful)
Ignoring the flamebait (only one good LCD? Really? I'm pretty happy with my Philips), I must say that as someone who has been a PC gamer most of his conscious life, I'm pretty impressed with what consoles had (and still have) to offer. When I was introduced to the Zeldas for the N64 there were so many things going through my head at once that I couldn't tell what the first impression was, but I'm pretty sure it wasn't "unplayable". Neither did I notice severe amounts of lag, but even if it's true that console games have more lag than PC games (and I think the article is making an unfair comparison by setting consoles, which are based off budget PC's nowadays, next to performance you can only get theoretically with a top of the line PC no one can afford) that doesn't necessarily mean that console games suck. There are more factors in the equation, not the least of which is new, fun, often somewhat original games that we haven't seen before yet. Katamari Damacy, Ridge Racer (actually arcade at first), Okami, Little Big Planet, or the legendary console RPGs from the SNES era, like Tales Of and Seiken Densetsu (among many many others), DDR, just to name a few. Rant on about latency all day long, but that doesn't change the fact that they're rock solid games and that PC game designers could learn something from them.
Multiple Mismtatched Stimuli (Score:3, Insightful)
Often the real problem players have isn't the latency itself, because our brains will accommodate almost any lag as long as it's uniform(witness the lack of "frames" for most movies, despite being (usually) at a mere 24fps). What causes the problem is actually when you have more than one set of stimuli that are going at different rates. This is most noticeable with audio and video not being in sync.
With an LCD display, this is magnified greatly unless you are going directly from the computer or machine to speakers with their own amplifier built in(or headphones).
Case in point - I like to play Rockband with my son. On a CRT, it was fine. On a LCD I had to set the audio lag to 0ms. THEN set the video to sync with that. Adding delay to the audio as well as the video made it impossible to get a decent result - one has to be set to zero.
eg: audio lag is tested at 20ms. Video lag is 35ms. The correct settings are 0 and 15, because the audio will always have that delay in it no matter what you do. Putting both at the recommended 20 and 35 yields a combined 55ms between your finger and the result. Though they are in sync, they feel "laggy" as our brains are used to video running at about 60fps continuous/30fps interlaced if we grew up in the era of CRT displays. So 55ms feels like we just dropped 3 frames versus one in this situation. And that's just about at the threshold of delay between what we hear and what we see where it starts to become annoying.
Note - it's also why you need a $20 dedicated sound card. Often games hammer the CPU and on-board audio chip set when a big group of sounds come in and that also causes lag in Direct-X games for a moment(which most all console ports are, exacerbating the issue).
Re:real test = ps3 vs xbox360 (Score:0, Insightful)
Reading TFA would have told you the reason why the PS3 wasn't tested at this time.
Idiot.
Re:Reality check (Score:5, Insightful)
The basic categories that set an elite gamer apart from an average or newbie gamer go something like this:
Predicting your opponent and being unpredictable yourself: Knowing where your opponent is going to be, and acting in a manner that your opponent can't predict. If you can put your crosshair where you know your enemy is going to be, and he can't do the same, you're going to win even if he has better raw reaction time than you. This is a function of experience with the game.
Decision making: Evaluating the importance of the various high-level goals in the game, deciding which ones to prioritize, and acting on that decision. Making better decisions, making them faster. Again, a function of experience with the game.
Aiming skill: If an enemy appears on your screen away from your crosshair, how quickly and accurately you can move your mouse to put the crosshair over him. This is a function of training, learning exactly how much mouse movement corresponds to how much movement on screen, and being able to precisely produce that movement with your hand. This is often confused for reaction time when watching people play, but really, the reaction time component is only in seeing the enemy and deciding to shoot him. The rest is muscle memory.
This is where input lag really hurts, it's very very important that your field of view appears to correspond to your mouse movements with absolutely no lag. Console games don't suffer from this because aiming with console controllers is far less precise than using a mouse, so the input lag "hides" behind the imprecision of the joystick. When the game meets the PC where people are using mice, the lag between moving your mouse and your on screen view changing becomes perceptible.
Movement skill: The ability to manipulate your controls to allow you to travel faster. Not just finding the most efficient routes, but being able to use quirks in the game's movement code to give yourself more velocity. Another function of training, getting the control inputs just right can be difficult to master.
Teamwork: In team-based games, communication, chemistry, planning, and effective group decision making.