Black Rock Studio's David Jefferies looks at the issue of lag in the wireless generation

Lagging behind the competition

Input 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.

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.

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.

About MCV Staff

Check Also

The shortlist for the 2024 MCV/DEVELOP Awards!

After carefully considering the many hundreds of nominations, we have a shortlist! Voting on the winners will begin soon, ahead of the awards ceremony on June 20th