Jump to content
  • Advertisement
Sign in to follow this  
Algotsson

Monitor problem on D3DXSprite movement

This topic is 4904 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. I have a little problem with my game that I'm creating with DirectX 8 and Visual Basic 6.0 (will upgrade to dotnet 2005 and DX9 as fast as I can). The thing is that my monitor seems to have problems following up my frame rate or something. I have tried to change every setting that I've been able to find (all the different Swapeffects and PresentationIntervals etc.). I'm wondering if there are any hidden settings that have not been covered by the basic tutorials. Or is it maybe a filter? Or is it due to VB's lack of performance? Though, I've heard that is should not be such a big problem. So, the problem occurs as fast as something starts to move. Because of an unknown reason the monitor doesn't clear the previous drawn pictures fast enough, and thus, this effect occurs: Example picture Note though that it is a more serious game, I will _not_ use that lame little character in my game. ;) Thanks. [EDIT]Oh, you can answer me in C++-terms or whatever. DirectX works almost the same as in VB.[/EDIT] [Edited by - Algotsson on March 17, 2005 10:34:46 AM]

Share this post


Link to post
Share on other sites
Advertisement
Do you think it can be solved by clearing the device in a different way, or by clearing it more often? I have a flat monitor which could be one of the reasons for why it happens. But it must be possible to correct it.

Do you think that it would be better to create the sprites manually, by using the DrawPrimitive directly? Or is it just a configuration issue. The PRESENT_INTERVAL_IMMEDIATE could maybe do something?

Share this post


Link to post
Share on other sites
I have not seen this effect in any other areas than in my demo. Except for a couple of tutorials that are on a basic level (they don't want to do it too advanced). C++ DX8-apps works very well, but I can't find what I'm doing wrong (it could eventually be vb's fault.
The effect is so big that I never could miss it.

My refresh-rate is 75 hz.

Share this post


Link to post
Share on other sites
Smear on LCD monitors is caused by the monitor's response time being longer than the refresh rate (assuming updates are occuring at or above the refresh rate). For example, a monitor with a response time of 16ms will start to smear at any refresh rate greater than 62.5Hz. So, it is possible that your smear is caused by having too high a refresh rate for the response time. Manufacturers generally specify a "native" refresh rate for LCD monitors. This is typically 60Hz. If you run your monitor at the native rate, you should get less smear.

Share this post


Link to post
Share on other sites
Yes, TFT has the same issues. TFT just allows for higher pixel density and, therefore, higher resolution. The response time is still the determining factor in the "smear campaign."

edit - It should also be mentioned that refresh rate for LCD monitors isn't as critical as it is for CRT's. This is also due to the response time issue. It doesn't do much good to refresh the screen more often than is necessary to keep the pixels lit. If the pixels can't turn on/off in less than 16ms, there is little point in refreshing more often than 60Hz.

Share this post


Link to post
Share on other sites
Thank you VERY much for your help!

Some of the smear is still there after I've changed the refresh-rate. Is there any way to compensate it with a good code?

Share this post


Link to post
Share on other sites
The only way to completely eliminate it is to update less frequently (e.g. limit the frame rate). If your monitor has a response time of 25ms, then a frame rate of 40fps would be the maximum it could handle. But, you would probably want to use something that was associated with your refresh rate, so 30fps might be better. (Assuming a 60Hz refresh).

Of course, since there is no way for your program to know the response time for a user's monitor it might be hard to justify limiting the frame rate. It would depend on how your game responds at that frame rate. If it runs well and looks good, then it doesn't matter. You could make it a configuration option, though.

I'm not saying this is the best idea, but it is the only way I know of to deal with this problem.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!