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 (http://en.wikipedia.org/wiki/Necessity_and_sufficiency) 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.
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 (http://en.wikipedia.org/wiki/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.
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.
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?
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.
Not only was it downloaded > 6 months ago, it is almost 1.5 years old, and many fixes behind the current master.
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.
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.
You haven't even ruled out that it might not happen on certain AMD or even Intel cards. Again... necessary condition.Absolutely true.
This can probably be considered a lesser manifestation of shotgun debugging (http://en.wikipedia.org/wiki/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.
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.
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.
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.
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.
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
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.
Turning Threaded optimization off, in the nvcpl helps alot, turning on triple buffering also helps a bit, but it's still not gone.
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.
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*.
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.
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.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. ;)
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.
Just because some OpenGL code doesn't play 100% smooth on a specific system with a specific GPU and driverAgreed.
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. ;)
...the stuttering issue is eliminated 90% of the time...17 out of 20 is 85% *rolls eyes*
I know this because I have at least 20 coworkers who have had that problem ...worked for 17 of them.
I was just looking through the quotes about those games and saw this::D.Quote...the stuttering issue is eliminated 90% of the time...17 out of 20 is 85% *rolls eyes*
I know this because I have at least 20 coworkers who have had that problem ...worked for 17 of them.
If there are more than 20 ("at least 20"), the percentage is even lower. *tut*