High FPS unstable frametimes?

[MrSoupSox]

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.

[Jabberwocky]

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

[Mario]

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.

[MrSoupSox]

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!

[Mario]

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.

[MrSoupSox]

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...

[Mario]

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.

[mkalex777]

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)

[eXpl0it3r]

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.

[Gambit]

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.

[eXpl0it3r]

All he has is his trial and error tests on his specific system.

[Gambit]

Sooo... No? 

[mkalex777]

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