Jump to content
  • Advertisement
Sign in to follow this  
DarkRonin

Best way to do a timer (for a render loop)

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

My biggest problem is that my card renders very basic scenes anywhere up to 8000 frames per second.

So, GetTickCount is useless as it can only report back >10ms differences.

And I have read that QueryPerformanceCounter has issues with newer AMD CPU's (something to do with energy efficiency in the architecture).

What is the best way to calculate time between frames?

Share this post


Link to post
Share on other sites
Advertisement
Well QPC is what i have always used but if you want to get controlled framerate of say 60 you can get away with using GetTickCount(). You basically work out the length of time it has taken to do the work you've set out in your frame and then sleep for the rest of the 16ms (in the case of 60fps).

Share this post


Link to post
Share on other sites
I have just gone with QueryPerformanceCounter(). I have read that if you set the thread affinity for the counter this will stop the AMD's jumping cores and skewing results.

Share this post


Link to post
Share on other sites
You could use timeGetTime, making sure to call timeBeginPeriod (1) at startup (and timeEndPeriod (1) during shutdown) - that will give you 1 ms resolution.

Share this post


Link to post
Share on other sites
Unfortunately, 1ms isn't quick enough.

At the current 8000 FPS (on a 2 year old GFX card) each frame has an in-between delay of 125 ns.

The current fastest GPU is about 30% faster than what I have. So, you are looking at a delay in the order of 90 ns.

By the time I develop something worthy of releasing, who knows what sort of timer resolution I'll need.

Share this post


Link to post
Share on other sites
Why do you care, honestly? 8000 FPS is overkill, and you should not put requirements on the resolution of your timer based on an 8000 FPS rate. In fact, not only is it unnecessary to plan around an 8000 rate, it's irresponsible. You're hammering the graphics card as fast as you can, rendering frames that are completely and totally redundant. Take pity on that poor card, and throttle that frame rate. Nobody plans around 8000 FPS. No human could possibly perceive a visual difference at even an eighth of that framerate. To impose technical requirements upon yourself (and rather hefty ones, at that, since uber-precise timing is tricky) based upon something that is going to make exactly 0 difference to the end user translates to a greivous waste of time and resources better spent elsewhere.

Share this post


Link to post
Share on other sites
Your best way is to use QuerryPerformanceCounter as that will give you the time to an accurracy of the CPU ticks per second. However on multicore CPU's you need to bind the function to a thread you are calling it on as it is possible that this function will otherwise be handled by another other core. In multicore CPU's the cores aren't running at exactly the same frequency, especially when turbo boost comes into play. To fix this you set the thread affinity for QuerryPerformanceCounter as outlined in the remakrs on the MSDN article, http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx.

Share this post


Link to post
Share on other sites

Unfortunately, 1ms isn't quick enough.

At the current 8000 FPS (on a 2 year old GFX card) each frame has an in-between delay of 125 ns.

The current fastest GPU is about 30% faster than what I have. So, you are looking at a delay in the order of 90 ns.

By the time I develop something worthy of releasing, who knows what sort of timer resolution I'll need.


Decouple the logic from the rendering and it won't matter, run the updates at a fixed rate, (say 100 times per second) and render as fast as you can, the timer only has to be accurate for the updates so the speed of the GPU is irrelevant. (Most monitors display between 60 and 200 frames per second)

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!