Bdtyktl

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

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.

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.

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).

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.