I'm sure this question is asked a lot...
...VLC media player (which uses hardware rendering I would guess), doesn't use %50 of the CPU when paused.Yes I'm sure VLC is making use of hardware acceleration for the video rendering part. For the whole GUI stuff they're using wxWidgets and/or Qt 4 (http://www.videolan.org/developers/vlc.html).
I'll look into sf::Sleep. Windows' Sleep is not good, because it makes the whole program unresponsive for that amount of time.
Is 2.0 stable?SFML 2.0RC is a Release Candidate (RC), which means the API won't change that much if at all. The stability of the library itself was always kind of guaranteed. ;)
I appreciate the help, but not the attitude.Well thank you! :)
Coming from GLUT, there are two very different functions: glutIdleFunc() and glutPostRedisplay(). Framerate/Sleeping has nothing to do with it. Using Idle will loop as fast as told to (Framerate/Sleeping), and PostRedisplay is called when drawing is needed.
Why couldn't you have said that in your opening question?Just because I figured the question had been asked a lot. Anyway...
void update(int value) {
if (camera.moving())
{
camera.moveX();
camera.moveZ();
camera.moveY();
glutPostRedisplay(); //Tell GLUT that the scene has changed
}
//Tell GLUT to call update again in 25 milliseconds
glutTimerFunc(25, update, 0);
}
bool Running = true;
while (Running)
{
App.Display();
}
SFML doesn't forward the "paint" event (which tells whenever the window needs to be refreshed). This is not how things must be done nowadays. A main loop and vertical-sync enabled is all that you need, don't try to keep the same structure as you had in programs that use 20-year old APIs.What are the drawbacks for such an API calling? Or why does the new way superseed the old one?
Basically, a display function is given to GLUT ...Thanks for explaining! :)
I imagine something like this is possible with SFML, however it isn't with the way the tutorial code is presented, basically:Yes, there's no API call for SFML to idle the application and since the paint event doesn't get propagated you can't use sf::Window::waitEvent() which would wait until the next event happens.bool Running = true;
while (Running)
{
App.Display();
}
We can limit framerate, but this still doesn't solve the fact that if nothing is happening, the frame shouldn't be updated.
What are the drawbacks for such an API calling? Or why does the new way superseed the old one?Reacting to the paint event is still useful for desktop applications that don't need constant refreshing. But SFML doesn't target this kind of application, its target is real-time applications (games).