Jump to content
  • Advertisement
Sign in to follow this  
ErikWise

OpenGL Strange SDL2 OpenGL stuttering on Windows(only)

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

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

 

 

Share this post


Link to post
Share on other sites
Advertisement

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/

Edited by wintertime

Share this post


Link to post
Share on other sites


Also look for calls to timeGetTime or other low resolution time measurement and make sure QueryPerformanceCounter is used.

 

He shouldn't use either of those, but use SDL_GetTicks (which uses QueryPerformanceCounter internally on Windows and something equivalent on .Linux) or SDL_GetPerformanceCounter instead.

 

However without any source there is no way to be sure if that is what's causing the problem.

Share this post


Link to post
Share on other sites

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:

std::chrono::high_resolution_clock

 

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.

Share this post


Link to post
Share on other sites
std::chrono defines three different clocks: steady_clock, system_clock and high_resolution_clock. If any you'd want to use the high_resolution_clock (which is required to have the shortest tick period). 
 
But you can't rely on any that. There is actually an unresolved bug about that:
 
 
TL;DR: Yes, the MinGW/MSYS chrono::high_resolution_clock implementation does indeed seem to be using the wrong clock when using libwinpthread. Try using chrono::steady_clock instead. 
 
However, I doubt the precision is bad enough to cause visible stutter. Have you tried using vsync instead of sleeping?

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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!

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!