Blurry trail on sprite movement

Hi all,

I read some posts about problems with AMD processors. I am not sure my issue is caused by that because I have a different processor from the ones I read the posts about.

The issue:

I have a simple ball sprite. I create a pong-like game. When the ball moves it produces a blurry trail behind it. Like you have with comets in space. The faster the sprite moves, the longer and more noticable the trail.

In response to this I have updated the drivers for my processor and grapics card.

The result is the same.

Beside the blurry trail I notice the movement is always a littlebit choppy. Not extreme, but I think it ought to be somewhat smoother than this.

So no I am wondering what might be causing it. Can it be the processor or the graphics card. Or maybee it is the monitor On LCD tv's I've seen the same effect watching a soccer game.

My configuration:

AMD Sempron 2800+ / 1,61 Ghz / 512 MB

Geforce 6800 Xtreem

Philips SL120 LCD monitor

Thanks,

Ton

It does sound like the monitor may be at fault.

My system (AMD 4800+ with a Samsung 8ms lcd display) display no ghosting / blurring at all with fast moving sprites through XNA. The symtoms you describe to sound typical of the slower lcd displays (although I've no idea what refresh rate your lcd runs at).

iainbyoung wrote:

The symtoms you describe to sound typical of the slower lcd displays (although I've no idea what refresh rate your lcd runs at).

Sorry, I meant response time, not refresh rate. Obviously I haven't had enough coffee this morning yet :D

It is an older TFT monitor. That is right.

What response time is (approximate) the minimum for moving sprites without such site effects

Is 12 ms suitable, or should it be faster

I know "the faster the better", so that answer can already be skipped :)

If you tell me what is the method used to determinate these 12 ms i could be able to answer. There are some tricks by manufacturers to declare low timings.
What does "a response time" means in reality In terms of the ISO 13406-2 standard it is a sum of two (i have simplified a bit):
1) time elapsed since the pixel is on electrically and its luminance is getting from 10% -> up to 90%
2) time elapsed since the pixel is off electrically and its luminance is getting from 90% -> down to 10%

Unfortunately, the standard does not set the common methods what and how to do. The timings are quite different for swithcing on and off, for black and white or halftone fields. It's the wide range for a marketing department to interpretate the timings.
Quite often the response time is shown with the remark "from gray to gray" but a gray color really is any color between black and white. To have a compatible result you'd visit some expert site used the consistent comparative measurements for all the marketed LCDs, f.e. http://www.tomshardware.com/graphics/displays/index.html.

As to your question once more - if the 12 ms is referenced in the LS120 docs it is not true. If 12 ms means the response time of a modern LCD (not older than one year) you want to buy, it sounds like true and may be accepted. But you'd always try before buy!

It's pretty simple to figure out. At 60Hz refresh rate you need at least 1000/60 ms response time (16.6667). At 75Hz refresh rate you need at least 1000/75 ms response time (13.3333). Basically, your response time has to be the same or less than the time for one frame of refresh.

 (But as neogir pointed out, your mileage may vary.)