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:
(http://i1093.photobucket.com/albums/i434/GanadoFO/intro01.png)
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?