Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: stuttering on some hardware, not others  (Read 12360 times)

0 Members and 1 Guest are viewing this topic.

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
stuttering on some hardware, not others
« on: October 02, 2014, 09:23:51 am »
Hi,

I have noticed my SFML game experiences stuttering or frame loss on some graphics cards, but not others.

Here's a video which shows the problem.  Although the video compression makes it appear worse than it actually is.  In the non-compressed avi captured using FRAPS (264mb download here), the motion is smooth except when the stuttering occurs.

I noticed the stuttering on my laptop, which has 2 graphics cards:
1.  Intel HD Graphics 4600 (integrated)
2.  NVIDIA GeForce GT 750M

Interestingly, the stuttering occurs only on the more powerful GeForce, but not on the Intel.

I also tested the game on my desktop, which has an AMD Radeon 7700 card.  The game runs perfectly smooth there.  So:
  • NVidia (Win8.1 laptop):  Significant stuttering.  Other (non OpenGL) games run fine on this card.
  • Intel (Win8.1 laptop):  No stuttering
  • AMD (Win7 desktop):  No stuttering

The game was tested in fullscreen, with vsync on.  All drivers are updated.  I am using a SFML 2.1 stable release which I would have downloaded probably >6months ago.

Given the different behaviour on different cards, maybe it is an NVidia OpenGL driver problem.

Questions:
1.  Has anyone else experienced this kind of issue with SFML?
2.  Is NVidia known to have crappy OpenGL drivers?
3.  Have there been any recent changes to SFML that might address this issue?
4.  It appears to be an OpenGL-specific problem.  Is it possible it is because SFML uses old/legacy OpenGL?
5.  Any ideas on how to fix it?

My biggest concern is that this problem will affect all, or even a significant portion of NVidia users.  I really like SFML, and have already written a lot of code around it.  But *if* the problem is OpenGL specific, and there is no work around, I may have to consider migrating to DirectX-based graphics middleware.  Unless maybe SFML plans to support a DirectX back-end. 

Thank you very much for your time and help.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: stuttering on some hardware, not others
« Reply #1 on: October 02, 2014, 12:48:29 pm »
After analysing the uncompressed video frame by frame, I have come to the conclusion that frames aren't being dropped. A frame just happens not to be synchronized, and delayed to the point it gets swapped right before the next one does, leading to the appearance that a frame has been skipped. It is also very uncommon for GPUs to simply drop frames when not under extreme loads.

It might sound strange at first, but this might be indirectly caused because your Nvidia GPU is simply too fast compared to the other cards. You see... with vertical synchronization enabled and fullscreen, you are asking your GPU to try its best to make sure a new frame can always be presented at the verticial synchronization signal. If your application is producing too many frames, the driver throttles it by blocking the buffer swap, if it is producing too few... it often just doesn't swap at all, leaving the previous contents in the front buffer.

Now consider, what I just said with having too many or too little frames works out nicely if you produce around a multiple or fraction the amount of frames compared to the vsync rate. What if you produce something in between, that doesn't fit so nicely? Where does the driver draw the line and say "sorry frame... you are a bit too late" or "sorry frame... you will have to wait for the next refresh"? This is very driver and hardware dependent, but it might also depend a bit on your code.

Stuttering is often naively attributed solely to the GPU or the OS, because of vsync and the frame limiter. What people seem to forget, is that vsync and the frame limiter do not guarantee a constant framerate. They are just hints or basically "nice to haves" that the responsible system is to give their best effort to fulfil. If you write code that depends on having a constant framerate, sorry to be the bearer of bad news, but it simply won't work. You haven't posted any code whatsoever, so based on what I've seen on this forum recently and in the past, I cannot exclude this possibility. If you have thought of this already, then you can ignore what I just said, but showing a bit of code would still be helpful.

I am using a SFML 2.1 stable release which I would have downloaded probably >6months ago.
Not only was it downloaded > 6 months ago, it is almost 1.5 years old, and many fixes behind the current master.

Given the different behaviour on different cards, maybe it is an NVidia OpenGL driver problem.
Perhaps... but drivers have gotten better and better over the years, and I think such a prominent "issue" would have been fixed long ago, since this would have affected any OpenGL application. Nvidia is also known for their efforts in supporting the latest OpenGL specifications, so I can't really say that they don't give enough effort in regards to OpenGL support.

Has anyone else experienced this kind of issue with SFML?
Like I said above, if the code makes that wrong assumption, then yes, people have experienced this issue, even on AMD and Intel cards. If you want people to be able to test on their own systems, you will have to provide code or a binary at least.

Is NVidia known to have crappy OpenGL drivers?
Crappy is always relative. Compared to AMD, probably not. They seem to fix glaring OpenGL issues faster than AMD does from what I've heard. Since drivers are also tied closely to the operating system, we can't rule that out as the cause. It might very well be that the proprietary Nvidia drivers perform better running your application from inside Linux than in Windows.

Have there been any recent changes to SFML that might address this issue?
Like I said above, the SFML you are using is more than 1.5 years old. I think it is safe to say that there have been a large number of fixes for various issues. How many of them might have an effect on this issue? I cannot say...

It appears to be an OpenGL-specific problem.  Is it possible it is because SFML uses old/legacy OpenGL?
How and why do you come to this conclusion? If you assume that because some other graphics library does not display this same behaviour, then that is merely a necessary condition to state that it is OpenGL specific, but not a sufficient one. Take into account that the code for both tests cannot be identical as well, and you have too many factors to be able to draw a reasonable conclusion.

It is true that SFML uses legacy OpenGL code, but I don't know where you got the misinformed idea from, but it does not have any impact on whether stuttering might occur or not. Legacy OpenGL was deprecated because it was a bottleneck, not because there were more serious problems that led Khronos to run away from it. In fact, it is still supported by vendors as much as non-legacy OpenGL is, due to the simple fact that industrial CAD applications might still depend on it to function.

Any ideas on how to fix it?
Knowing what the actual problem is comes before trying to find a fix for it...

My biggest concern is that this problem will affect all, or even a significant portion of NVidia users.
You haven't even ruled out that it might not happen on certain AMD or even Intel cards. Again... necessary condition.

But *if* the problem is OpenGL specific, and there is no work around, I may have to consider migrating to DirectX-based graphics middleware.  Unless maybe SFML plans to support a DirectX back-end.
I really do not understand what is it with those that flock to DirectX as soon as something doesn't work as expected with non-DirectX software. Do you ever hear of people saying "DirectX doesn't do this right... I'm going to use OpenGL now."? Not even close to as much as the opposite. This can probably be considered a lesser manifestation of shotgun debugging, and Microsoft is obviously happy that many misinformed people still think like that. Before transitioning to another library, or even different code using the same library, understand what the problem is and why the change might make a difference. Simply saying "I don't know how that fixed it, but all I care about is that it seems to be fixed." isn't considered good software development practice, and often is the result of badly trained or lazy developers.

I can't speak for every game developer out there who currently uses DirectX, but if any of them truly believe the marketing material that Microsoft has put out over the years about DirectX which has been debunked time and again from objective observers, then I can only hope that they will one day wake up and realize that OpenGL is just as worthy of a graphics library as Direct3D is. Whoever still believes that Direct3D 12 is "more powerful" than OpenGL 4.5 doesn't seem to know enough about OpenGL 4.5 if you ask me. They are equally powerful, and can produce the exact same results, since operations in Direct3D and OpenGL get translated into the exact same instructions on the GPU anyway. Contrary to what naive laypeople might think, there are no "special Direct3D 12 hardware units" on the GPU that only Direct3D has access to. And in the recent years, GPGPUs have become so universal, that there isn't really much else one can add in terms of "specialized functionality". What you could only do in a software renderer decades ago you can do using dedicated hardware now. Every new iteration of Direct3D and OpenGL is thus focusing primarily on performance improvements. But of course, Microsoft likes to show their customers pretty pictures of what they claim is only possible using the latest API on the exact same hardware.

Please, don't be one of these people. I still have hope that you can rise above that.

And before more people ask. No, Direct3D support in SFML will not be coming before SFML 3. Even if we decide that it is doable, I am certainly not going to invest my unpaid time promoting a graphics library that has done nothing but mislead and stab people in the back time and again. When it comes to open source development, I am strongly driven by my morals, and Microsoft has violated them in too many ways already.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: stuttering on some hardware, not others
« Reply #2 on: October 02, 2014, 10:54:51 pm »
After analysing the uncompressed video frame by frame

I really appreciate your thoughts and effort on this binary1248.  Super cool of you.

Let me give an update before I respond to the rest of your post.  If I turn off "Threaded optimization" in the NVidia Control Panel, the problem seems to disappear.  I'll talk more about this in a separate post following this lengthy one.

I have come to the conclusion that frames aren't being dropped. A frame just happens not to be synchronized, and delayed to the point it gets swapped right before the next one does, leading to the appearance that a frame has been skipped.

So this would have the effect of displaying the same frame twice, correct? 

Now consider, what I just said with having too many or too little frames works out nicely if you produce around a multiple or fraction the amount of frames compared to the vsync rate. What if you produce something in between, that doesn't fit so nicely?

With vsync off, the game runs at ~450 fps.  So this doesn't appear to be the case.  Apologies for not providing this info in the original post, but I did a lot of testing and wasn't sure what info would be relevant or not.

If you write code that depends on having a constant framerate, sorry to be the bearer of bad news, but it simply won't work. You haven't posted any code whatsoever, so based on what I've seen on this forum recently and in the past, I cannot exclude this possibility. If you have thought of this already, then you can ignore what I just said, but showing a bit of code would still be helpful.

I totally understand you bringing this up.  My code is not dependent on a constant framerate. 

Not only was it downloaded > 6 months ago, it is almost 1.5 years old, and many fixes behind the current master.

Ok, I'll grab latest.

Perhaps... but drivers have gotten better and better over the years, and I think such a prominent "issue" would have been fixed long ago, since this would have affected any OpenGL application.

Interestingly, stuttering problems with threaded optimization (both on OpenGL and DirectX apps) seem to be pretty common.  I'll link some stuff in my next post.

It is true that SFML uses legacy OpenGL code, but I don't know where you got the misinformed idea from, but it does not have any impact on whether stuttering might occur or not.

Let me justify my thoughts.  I am doing so because I recognize your much greater expertise in SFML/OpenGL, and find the opportunity to discuss this with you highly educational.

I was trying to identify differences between my SFML-based game and other games which operate properly on the NVidia card.  (Legacy) OpenGL is one of those differences. 

In researching the "threaded optimization" NVidia option, I came across many cases where specific driver instances led to stuttering.  These were often fixed in subsequent driver updates. 

I don't know to what extent legacy OpenGL driver code diverges from current OpenGL driver code.  But, as you discussed, deprecated code is generally marked as such because either 1.) it will cease to be maintained, and/or 2.) it is a sub-optimal way of doing things.  In either case, it likely receives less driver support, as more programs migrate to the modern recommended API. 

For example, there was a certain NVidia driver in mid 2012 where "threaded optimization" was blatantly broken and caused widespread stuttering.  It is conceivable that these types of driver problems may linger longer in deprecated OpenGL.  Again, this is just a hypothesis.

You haven't even ruled out that it might not happen on certain AMD or even Intel cards. Again... necessary condition.
Absolutely true.
I was just making some guesses based on the known information so far.  Testing the game on a wider range of hardware will certainly add clarity to the issue.

This can probably be considered a lesser manifestation of shotgun debugging, and Microsoft is obviously happy that many misinformed people still think like that. Before transitioning to another library, or even different code using the same library, understand what the problem is and why the change might make a difference. Simply saying "I don't know how that fixed it, but all I care about is that it seems to be fixed." isn't considered good software development practice, and often is the result of badly trained or lazy developers.

Well, I consider myself neither badly trained or lazy.  :P

There is likely a very different mindset between an indie game developer and an open source library dev such as yourself.  I need to be lazy in the sense that the path of least resistance is a crucial factor in my engineering decisions.  Otherwise, I simply would not finish my projects, or else spend too much time on low level engineering issues at the expense of coding and polishing gameplay.  Now, the path of least resistance is not the only consideration.  If it were, I would likely be using something like Unity3D rather than building a game engine around SFML.  I choose SFML because I dislike working in a "scripted sandbox" such as Unity, and much prefer to have access to all the source code in my project.

Given infinite time, I could absolutely understand what the problem is and why the change might make a difference.  But I don't have infinite time, so I must set boundaries before resorting to "shotgun programming".  Given the evidence so far (works on ATI on different machine, works on intel card of same machine, does not work on NVidia, other DirectX games do work on NVidia), NVidia OpenGL driver issues are an obvious candidate for consideration.  *If* (and I stress if, as I did in my original post) SFML/OpenGL/driver issues repeatedly plagued the project, and the solution to these issues lay in closed source NVidia driver code, or low level SFML/OpenGL code (which is beyond my current expertise to fix), switching would be a reasonable consideration.  But that is just one potential outcome of many.  And please do not interpret this as a criticism of SFML code, which I find to be excellent code to work with.

Hopefully that provides some insight into my (I think reasonable) mindset.
I certainly agree much more investigation is warranted before such a drastic decision.

Please, don't be one of these people. I still have hope that you can rise above that.

And before more people ask. No, Direct3D support in SFML will not be coming before SFML 3. Even if we decide that it is doable, I am certainly not going to invest my unpaid time promoting a graphics library that has done nothing but mislead and stab people in the back time and again. When it comes to open source development, I am strongly driven by my morals, and Microsoft has violated them in too many ways already.

I'll try not to be.  :)  I necessarily mix my morals with some pragmatism, but I understand and respect your stance.
« Last Edit: October 02, 2014, 11:19:59 pm by Jabberwocky »

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: stuttering on some hardware, not others
« Reply #3 on: October 02, 2014, 11:15:34 pm »
For anyone interested, here are some links discussing stuttering and performance problems with NVidia's "Threaded optimization" across many different OpenGL and DirectX games. 

Minecraft (OpenGL-based)

Quote
Go into Control Panel (should be in your start panel button, if not just search for it), click Appearance and Personalization, then go to NVIDIA Control Panel and turn off threaded optimization, and it should work.

GTA IV

Quote
Since the 180.84 drivers nVidia f*cked up this game completely. They added a so called "GTA IV Optimization" into their drivers from that point on. And it just made it stutter like hell for at least 30% of the players.

However, I found that if you disable "Threaded Optimization" in the nVidia control panel, the stuttering issue is eliminated 90% of the time on all nVidia drivers, old and new.

I know this because I have at least 20 coworkers who have had that problem. Deactivating the threaded optimization worked for 17 of them.

Diablo 3

Quote
Hi Guys,

was having a play around on the weekend, still get massive latency issues but here are some options that fixed my framerate.

Optical Occlusion - OFF
Pre Rendered Frames - 0
Threaded Optimization - OFF

I have done a few other things but the Threaded Optimization was what fixed the stuttering.

Alien Arena (OpenGL-based)

Quote
Just wanted to post this in a dedicated thread to make it easier to search:

Make sure to turn OFF Threaded Optimization in your nVidia control panel (do not leave on Auto). Twice now this has gotten the better of me and it was only luck that I rediscovered an old thread to remind me. For me there is a significant performance increase with it OFF as opposed to Auto (default).

With each driver update you should check it again and make sure its still off. I had mine off but when I checked again, its back on (Windows). Linux does not have this in the nVidia control panel, you have to use: export __GL_THREADED_OPTIMIZATIONS=0

Keywords:
Video, FPS, nVidia, frame rate, choppy, stutter, jitter, performance, settings

Arkham City

Quote
I turned off "Threaded Optimization" in Nvidia Control Panel and it seemed to work wonders for me. I get stuttering before but it seemed fixed when I turned of Threaded Optimization. Worth a shot for Nvidia users having problems.

Diablo 3

Quote
Turning Threaded optimization off, in the nvcpl helps alot, turning on triple buffering also helps a bit, but it's still not gone.

Oblivion

Quote
In the Nvidia drivers control panel, under 'Manage 3D Settings', and in the profile window there is an option labelled 'Threaded Optimization' which can be set to Off, Auto or On.

Now i'm guessing it has something to do with the way multi-core CPU's handle in game visuals and the like. A lot of people think it produces nothing but bad results when left to Auto or On....and I can concur that Oblivion for example would stutter and crash while I had this forced on.

Testing NVIDIA's Linux Threaded OpenGL Optimizations

Quote
The HTML documentation bundled with the driver binary goes on to explain:
"The NVIDIA OpenGL driver supports offloading its CPU computation to a worker thread. These optimizations typically benefit CPU-intensive applications, but might cause a decrease of performance in applications that heavily rely on synchronous OpenGL calls such as glGet*.

NVIDIA "threaded optimization" oxymoron

Quote
So I pulled out Process Explorer and looked at the threads, lo and behold there is an opengl thread using a whole core on its own. I looked at the stack trace and saw this thread was doing the VSYNC. This confused me, because another thread was apparently also doing this, why do you need two threads to do the same thing? Especially something so costly? Well as it turns out, NVIDIA calls this an optimization, threaded optimization, and guess what, it's enabled by default.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: stuttering on some hardware, not others
« Reply #4 on: October 02, 2014, 11:45:23 pm »
This is also one of the issues I have with Nvidia. They think they are doing a favour for their users by giving them the option of enabling this so called "threaded optimization". What they fail to realize is that the vast majority of those users simply have no idea what the option does. I must admit, I initially didn't know what it really did, but unlike others, I wouldn't enable things that I do not fully understand (I never owned an Nvidia card so...). But I guess your average gamer, or even novice developer always thinks of good things when something is labelled as an "optimization", and complains about how broken this so called "optimization" is in retrospect. Maybe if it was labelled "enable driver thread offloading", people would be a bit smarter about it...

But yeah... since as you mention, big games seem to have issues with it as well, SFML really can't be held responsible for the user enabling broken driver settings.

I still stand by my statement that this has almost nothing to do with deprecated OpenGL. Khronos writes the specification they call OpenGL. In it is described what effects API calls have to have. How they are translated into driver and GPU specific instructions is up to the vendor to decide. But one thing is for sure, if a new GPU comes out with a new instruction set, new drivers and translation routines would have to be written anyway, and unless vendors refuse to let old games like Quake III run on GTX 980s they will have to constantly maintain these as well. So from that standpoint, you can't really say that deprecated OpenGL is "supported less" than modern OpenGL. Once the implementation of a specification works flawlessly, there isn't much left to do. The problems only arise when they think they can get smart and start implementing "optimizations" that were never part of the specification in the first place. In that sense, they are actively breaking what was previously considered stable, and this should be something their users complain more about, because it seems they don't care enough about it at the moment. Just another day in the life of the positive DirectX feedback loop...
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: stuttering on some hardware, not others
« Reply #5 on: October 03, 2014, 12:20:54 am »
There is likely a very different mindset between an indie game developer and an open source library dev such as yourself.  I need to be lazy in the sense that the path of least resistance is a crucial factor in my engineering decisions.  Otherwise, I simply would not finish my projects, or else spend too much time on low level engineering issues at the expense of coding and polishing gameplay.  Now, the path of least resistance is not the only consideration.  If it were, I would likely be using something like Unity3D rather than building a game engine around SFML.  I choose SFML because I dislike working in a "scripted sandbox" such as Unity, and much prefer to have access to all the source code in my project.

Given infinite time, I could absolutely understand what the problem is and why the change might make a difference.  But I don't have infinite time, so I must set boundaries before resorting to "shotgun programming".  Given the evidence so far (works on ATI on different machine, works on intel card of same machine, does not work on NVidia, other DirectX games do work on NVidia), NVidia OpenGL driver issues are an obvious candidate for consideration.  *If* (and I stress if, as I did in my original post) SFML/OpenGL/driver issues repeatedly plagued the project, and the solution to these issues lay in closed source NVidia driver code, or low level SFML/OpenGL code (which is beyond my current expertise to fix), switching would be a reasonable consideration.  But that is just one potential outcome of many.  And please do not interpret this as a criticism of SFML code, which I find to be excellent code to work with.
While I see your "point" it's in my opinion a rather bad consideration. Just because some OpenGL code doesn't play 100% smooth on a specific system with a specific GPU and driver, it would be rather naive to abandon OpenGL and run to the "next best thing" DirectX, while completely ignore that by doing so you might run into new/similar/same issue, while loosing any kind of true cross-platform support. Sure cross-platform support doesn't seem like a big deal when starting out development on one system, but once you're ready to release a game and can only serve one platform, you'll very quickly regret it. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: stuttering on some hardware, not others
« Reply #6 on: October 03, 2014, 12:47:45 am »
@binary1248
Agreed with everything you wrote.  But I should point out that it was the default option ("Auto") that was causing the stuttering.  Only by explicitly setting this option to "Off" did the stuttering go away. 

While it is very useful to find this work-around (changing a setting in the NVidia control panel), this still presents a pretty nightmarish situation if this is a requirement of the released product.  I've got some more investigation to do.

Just because some OpenGL code doesn't play 100% smooth on a specific system with a specific GPU and driver
Agreed. 
Although that is very different from what I said.  Just to stress it a third time in bold and italics ;) I would only do this *if* it proved to be a OpenGL-specific problem that affected a lot of users.

Sure cross-platform support doesn't seem like a big deal when starting out development on one system, but once you're ready to release a game and can only serve one platform, you'll very quickly regret it. ;)

I fully agree on the importance of cross platform.  It was a significant factor on why I choose SFML.

For what it's worth, I ported my last game to linux as well as windows.

Hapax

  • Hero Member
  • *****
  • Posts: 3346
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: stuttering on some hardware, not others
« Reply #7 on: October 03, 2014, 03:13:43 am »
I was just looking through the quotes about those games and saw this:
Quote
...the stuttering issue is eliminated 90% of the time...
I know this because I have at least 20 coworkers who have had that problem ...worked for 17 of them.
17 out of 20 is 85% *rolls eyes*
If there are more than 20 ("at least 20"), the percentage is even lower. *tut*
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

BaneTrapper

  • Full Member
  • ***
  • Posts: 213
  • Do you even see this, i dont need it.
    • View Profile
    • Email
Re: stuttering on some hardware, not others
« Reply #8 on: October 05, 2014, 10:33:03 am »
I was just looking through the quotes about those games and saw this:
Quote
...the stuttering issue is eliminated 90% of the time...
I know this because I have at least 20 coworkers who have had that problem ...worked for 17 of them.
17 out of 20 is 85% *rolls eyes*
If there are more than 20 ("at least 20"), the percentage is even lower. *tut*
:D.

Free education! thanks all.
BaneTrapperDev@hotmail.com Programing, Coding
Projects: Not in development(unfinished/playable):
http://en.sfml-dev.org/forums/index.php?topic=11073.msg76266#msg76266
UP and in Development: The Wanderer - Lost in time
http://en.sfml-dev.org/forums/index.php?topic=14563.0

Xornand

  • Jr. Member
  • **
  • Posts: 78
  • C++ / Python
    • View Profile
Re: stuttering on some hardware, not others
« Reply #9 on: October 19, 2014, 11:04:00 pm »
I was just about to post a similar thread. After upgrading to the newest SFML revision, my game started to stutter. I experimented with different settings (choosing different framerate limits etc) but the program was still stuttering no matter what... After reading this thread, I decided to turn threaded optimization off on my Nvidia Optimus setup (it was enabled by default) and, to my surprise, it really fixed the problem :D

musicaljelly

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: stuttering on some hardware, not others
« Reply #10 on: April 15, 2016, 06:26:49 am »
I know I'm digging up an old thread, but I figured I'd mention this for future readers.

I was timing each frame in my game, and they were consistently coming in under 0.5ms. Silky smooth. Every few seconds, I'd get a frame that was 30ms+. This baffled me. I profiled the various parts of my code, and there was no rhyme or reason to why different parts seemed to be randomly taking a long time all of a sudden.

It was the OS switching threads while the frame was in progress.

If you're seeing stuttering, try turning up the process priority. Be careful of course, as you don't want to negatively impact the usability of the machine by making everything else slow. And make sure that you have vsync or a frame limit enabled if you do this, so you don't chew through boundless CPU cycles at a high priority. But I found this change completely fixed the stuttering I was having.

I'm on Windows, and I added the following at the startup of my game:

SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS);

...and this eliminated practically all of the stuttering. You'll need the Windows API available to you of course to get the above to compile. I still get stuttering when the game doesn't have focus, or when other CPU-intensive processes run. Those cases however are both to be expected, and are acceptable for a game in my opinion.

 

anything