Hey GameDev!

For some time now, my brother and I have been working on a game in C++ using SDL2 and OpenGL 2.1 (which is widely supported with both the Linux and Windows OS). We started porting our game to Windows recently (usually we work on Linux), and right from the start using a simple example we experienced a strange stuttering. We are using Mingw to do so and use the libwinpthread library, which resemples the Linux threads best.

I use the word strange because it stutters when starting the application with nothing running in the background. However when we start the application with a graphics application in the background: for instance a movie played by VLC , or youtube, the application works flawless! We have searched the internet for possible fixes, but most are not applicable to our problem, because it is a rather specific behavior.. We have however tried to change the priority of the app to real-time, but without success.

The simple testapp can be found in the attachment of this post, so if you'd like you can test it for yourselves. We really hope that someone with better understanding of graphics in Windows can help us solving this mystery!

Have a great day!

Erik

The Netherlands

I did not download your file, but from the description it sounds like you are using some functions which depend on the Windows timer interval and those other apps you run are changing this global setting (which should be avoided). You might want to go through your code and change it to not use tiny sleeps below 16ms, replacing them with waits on synchronization primitives where necessary. Also look for calls to timeGetTime or other low resolution time measurement and make sure QueryPerformanceCounter is used.

https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

Thanks for the responses!

We are indeed using sleep commands < 16ms, the render thread at this moment sleeps for 1ms. For the clock we are using:

You might want to go through your code and change it to not use tiny sleeps below 16ms, replacing them with waits on synchronization primitives where necessary.

>> We are not aware of synchronization primitives, are these an alternative to sleeping a thread < 16ms? If so we would be interested because our code is at the moment relying on sleeping shorter amount of time.

He shouldn't use either of those, but use SDL_GetTicks

>> Could it be the case that the std::chrono uses the wrong Windows clock? If so this could improve our situation already.

We are not aware of synchronization primitives, are these an alternative to sleeping a thread < 16ms? If so we would be interested because our code is at the moment relying on sleeping shorter amount of time.

Try removing the sleep and see if it improves.

If suddenly everything moves too fast or you get other glitches, read this: http://gafferongames.com/game-physics/fix-your-timestep/

After that, activate vsync and check again.

Thanks wintertime and kolrabi for all the information and help,

We are now fully aware that our problem is indeed a Windows drawback with a default minimum sleep time of 15.6 ms (while Linux defaults to 1ms). There are multiple fixes to our problem as we are aware of now, we have to think this over because we are depending on separate render and update threads within our engine. One option would be to merge both threads into one and wait for vsync.

Have a great day!