Steady_Clock skipping between updates in main game loop

Question

In the process of trying to work out a solid game loop in SFML I came across this issue which I can't seem to figure out. I was able to strip out all of the SFML code and still see the issue with clock() in time.h. Then I went further and still see the problem using std::chrono::steady_clock.

The issue: Somewhat consistently I see skips in the amount of work able to be done between updates. Each update should take 1/60th of a second, and the rest of the time is spend in Draw() getting as much drawing done as possible. Sometimes the amount of draws drops to 0 or 1 for no obvious reason. This bubbles up to the actual application in the form of noticeable stuttering. Other than the "skips" the number of draws done is very consistent.

Here is an image (notice the jump in update time and drop in draws): Console output of the issue

Some code:

#include <iostream>
#include <time.h>
#include <chrono>

using namespace std;
using namespace std::chrono;

void Draw()
{
    //for (int i = 0; i < 1000000; i++);
}

int main()
{
    steady_clock::time_point update_time;
    steady_clock::time_point update_next;
    int update_rate = 16666666; // 60 times a second (nanosecs)
    int updates;
    int max_updates = 5;
    int draws = 0;
    update_next = steady_clock::now();

    while (true)
    {
        updates = 0;
        update_time = steady_clock::now();
        while (duration_cast<nanoseconds>(update_time - update_next) > nanoseconds(update_rate) && updates++ < max_updates)
        {
            if (draws <= 1) {
                cout << "!!!!!!!!!!!!!ERROR!!!!!!!!!!!!!" << endl;
            }
            cout << "UPDATE - ";
            cout << "Draws: " << draws 
                 << " - UT - UN: " << duration_cast<nanoseconds>(update_time - update_next).count()
                 << endl;

            draws = 0;
            update_next += nanoseconds(update_rate);
        }
        draws++;
        Draw();
    }

    return 0;
}

• Perhaps there is something I don't understand about typical applications? Does Windows need to hijack CPU cycles every so often?
• I have seen this problem with steady_clock, clock, and in a fleshed out SFML app where work is done during Update and Draw
• I assume SFML clock probably uses time.h clock
• From my testing the max_updates checks have nothing to do with this issue (I don't think they are causing the problem)

The fact that I have seen this with a few different timers leads me to believe there is something wrong with my implementation or my system. This example was run in VS but I have seen it also in a standalone release exe. Playing with the update rate or the amount of work done in draw may help it show up for you.

---

After testing out my background processes I noticed a strange correlation. This skipping issue only occurs when the Spotify web player is open in chrome and occurs once a second or so.

I found this post which may be related: https://community.spotify.com/t5/Other-Partners-Web-Player-etc/Web-Player-on-Chrome-causes-lag-stutter/td-p/4587103

Prima

Answer 1

Perhaps there is something I don't understand about typical applications? Does Windows need to hijack CPU cycles every so often?

Yes, absolutely. Windows is running a whole lot of processes all at once. Now your application comes along and executes what is essentially a busy spin-loop. At some point, the OS is likely to de-prioritize this for longer than you expect because it just looks like a long calculation, and the OS needs to give other processes a fair share of CPU time.

In general you should not rely on your drawing routine being called an exact number of times per second, and your game's master clock should be able to cope with skipped frames. I'm not familiar with SFML so I can't comment on that.

However, I do have experience with realtime audio (and video for that matter) running in loops that exceed 1000 updates per second. You can improve your game loop time share by setting the thread priority to THREAD_PRIORITY_HIGHEST or THREAD_PRIORITY_TIME_CRITICAL (see SetThreadPriority).

For this to be effective you should also be a well-behaved application and periodically perform some kind of wait. Waiting allows the OS to do its necessary task-switching to service other processes (several of which will also be a high priority, and often higher than you will be able to force as a userspace application).

The obvious place for a wait is prior to your next draw cycle. Rather than spinning on your timer with 100% core utilization, simply calculate how long you're prepared to wait and call std::this_thread::sleep_for. Remember that the only guarantee is the sleep will be for at least the amount you specify. It absolutely can and will be more than this. But I recommend you start there and do some experiments.

Carpetbag

How effective is std::this_thread::yield for this sort of thing? EDIT: i.e. is spinning while calling std:this_thread::yield an effective way of reducing the possibility of oversleeping – Nutbrown

I don't have personal experience using that for this kind of thing. I'd say it's more suited to things like spin-locks and very short-duration timing spins. I would definitely not want to run a 60Hz game loop with a spin-wait + yield, especially not if I'd also upped the thread priority. – Carpetbag

Right, so as you edited your comment, then yes that could be a performance tweak. Since the sleep_for can come out late, you can use a shorter sleep than you need, then use yield for tighter spin "sleeps" that pad out any undershooting. That's down to experimentation and black magic. – Carpetbag

I tried both of these, adding a thread sleep for as long as 10ms on each update, and still see the problem :( – Prima

Answer 2

In addition to @paddy's answer I recommend you look into fixed timesteps. If that isn't worth the trouble of implementing then you should also note that SFML has Window.setFramerateLimit(). It's not very precise but most simple games don't need significant precision.

Spathic

The fixed timesteps link is a good one, and what I used to come up with the code example. I also see the issue even when using SFMLs setFrameLimit. For some reason the clock is jumping a huge amount of time. – Prima

Well the FrameLimit only keeps your loop from running too often on a fast cpu. It doesn't stop the framerate from dropping. What are you running in your background anyway? Could you try on a different machine? – Spathic

Answer 3

I've used spinning loop plus yield for 1 KHz control loops with good results, but expect some deadline miss (once in thousands cycles also long sleeping times).

Denudation

Answer 4

It originally looked like the issue was caused by my antivirus, but I think I've actually narrowed it down to spotify web player being open and causing a performance spike 1/sec. I'm not sure why this would be.

Prima

Do you have the same issue if you use the Spotify desktop app instead? You could try doing performance profiling on your web browser to see what system calls might be responsible. Also try using the web app in different browsers, as it could be related to details in the browser implementation. – Carpetbag