emptying sf::Window from events?

[Stauricus]

hello everybody
i made a simple intro screen, where it fades in a image, waits for the user to press anything in the keyboard, and then fades out the image.

the problem is that if the user press any button before the image is completely showing in the screen,  it fades in and out directly (instead of fading in and only then accepting user inputs)

this is the code (game_sys_p is an object that holds the sf::Window; and intro1_spr is a sf::Sprite)

sf::Event intro_events;
    int fade_factor = 1;
    for (int i=0; i>=0; i+=5*fade_factor){
        game_sys_p.getGameWindow().clear(sf::Color(0, 0, 0, i));
        intro1_spr.setColor(sf::Color(255, 255, 255, i));
        game_sys_p.getGameWindow().draw(intro1_spr);
        game_sys_p.getGameWindow().display();
        if (i>=255){
            fade_factor=-1;
                while (intro_events.type != sf::Event::KeyPressed){
                    game_sys_p.getGameWindow().pollEvent(intro_events);
                    sf::sleep(sf::milliseconds(10));
                }
        }
        sf::sleep(sf::milliseconds(20));
    }

i believe this happens because sf::Event is queueing the events (and i think it is expected). is there any way to prevent that?
or any change i could do to the code to fix it? any suggestion is welcome

thanks in advance!

[Jonki]

This line of code will empty the event buffer:

while (window.pollEvent(event));
 

I would recommend you to go through the tutorial (again), though. To me it seems you're not using the event system exactly like it's meant to.

[Stauricus]

ok, but if i use it like this:

while (game_sys_p.getGameWindow().pollEvent(intro_events)){
    while (intro_events.type != sf::Event::KeyPressed){
    //game_sys_p.getGameWindow().pollEvent(intro_events);
    sf::sleep(sf::milliseconds(10));
    }
}

then it does not respond to any input. i believe that it becomes jailed at the inner 'while', and to get out of it, the user have to press any button just after the loop started and before it ends, which is something very unlikely to happen, since it's a very fast moment.

[Jonki]

That will indeed freeze your program as soon as any event other than a key press is polled
To fix change the inner while into an if statement.

This doesn't resolve your initial problem, however. What you need to do is to keep running the empty event loop until you're ready to accept user input. After that, you can start listening for the key press event which will then move your app forward.

Again, please read the tutorial carefully, it's all there

[Stauricus]

(i also tought about changing it by an if statement, but it was fading in and out without user input at all...)

well, apart from the tutorial having a switch/case, the only thing i noticed is that "while (window.pollEvent(event))" checks for pending events (which i didn't knew). so is this a aceptable workaround (just added the bool key_pressed)?

sf::Event intro_events;
    int fade_factor = 1;
    for (int i=0; i>=0; i+=5*fade_factor){
        game_sys_p.getGameWindow().clear(sf::Color(0, 0, 0, i));
        intro1_spr.setColor(sf::Color(255, 255, 255, i));
        game_sys_p.getGameWindow().draw(intro1_spr);
        game_sys_p.getGameWindow().display();
        if (i>=255){
            fade_factor=-1;
            bool key_pressed = false;
            while (key_pressed == false){
                while (game_sys_p.getGameWindow().pollEvent(intro_events)){
                    if (intro_events.type == sf::Event::KeyPressed){
                        key_pressed = true;
                    }
                }
                sf::sleep(sf::milliseconds(10));
            }

        }
        sf::sleep(sf::milliseconds(20));
    }

[Ixrec]

I don't think it's a workaround at all.  I use a similar technique in my program and I've heard from others that the SFML book recommends it as well.  Simply put, doing it that way lets you separate the conversion from inputs to meaningful commands from the actual processing of those commands, which is very useful.

Of course, that's all assuming you actually do something with key_pressed later in your code.

[eXpl0it3r]

In all iterations you should be calling clear and display.
Draining the event loop like this is a bad idea.
However you can use a boolean to track the key input state, but make the check in the game loop itself and don't introduce an infinte loop while no input is happening.

[Stauricus]

ok, i got it.
the main game loop is designed acording to the event "rules". just this little intro is different. but now it's working exactly as it should.

thanks everybody for the help!