Shawn Hargreaves Blog
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?
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"...
Any idea on what is going on with the Super AMOLED panels (and FYI they are 24bit panels accoding to Samsung's mnufacturing specs)?
Interesting read, particularly the linked NTSC article - avoid fine vertical lines. Reminds me of when the local news guy decides to wear a pin-striped suit to work it creates all sorts of weird artifacts.
For my xboxing, the 2nd gen plasma is still tops. Long life display, < 300 watts operation, vivid colours, 20M:1 contrast and lightning quick refresh. For fast action the latest led backlight 240+hz lcd televisions are only now starting to catch up.
I wonder how many xna developers actually playtest on a CRT display before sending to market.
Wouldn't limiting the frame rate also help? This seems like one of those times where 120fps might not be desirable.
"Black to white takes a long time, while dark green to light green is much faster." - I thought the reverse was true; Black to white is fastest, while green to green was slower due to the inability of the LCD hardware to "overdrive" the subtler transition. Daniel Rutter talks about it here: www.dansdata.com/askdan00009.htm
Avoid bright red? How did they possibly make Mario?
> Avoid bright red? How did they possibly make Mario?
Mario is actually surprisingly far away from RGB (250,0,0), for exactly this reason...
Would be deeply uncool if the display started to shimmer and pieces of the image slide sideways any time the plumber came on screen :-)
> Wouldn't limiting the frame rate also help? This seems like one of those times where 120fps might not be desirable.
Definitely. Response time artifacts are most of a problem when you are presenting new radically different images significantly faster than the LCD can change to keep up. If you're a hardware designer you can try to fix this by making the LCD update faster, but if you're a software developer your only options are to make the images less radically different (by blurring, avoiding sharp contrast and single pixel details), or to present new ones less often (ie. lower your framerate).
It's the ratio between framerate and LCD response time that's the real problem. Even a 1 second LCD response time would be fine for a photo slideshow that only updates at one frame per minute!
is it possible to change the response time of any lcd panel if we were to just replce its internal organs or is the response time only associated with the lcd panel itself? please reply this is kind of a life and death situation. well not really
luis: I'm not aware of any LCD hardware that has user servicable or upgradable parts. An LCD pretty much is what it is. If you want better performance, you need a better LCD...
We have customers that require the faster response time and have no need for color. We suggest the old TN technology. It is not as nice looking as a HD color display, but if all they need are numbers or letters, TN works great.