29
\$\begingroup\$

Is it safe to use Sleep() function on Windows in game loop (C++)? I want to have fixed frame rate.

\$\endgroup\$
1
  • \$\begingroup\$ You need to clarify, what do you mean by "safe". Of course it's safe and is not going to corrupt memory or blow up players PC. \$\endgroup\$
    – Kromster
    Jun 1, 2016 at 4:23

2 Answers 2

33
\$\begingroup\$

No, it's not. Sleep only guarantees a minimum time to sleep for, but it may actually sleep for any arbitrary amount of time over that. Your timer resolution (set via timeBeginPeriod) is also important for it, and even if you're using something else (like QueryPerformanceCounter) for your timer, you still need timeBeginPeriod to control Sleep.

So in summary:

  • Time to sleep for is only a guaranteed minimum and actual sleep time may be higher.
  • Sensitive to value set (or not set) via timeBeginPeriod.

The only reasonable case for using Sleep would be if you wanted to reduce CPU usage for e.g. mobile devices. Even then you'd be using Sleep (1); using it to control framerates is not the way to go.

Forcing vsync on is probably one common way to get a fixed framerate, but even then, different hardware will run at different refresh rates and you won't be able to have a consistent fixed framerate across different machines (this depends on what kind of hardware you're targetting of course).

At this point in time it's necessary to mention this article: Gaffer On Games - Fix Your Timestep!. That describes the steps you need to get a consistent timestep in your simulation.

\$\endgroup\$
5
  • \$\begingroup\$ Enormous thanks for the link. Until now, I usually used the "variable timestep" approach described in the article. \$\endgroup\$ Oct 23, 2011 at 16:55
  • \$\begingroup\$ Sleep is also dangerous on machines that have Intel speed-step enabled. \$\endgroup\$ Oct 23, 2011 at 17:52
  • \$\begingroup\$ "but it may actually sleep for any arbitrary amount of time over that." Well, that has to be proven I guess... Never ever seen any proof of it so I guess it is one of those 'definitions'. Good answer though and yeah, you can't (even if it was, as it is, accurate) use any kind of Sleep to set a fixed framerate (well you can but you need a high precision timer to do it). \$\endgroup\$
    – Valmond
    Oct 23, 2011 at 18:51
  • 2
    \$\begingroup\$ Per MSDN - "Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses". True, I've never seen it happen, but at the same time if it's documented as being possible I definitely wouldn't rely on it never happening. \$\endgroup\$ Oct 23, 2011 at 19:36
  • 1
    \$\begingroup\$ Worth mentioning, I think this would relate to "...if you wanted to reduce CPU usage...": nanobit.net/doxy/quake3/win__main_8c-source.html <-- relevant code begins at 01224 \$\endgroup\$ Oct 23, 2011 at 22:09
16
\$\begingroup\$

Short answer: no, it is not.

To have a fixed frame rate you have to call a certain callback function that forces a specific frame rate. Obviously, if you don't now how long a single iteration in a loop will take you cannot set a fix sleep time.

GLUT provides glutTimerFunc(), which is, if you are programming in OpenGL, the right function you need. Take a look at this example, or this one.

\$\endgroup\$
1
  • 3
    \$\begingroup\$ "After at least msec milliseconds, OpenGLUT will call callback" - how is that different from Sleep? \$\endgroup\$
    – Kromster
    Jun 1, 2016 at 4:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .