Processor usage, using the Intro's fixed timestep code

[Ganado]

I know there's been threads on stuff like fixed timestep, but my question derives from that but is not talking about it in itself.

http://en.sfml-dev.org/forums/index.php?topic=3423.msg22221#msg22221
My issue is similar to the above link. It's not using up 50%, but it's still the most CPU-used program in the Task Manager (Windows 7).

The code I am using is verbatim https://github.com/SFML/SFML-Game-Development-Book/tree/master/01_Intro except I just have all the .cpp/.hpp files in one folder. Also, I read that mentioned article on a fixed physics timestep.

My problem is why such a simple program makes the processor work hard. I have made other programs in my free time, but I have set a max frame rate in the program, and using this, it runs almost silently like other low-power games.

Is there something simple I can change to the Intro's code to make it still have a fixed timestep but also limit the processor (this is done through sf::sleep when the MaxFrameRate setting is set)? Edit: Would having the maxFrameRate function on top of the fixed timestep part of the run/update cycle make it still have a fixed timestep but not run as hard? I feel like that would cause inaccuracies or defeat the point.

Image:

(click to show/hide)

[Jesper Juhl]

Try enabling vsync.
Make sure you are running a optimized release build and not an unoptimized debug build.
Also see this thread: http://en.sfml-dev.org/forums/index.php?topic=15175.msg107603#msg107603
And use a profiler to see where the CPU time is spent.

Edit: Also don't make the mistake of thinking that a fixed time step means a fixed frame rate - it does not. A fixed time step means that your simulation always advances a fixed amount of time each time you update it. The time between frames (frame rate) is completely separate from the update time and will vary and means that every frame you may advance the simulation 1 step, multiple steps or not at all depending on how long the frame took.
The fixed time step makes your simulation smooth and predictable, it doesn't fix the frame rate.
To fix the frame rate at some (rough) value you need to limit it by either synchronizing it to the monitors refresh rate (vsync) or by sleeping a bit after each frame (as the function to set a frame rate limit does). Both options will result in variable times per frame, but that's OK when you take the time per frame into account.

[Ganado]

I downloaded Sleepy, I'm still trying to decipher what some of it means... if I find anything from it I'll post it here.

Adding

mWindow.setVerticalSyncEnabled(true);

before the main loop did solve the processor issue, but as you said in your linked page, that shouldn't really be a "solution", should it?

And, I partially understood that, but I thought having a function that called sf::sleep would make the fixed timestep become inaccurate, or defeat the purpose of it.

Sleeping is not very accurate, so you should not use it for exact timing purposes. The method sf::RenderWindow::setFramerateLimit() tries to achieve the specified frame rate by calling sf::sleep() internally. It is a nice function for testing purposes, but it also lacks precision.

I thought that using the Window.setFramerateLimit(unsigned int limit) function negated the fixed timestep, or something. But if using both on top of each other makes it limit the frame rate while still providing a fixed update, then I will use that. Without making inaccuracies?

Right now I'm using the aforementioned function set at 60, and it's giving me a frame rate of 50-51 instead of the 700 in the previous picture (and the image does still move at the same rate, as far as I can tell, in case that wasn't clear).
Using Vsync gives it a 60-61 framerate, but both significantly limit the processing.

Thanks for the help. Could you confirm that using the tutorial's fixed timestep while also using the setFramerateLimit function does not decrease the accuracy of the logic?

[Jesper Juhl]

Don't use both setVerticalSyncEnabled and setFramerateLimit at the same time - they interact badly. Use one or the other, not both.
Prefer vsync when it works, fall back to setting frame rate limit when you must is my advice.

[Ganado]

I guess I wasn't being clear, whether I'm using Vsync or (exclusive) the framerateLimit, I just want to confirm that this shouldn't mess with the update logic in the fixed timestep because of the sf::sleep inaccuracies.

[Jesper Juhl]

What (I think) you are misunderstanding is, that the whole point of using a fixed time step is that inaccuracies in frame time does not matter. That's why you use a fixed time step in the first place; to deal with variable frame times and frame times beeing longer/shorter on different machines.
The reason for setting vsync enabled or limiting frame rate via sf::sleep (directly or indirectly) is purely to limit the amount of cpu your application uses.
Yes, vsync (usually) gives a smoother/more steady frame rate and lower CPU usage than setFramerateLimit, so when it works it is usually the better choice. But regardless of what you use you *will* get inaccurate times between frames and the way to deal with that is a fixed time step and taking delta time into account.

[Ganado]

Alright, then I think I have it set up good. Thanks for reading my walls of text!

[Ganado]

I figure I'd bump this topic instead of creating a new one:

So I've been making a game. From the start, it seemed like the movement was ever so slightly choppy, but I ignored this and kept adding onto it, making sure to keep the timestep stuff separate from other parts of the program so that I could one day fix it. But I don't want to ignore it anymore, so I made this example to show the choppy movement I am talking about.  It's set up very similar to the SFML intro.

Example of jittery movment (may be hard to see in this, I tried to show it by turning off the window.clear() function while the player moves diagonal)

Here is the compilable code:
http://pastebin.com/wSUN2DxJ

It might not look like much, and for now it really isn't, but is there way to change my timestep so that it doesn't get these slight "jumps" in the otherwise smooth movement?

From the fix your timestep article:

This causes a subtle but visually unpleasant stuttering of the physics simulation on the screen known as temporal aliasing.

Is this what's happening here? Should I bother to try to implement "interpolation" for something that doesn't need really accurate physical timing?

This is asking a lot, but if anyone would try to compile the above code (I tried to make it minimal) and see if they get instances of jittery movement, I would appreciate it! And also, if you know a good solution =) It it just saddening when my code has this weird movement, but other games I've played run so smooth comparatively.

[Hapax]

I don't think removing clear() gives an accurate representation of the problem. I tried that and it can animate (alternate) even when still 

As for the code, I don't think you "tried to make it minimal"  A minimal code would usually only require the main() block. Why would you post a full game class? To understand something better, it's best to make a small, minimal (main() only) code of it and test it alone. It also helps to assure that there can't be any mistakes in your use of the class etc.. The question would be have to be: does this still jitter if you remove all the class stuff and put very simple (obvious) version in just a main block.

I probably seem like I'm complaining far too much. I'm tired 

Anyway, the jittery seems to be when the frame rate goes into double frames per cycle. This could be due to your frame rate being only slightly higher than your refresh rate. Try out a higher timestep - 1/100s, for example.

[eXpl0it3r]

The interpolation isn't really optional if you want smooth movements, I mean the article already told you so.