SFML community forums
Help => General => Topic started by: MrSoupSox on October 19, 2015, 11:08:31 pm
-
I've been searching for several hours, and tweaking my code, trying to determine exactly what's causing my problem, but to no avail.
I've been spending the past few days tweaking my game and making it frame-rate independent, and running into frametime inconsistencies that I can't seem to eliminate. I've been working on implementing a time step like that described in Gaffer's "Fix your timestep" article (fixed physics update intervals, variable rendering w/ interpolation), and I understand the loop inside and out, but I for some reason can't eliminate some timing discrepancies.
I've commented out every game loop aspect besides
1) Calculating frametime (to determine how many fixed-interval physics updates to calculate per cycle)
2) Basic drawing of debug info. And I've even tried not printing the debug info, and still I get spikes(just printing spikes to the console).
No matter what pollrate and fps settings I use, I still get frametime spikes every 5-6 seconds or so. This is manageable, considering the game adjusts for the increased frametime, and updates the physics more times per cycle to compensate, but the noticeable hitching when frametimes sometimes spike above 50-70 ms (I'm trying to have stability at 144 fps, so 7-8 ms) is very irritating, and I can't seem to figure out why this is happening.
I am not using setFrameRateLimit at the moment (my experience is that it limits the speed of the whole thread, and this caused some inconsistencies for me), but even when setting the framerate limit, I still get frame time spikes. Enabling vsync yielded less overall spikes, but the spikes were far higher (sometimes 80+ ms). I can provide my code if needed, but again, literally all it is doing is calculating frametime (at the pollrate, 60-150 times a second, depending on my settings), and drawing debug info (60-144 fps, depending). I have also tried calculating frametimes with millisecond and microseconds, and both still get frametime spikes.
Does anyone have experience running SFML games stable at high refresh rates? Is this a threading problem?
I wasn't sure if multi-threading would solve my problem, but am certainly more than willing to try it at this point, as I'm at my wits' end.
Any help would be greatly appreciated.
-
First off multi-threading won't solve anything in most likely would make things only worse. ;)
What's your OS, GPU, etc?
Is your GPU driver uptodate?
Do you experience the same issue in release mode?
-
First off multi-threading won't solve anything in most likely would make things only worse. ;)
Yeah that's what I figured. I did notice that 1 core is running at 99%, with drop-offs whenever I get frametime spikes. I wouldn't assume that it's a CPU throttling issue though, is that right?; Does SFML typically run a single core at high usage like that?
And for specs, I'm on Windows 10 with a 980Ti, drivers are up to date.
You did clue me in that I had been running in release mode this entire time! Yikes! Running in debug mode actually yielded less spikes overall, but there are still occasions where I get 50+ms for several game ticks, before returning to regular times for another ~20 seconds or so.
I'll try experimenting with pollrate and fps settings in debug, see if that helps. And perhaps this is the wrong place to ask, but what is the difference between debug and release mode? I assume VS keeps a closer eye on system resources and the like in debug mode?
Thank you for your help!
-
Still getting spikes :/ No changing to fps or pollrates has fixed it, debug or release mode. It seems almost as if the whole program is "hiccuping" with CPU performance, and then goes right back to normal.
Not game-breaking by any means, but I'm trying to work my way up from the most baseline performance issues, and back to the regular working state of my game before I start re-adding stuff that could further reduce overall performance. Cpu usage on core 0 stays at 99%, then drops to 50% or so when the program has a frametime spike, then hops back up to 99% again.
-
What if you disable multi-threaded rendering in your GPU driver's settings?
It sounds a bit like the OS is pausing your application on the CPU for a bit, but not sure why. Then again at best you use some profiling tool to figure out where exactly the time is spent.
Does SFML typically run a single core at high usage like that?
Well by not limiting your framerate in anyway, you're telling the CPU to run as fast as possible, which then obviously will try to max out one core.
And perhaps this is the wrong place to ask, but what is the difference between debug and release mode? I assume VS keeps a closer eye on system resources and the like in debug mode?
If you don't know the difference, you might want to learn a few more things about your toolchain etc.
A debug build contains debug information, like symbols information. Additionally it usually is also not optimized and more of a 1:1 translation of the code. This makes it possible to step through the full source code.
-
What if you disable multi-threaded rendering in your GPU driver's settings?
Well by not limiting your framerate in anyway, you're telling the CPU to run as fast as possible, which then obviously will try to max out one core.
Yeah, went ahead and disabled multi-threaded rendering, and capped the SFML frame rate (just to make sure it's not needlessly adding to the timecounter every cpu cycle). Same problem. :/
And yes, I really should take the time to properly learn VS. I've been using C++ for a while, but I'm brand new to VS, there's a lot going on haha.
I'll see what I can do as far as profiling, thanks for the suggestions.
-
Interestingly enough, task manager and resource monitor both list the game as constantly not responding...
Also, if I open a program while the game is running, it immediately causes a reproducible spasm of frametime jumps (which I guess is actually pretty typical of many games, to a certain extent). Raising the priority of the game in task manager also has no effect
-
Interestingly enough, task manager and resource monitor both list the game as constantly not responding.
That sounds like you are not processing events regularly.
-
That sounds like you are not processing events regularly.
Ah, thank you, I was wondering which part of my debug commenting caused that to start happening. I wanted to eliminate as many performance barriers as possible in my game loop when testing this problem.
-
Yeah still no luck :/ If anyone has any sort of CPU monitoring tools in mind that might help me resolve this weird issue, it would be greatly appreciated (or rather, what exactly to google).
-
You're using Visual Studio, right? It has a profiler built in.
-
You're using Visual Studio, right? It has a profiler built in.
Ah, thank you, that's a really cool part of VS I've never even explored!
I discovered that when in windowed mode, whenever I move the window, the game stops responding, and whenever I let go/release the window, it resumes, and catches up the time that was lost.
I noticed that in the CPU usage analytics, window events seem to be the only functions called. Does this mean I should be putting my game loop within the loop that is just responsible for polling window events, or finding a way to bail out of checking too many events? (i:e moving the window so much, it never gets out of the window event poll loop) That doesn't seem right, but those are the only function calls during my game's periodic "blackouts". That being said, commenting out my window event polling loop still gives me the original small frametime spikes, just not the larger, reproducible ones (because I can't actually move the window without the event polling...).
I also tried requesting window focus whenever it is lost, but that doesn't seem to work, either (it doesn't actually even request the focus until the window returns back to it's normal responsive state). So it looks like the small frametime spikes I've been having are some sort of window-focus related issue.
-
Do you have any controllers/joysticks plugged in?
-
Do you have any controllers/joysticks plugged in?
Nope, neither of those. Tried disabling and turning off most background programs as well
-
Although I agree that spikes are unpleasant. You do realize that that you can never elliminate such spikes - right? So you have to be prepared to deal with them.
Yes, if SFML is causing unneeded spikes, then that's a bug to be fixed. But just the fact that there are spikes - that's not a bug in itself. You can never count on a stable frame rate..
-
Although I agree that spikes are unpleasant. You do realize that that you can never elliminate such spikes - right? So you have to be prepared to deal with them.
Yes, if SFML is causing unneeded spikes, then that's a bug to be fixed. But just the fact that there are spikes - that's not a bug in itself. You can never count on a stable frame rate..
Yes, I am aware of this. I just asked originally to determine if anyone had any similar experiences with these sorts of consistent irregularities. I reworked my game's loop from the bottom up to make it bulletproof in terms of physics and graphics being independent of framerate and frametime, and while I was doing this, I noticed that these strange irregularities (the very noticeable stuttering of my game was always a factor, but the concrete frametime measurements were not) were still present, even though my code was drastically more stable and adaptable.
So yes, even though my game works at any framerate/frametime, and the spikes don't affect the actual determinism of the gameplay, I guess it's a trivial complaint. That being said, playing the game and having it visibly hiccup, and then play catch-up isn't exactly what I'm aiming for when refining the most basic parts of my game loop. Perhaps I'm too picky, but then again, this happens for any fps, any pollrate, so unless everyone else using SFML deals with 3x the frametimes for several frames at a time, with visible stuttering in their games, then I must have some issue still yet to sort out. I do appreciate the suggestions, I'm just overall very frustrated with this bug.
-
while I was doing this, I noticed that these strange irregularities (the very noticeable stuttering of my game was always a factor, but the concrete frametime measurements were not) were still present, even though my code was drastically more stable and adaptable.
Regarding stuttering, if you're using an nvidia graphics card, this is worth a read:
http://en.sfml-dev.org/forums/index.php?topic=16449.0
-
I discovered that when in windowed mode, whenever I move the window, the game stops responding, and whenever I let go/release the window, it resumes, and catches up the time that was lost.
That's completely normal, however you might want to limit the amount of frames caught up. Otherwise the game will run for several seconds (or even longer) without the user being able to react properly, once the window got moved (or something else happened). This might most likely be at least part of your issue here.
Does this mean I should be putting my game loop within the loop that is just responsible for polling window events, or finding a way to bail out of checking too many events? (i:e moving the window so much, it never gets out of the window event poll loop)
No, your code is probably fine already. The event loop should really just be an event loopt.
I also tried requesting window focus whenever it is lost, but that doesn't seem to work, either (it doesn't actually even request the focus until the window returns back to it's normal responsive state).
This is pretty normal as well. The window won't be able to process messages while it's stuck catching up and even then they're processed in order. Also keep in mind that the window focus requests aren't considered to be guaranteed. It's up to the window manager to grant or deny focus.
-
I discovered that when in windowed mode, whenever I move the window, the game stops responding, and whenever I let go/release the window, it resumes, and catches up the time that was lost.
That's completely normal, however you might want to limit the amount of frames caught up. Otherwise the game will run for several seconds (or even longer) without the user being able to react properly, once the window got moved (or something else happened). This might most likely be at least part of your issue here.
Ooooh I never considered that, that's actually a really good idea. So instead of forcing the game to track the entire time it's "behind" in frametime, I let it catch up to a certain extent, and then just skip ahead after a certain frametime threshold? That's something I never considered, thank you!
-
Also something else to consider why you need a limit: Assume your target update rate is 100 updates per second. What happens if the machine is too slow and is only able to update 90 times per second? It will never ever leave that loop again, because you'll constantly add outstanding updates.
-
Also something else to consider why you need a limit: Assume your target update rate is 100 updates per second. What happens if the machine is too slow and is only able to update 90 times per second? It will never ever leave that loop again, because you'll constantly add outstanding updates.
Actually it would account for running too slow, as it adds the time taken since the last update, and subtracts every time it actually updates the game itself. So if it was too slow, it would skip cycles until it accumulated enough time to calculate another game "frame". It would just result in stutters actually quite similar to the ones that I get currently. That was my first thought as far as my issue goes; but the problem is reproducible at any poll rate of the game frames. I think Gaffer's article refers to it as "fixed update time step, variable rendering". Variable t produced by the renderer, consumed by the updates in fixed dt increments.
That being said, I realized that my measuring of time could be flawed. I measure currently in microseconds, and I tried comparing sf::Time objects, but couldn't determine any way without converting to concrete types at some point in the process.
That's completely normal, however you might want to limit the amount of frames caught up. Otherwise the game will run for several seconds (or even longer) without the user being able to react properly, once the window got moved (or something else happened). This might most likely be at least part of your issue here.
This did get me thinking though, wouldn't just skipping amounts of lost frames affect the determinism of my game in the long run? Perhaps that's the least of my problems at the moment, but I am concerned that if I commit now, it might eliminate possibilities of any game features that rely on determinism (replays, multiplayer, etc). Maybe just log whenever frames are lost? Perhaps I just cross that bridge when I come to it...
-
No, by dropping updates you're essentially just pausing the game, unless you use some kind of real time clock somewhere. Count the number of updates for timing purposes, don't rely on actual time and you should be fine.
-
Here is some notes that I found during performance improvement:
1) Do not set Text.CharacterSize it leads to low performance and unexpected lags at random moments. Use Text.Scale instead (high important)
2) Do not set CircleShape.SetPointCount at render loop, it leads low performance (important)
3) Create shape instance only once and then reuse it for different sizes (a little better performance)
4) Try to render each shape with dedicated shape instance if possible to avoid change shape properties (it consumes more memory, but gets a little better performance)
5) After create RenderWindow, call to SetFrameLimit with 0 or exact physical display frame rate (important)
6) Do not use SetFrameLimit with value different from 0 and exact physical display frame rate. Unfortunately SFML doesn't provide current display frame rate, so if you are using non 0 value, you should to provide user with setting for frame limit value (important)
7) Try to avoid pass more than 205 vertices into RenderWindow.Draw. Just split it on small parts with 200 vertices in each and pass them separately. The same limitation is applied to CircleShape.SetPointCount (it significantly minimizes CPU load and improves perfromance for a little. I don't know the exact reason of such behavior, but it seems like more OpenGL issue than SFML)
-
For anyone stublign up on this at one point, it has to be said that these "tips" are not generally applicable. Most of them are specific to mkalex777 hardware and a lot of them are just premature optimization that have barely any basis in real applications.
-
Tips....?
Do you have any proof at all that these are legitimate problems or optimizations? Any benchmarks or blog articles by verified programmers or anything at all? 205 seems ridiculously arbitrary especially considering that it isnt even a power of 2.
-
All he has is his trial and error tests on his specific system.
-
Sooo... No? ;)
-
All he has is his trial and error tests on his specific system.
We're found that this behavior depends on video driver setting "Thread optimization". It is reproduced with default setting "Auto" and disappears with "disabled" setting.
It's reproduced on nVidia GTX460 videocard with the latest drivers and Intel i5 760 processor (4 core, 2,8 GHz) on Windows 7 x64.
I'm not sure if it will be reproduced on ATI videocard, but it seems like some issue related to the nVidia OpenGL 4.5 implementation.
There is need to test it with clean OpenGL code to make sure that it's not related to SFML.
And I need to clarify that 205 is not limit. All works fine even wih higher amount of vertices. But this magic 205 vertex count leads to trigger high CPU load and decrease frame rate for a little. When this magic number is reached, adding just one more vertex into array leads to jump CPU load from zero to 100% cpu core consumption. It's very strange I have no idea how 1 more vertex may consume so many cpu time.
Probably this magic count activates using some kind of spin lock loop insteand of wait handle inside vedeo driver...
I understand that this issue may be related to hardware and driver, but it at least solves high CPU load on my machine so I split vertex array and have low CPU load with any driver setting :)