Jump to content
  • Advertisement
Sign in to follow this  
Omroth

Rendering at exactly 50hz

This topic is 2805 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

Hey guys.

I wish to render at exactly 50hz in my DirectX program. Using the Windows High Performance Timer I believe I have achieved this.

However, the output looks ever so *slightly* jerky. I have a bitmap moving straight accross the screen and it looks *just* off.

My question is - is there anything I'm missing here? Would there be a reason why the graphics card may not output this in a regular enough fashion to look smooth to the human eye?

Any help is much appreciated,
Thanks,
Ian

Share this post


Link to post
Share on other sites
Advertisement
What refresh rate is your monitor set to?
Most monitors use 60 Hz or a higher rate by default, which will give you some artifacts when rendering at a lower rate. In order to get perfect smoothness you must render at exactly the monitor refresh rate, and also present your scene exactly in between monitor refreshes. The best way is to select the most fitting monitor refresh rate and rely on VSync to render at exactly that speed, and the only way to get it perfect.

Share this post


Link to post
Share on other sites
Thanks Erik.

I have enabled vSync and switched to 60hz - it looks significantly better.

I still have a little hitch every couple of seconds, which I presume is because I'm not feeding quite enough frames, or maybe slightly too many.

What is the behavour of DirectX VSync if I send 62 or 58 frames when the monitor is refreshing at 60?

Share this post


Link to post
Share on other sites
If you have enabled VSync you should remove your own frame delay and draw as fast as possible. DirectX will automatically delay displaying the frames so they match the screen refresh perfectly (Present will block when necessary). For best performance make sure you can draw at least a few more frames than the refresh rate, so that there is never a time when a frame is missing at refresh time.

What DirectX version are you using?
In D3D9 you can use D3DPRESENT_INTERVAL_IMMEDIATE for the D3DPRESENT_PARAMETERS::PresentationInterval parameter in order to render as fast as possible, or D3DPRESENT_INTERVAL_ONE to draw with VSync. In D3D10/11 you specify the present interval when Presenting with your swap-chain.

Share this post


Link to post
Share on other sites
Thanks again Erik. I'm using DX9.

But if I render *really* fast, then surely DX will have to throw away frames - under what algorithm does it do this?

Share this post


Link to post
Share on other sites
No it doesn't throw away anything. Present will block when necessary, and act as your custom timer does now. So even if you draw at 1000 FPS with D3DPRESENT_INTERVAL_IMMEDIATE, it will stay at exactly 60 with D3DPRESENT_INTERVAL_ONE. Present has code to do the same delay you do yourself, just that it does it with VSync instead to get perfect sync to the refresh rate.

Share this post


Link to post
Share on other sites
What if I'm not calling Present? Or is that very unlikely.

It's important that I know which part of my renderer will actually block.

Share this post


Link to post
Share on other sites
Present will block, and without it you will not see anything on the screen. If you want to render images without displaying them, then vsync doesn't matter so then you can use your own timer.

Share this post


Link to post
Share on other sites
I've checked my render pipeline, and I do indeed call Present and *not* with the DO_NOT_WAIT flag.

But my results are that it is not blocking when I give it lots of frames - it just seems to overwrite.

Is it possible that it buffers several frames before blocking? My data looks like it might block only every third frame.

I'm running in windowed mode and Windows is set to 60hz.

(Thanks for the continued help)

Share this post


Link to post
Share on other sites
While mostly tangential, I'd like to point out that jerky movement could be caused by other things than an uneven refresh rate. For example, if the square was moving at 0.667 pixels per frame then every third frame it could appear to not move.

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!