Regardless of whether you are developing for PC, Xbox 360, or Windows Phone, your game will most likely be viewed on some kind of LCD screen. An important characteristic of LCD technology is the response time, which measures how long pixels take to change color from black to white and then back to black again. Depending on the display this may be anywhere from 8 milliseconds up to 30 or more, but it is inherent to how LCDs work that the change can never be truly instant. Poor response time affects game graphics in two main ways:
It can make moving objects appear to be blurred, as the display has not yet fully faded out the previous position of the object. We sometimes choose to implement motion blur as a deliberate special effect, but it is not usually so desirable to have it applied indiscriminately to all our graphics!
More surprisingly, LCDs can make moving objects appear faded out, dimmer than usual. Consider a starfield, which consists of single white pixels on a black background. When stationary, we have many black pixels, plus a few white ones. But what happens when we scroll the stars? The pixels that were white start fading out toward black, while new pixels that were black start fading in toward white. But if we are scrolling faster than the LCD response time, we will move again before the LCD has finished its transition. The black pixels that were fading toward white have only reached a mid shade of grey, but must now fade back out toward black, while new black pixels start to fade in. As long as we keep moving, no pixel ever has a chance to become brighter than mid grey, so the stars appear dimmer than they ought. The only way we can ever see a bright white star is if we stop moving long enough for a pixel to fade all the way in.
If you suffer from blurring or dimming but are not sure whether this is due to LCD response time or a bug in your code, capture a screenshot while the problem is occurring (using the PrtScn key on Windows, or XNA Device Center for Xbox). If the problem is not visible in the static screenshot, it must be caused by slow LCD response.
Unfortunately there isn’t much you can do to fix such problems, other than just changing your game artwork to make them less objectionable. It is important to understand that the response time varies depending on how far the color must change. Black to white takes a long time, while dark green to light green is much faster. This means response time blurring is often a big problem in simple tests, where people do things like moving a bright yellow rectangle over a black background. The problem will often go away when these test graphics are replaced by proper sprites and backgrounds that have less extreme contrast.
The worst case for LCD response artifacts is single pixels with high contrast, so a retro style starfield is pretty much as bad as it gets. How might we change these graphics to reduce the artifacts?
- We could reduce the contrast, perhaps using light blue stars over a dark blue plasma / nebula background image
- We could make the stars larger than a single pixel, drawing a soft edged glow around each one
- We could embrace the blurring, deliberately adding our own bloom and motion blur effects to cover up the hardware issues (do your worst, oh crappy LCD! I see your artifacts, double or nothing, and if anyone asks will insist I wanted it to look like this all along 🙂
On the bright side, the quirks of modern LCD hardware are nowhere near as bad as the days of NTSC television, when skilled game developers had to worry about things like "avoid bright red" and "don’t use thin horizontal lines"…