INDUSTRY ANALYSIS SPONSORED BY
OPINION | ALPHA
COMMENT: CODING
Lagging behind the competition by David Jefferies, Black Rock Studio
I
nput lag used to be a big deal in games. For a game like Street Fighter, it was imperative that it ran at 60 frames per second and processed the inputs from the gamer as quickly as possible. It felt fast, responsive and fair. A game running at 60fps processes a single frame in 16 milliseconds, and so the resulting action from your input would be on screen within 32ms. That’s fast. In this era of wireless controllers, LCD panels and lots of 30fps games I thought it would be interesting to trace the lag that we see in our games today. ESSEX LAGS I’m going to define lag as the time it takes between a button touching its contact points on the gamepad to the resulting action being seen on screen. I’m going to assume a typical setup of a modern console such as an Xbox 360, PS3 or Wii with a wireless control pad connected to an LCD display. When the button is pressed, the wireless gamepad packages up the state of the pad and encodes for sending. It doesn’t continuously broadcast; instead it sends bursts of data at short intervals in order to conserve battery power. The console receives and decodes the wireless packet and presents it to the game code for processing. The console manufactures claim this process takes between 10ms and 14ms. I’ll take the average of 12ms for this article. The first thing your game loop should do is read the pad inputs. If your game is running at 30fps then the game will spend the next 32ms updating the game state and building a command buffer ready to be rendered by the GPU. Remember, the gamepad packet could have arrived after the game loop has started processing and so will have to wait until the next loop begins which will impose a further delay of up to 32ms. Next, the GPU will consume the command buffer and will take another 32ms to render the frame. When the GPU has finished and the framebuffer is presented to the drivers for display the elapsed time from pushing the button is about 76ms in the best case. In the worst case where the wireless packet arrives just after the processing has started, the time is 108ms. If your game is running at 60fps then these figures are 44ms and 60ms respectively.
DEVELOP-ONLINE.NET
Now the framebuffer is ready to be displayed. If your display device is a CRT then that’s the end of the story, because a CRT is a streaming device and will start to display the image immediately. LCD-REAM LCDs, however, do additional processing before displaying the image. Manufacturers like to measure the lag of their LCDs using pixel response times, which is the amount of time it takes a pixel to change to the required colour. However, this isn’t the whole story: we are also interested in the lag introduced by the processing that happens before the LCD is ready to display the image. This lag is called circuit delay, and the total lag of an LCD is the circuit delay time added to the pixel response time.
Amateur tests show that, astonishingly, LCDs have a lag of between 30ms and 80ms, with the average being around 40ms. None of the major LCD manufacturers publish their circuit delay times, and it’s become apparent to industry observers that the processing they perform in order to decrease pixel response times has significantly increased circuit delay time. In the absence of manufacturer specifications, there has been amateur research into circuit delay times. These amateur tests show that, astonishingly, LCDs have a lag of between 30ms and 80ms with the average being around 40ms. Combine this average with the wireless lag and inherent lag of the game, and a 30fps game will have a lag of up to 150ms with a 60fps game fairing a bit better at 100ms. Compare this to a classic arcade game with a 32ms lag and it’s up to five times worse. So games are significantly less responsive than they used to be, but is this really a problem? Well, yes: the extreme lag that
we’re talking about here will definitely make the controls seem more sluggish than they should be. It would make one of the original fighting games like Street Fighter virtually unplayable, because these games require responses within such tight windows of opportunity that adding all this additional latency would simply make it too difficult. But the good news is that LCD manufacturers are starting to wake up to this issue, and some specialists are including a ‘through’ mode where the LCD does no processing and so the input lag is reduced to almost nothing. Let’s hope the big brands catch up soon.
Wireless controllers, such as these microphones, have introduced another layer of lag – but it’s LCDs that are slowing modern response times
David Jefferies started in the industry at Psygnosis in Liverpool in 1995, eventually working on Global Domination and WipEout 3. He later moved to Rare where he worked on the Perfect Dark and Donkey Kong franchises. Next came a move down to Brighton to join Black Rock Studio (which was then known as Climax Racing) in 2003. On this generation of consoles he’s been the technical director of MotoGP’06 and MotoGP’07 before starting work on new racer Split/Second.
www.blackrockstudio.com JULY 2009 | 21