Author Topic: Temporary disable double buffering (or capture screen) (Read 8774 times)

93interactive · « **on:** September 11, 2009, 01:21:08 pm »

Hello,

i am trying to implement some pause to my game, so my game runs in game mode, renders everything and calls Window->Display(), then the user hits escape, and the game changes changes to the pause mode.

so my plan was, just to keep the drawn screen and render my pause menu over it, but calling Window->Display() in the pause mode, does switch between the last 2 frames of the game mode.

is it possible to temporary disable double buffering, so that in menu state, only the last frame is kept, and when back in game mode, double buffering is active again?

some other option would be to somehow capture the last render screen and blit it once in the pause state.

K-Bal · « **Reply #1 on:** September 11, 2009, 01:35:56 pm »

Just don't call sf::RenderWindow::Clear() maybe?

93interactive · « **Reply #2 on:** September 11, 2009, 02:33:46 pm »

yes i could do that, but actually i want the running game to be visible in the background.

K-Bal · « **Reply #3 on:** September 11, 2009, 03:09:07 pm »

The game is still running when paused :?:

Laurent · « **Reply #4 on:** September 11, 2009, 03:36:40 pm »

This is bad idea. You'd better capture the last screen (RenderWindow::Capture) and display it with a single, fullscreen sprite.

jimboTL60 · « **Reply #5 on:** September 23, 2009, 12:32:17 am »

I built a graphic interface. In the main loop, if a control has to be updated, it is drawed on the RenderWindow then displayed. But I do not use Clear(), because the program would have to draw all the controls over again, which would considerably slow down the program. The problem is that without clearing the screen, it flickers between the two buffers used by SFML. I'm looking for the best solution not to compromise speed. I wouldn't care if it were not for the real time audio that has to be calculated at the same time.

I guess I could indeed capture the last frame and redisplay it, but wouldn't that mean doubling the framerate?

Laurent · « **Reply #6 on:** September 23, 2009, 08:45:04 am »

Don't do that. A real-time application must be drawn completely every frame, trying to draw only parts of the screen will always lead to problems.

Drawing a GUI shouldn't be that slow, maybe you can show us your code so that we can help you to optimize it?

By the way, drawing GUIs will typically be much faster in SFML 2.

jimboTL60 · « **Reply #7 on:** September 24, 2009, 04:59:55 am »

That's good to now, thank you very much! I was afraid it would be too slow but if you say it is the common way, I'll just do that.

Why will it be faster in SFML2 to draw a GUI?

Also, is it better to use vsync?

Laurent · « **Reply #8 on:** September 24, 2009, 08:40:36 am »

Quote

Why will it be faster in SFML2 to draw a GUI?

Because SFML 2 will use automatic batching, which works very well when lots of sprites using the same image are drawn.

Quote

Also, is it better to use vsync?

Usually yes. But it's not very important.