Command and Control – Input Handling

Playing nice with your application neighborhood

Now what we learned in the last part is indeed handy, but it has got its problem. What if the user tabs out and tries to interact with the other applications that are running in the background? We would be constantly forcing the mouse back to the center of our window, making it impossible to do anything else than playing our game.

Believe it or not, this is actually very annoying for a lot of people, including ourselves. When we are debugging our application, this behavior will make it impossible to work with the IDE in the background. We have to detect when the user doesn't want to interact with us anymore and behave properly.

This is where events come in again. If you remember, we had the event types sf::Event::GainedFocus and sf::Event::LostFocus that notify the application as soon as the window gains or loses focus:

void Game::processEvents()

{

sf::Event event; while(mWindow.pollEvent(event))

{

if (event.type == sf::Event::GainedFocus) mIsPaused = false;

else if (event.type == sf::Event::LostFocus) mIsPaused = true;

}

}

void Game::run()

{

while (mWindow.isOpen())

{

if (!mIsPaused) update();

render();

processEvents();

}

}

In this example, we keep track of the focus of our application. We toggle a Boolean value depending on the focus that tells us if the game should be paused or not. Then, how do we prevent the game from changing if we are paused? That is simple with our current architecture; we just branch out the update call to only be called if the game is not paused. That way the game will keep rendering, registering events, and be responsive to the user and the OS. But it won't change its state over time.

[ 94 ]

www.it-ebooks.info