SFML community forums

Help => General => Topic started by: Assassinbeast on February 02, 2013, 01:58:39 am

Title: Is it okay to have two pollevent() on one event?
Post by: Assassinbeast on February 02, 2013, 01:58:39 am
ex:

sf::RenderWindow mywindow(sf::VideoMode(800,600,32),"test");
sf::Event ev;
void world1();

int main()
{
        while(mywindow.isOpen())
        {
                while(mywindow.pollEvent(ev))
                {
                        switch(ev.type)
                        {
                        case sf::Event::Closed:
                                mywindow.close();
                        case sf::Event::KeyPressed:
                                if(ev.key.code == sf::Keyboard::Space)
                                        world1();
                        }
                }
                mywindow.clear(sf::Color(0,200,0));
                mywindow.display();
        }
}

void world1()
{
        bool go = true;
        while(go)
        {
                while(mywindow.pollEvent(ev))
                {
                        switch(ev.type)
                        {
                        case sf::Event::KeyPressed:
                                if(ev.key.code == sf::Keyboard::Left)
                                        go = false;
                        }
                        mywindow.clear(sf::Color(200,0,0));
                        mywindow.display();
                }
        }
}
 

here, the ev variable is polled by two different pollevents, deppending on where the loop is executing, is that okay?
Title: Re: Is it okay to have two pollevent() on one event?
Post by: eXpl0it3r on February 02, 2013, 02:15:19 am
Not really, since you're calling world1 from within the other event handling. It might "work" but it's not advised. But you can easily just poll the events in one location and then pass the polled event to different functions, where you can further process it.
Title: Re: Is it okay to have two pollevent() on one event?
Post by: Assassinbeast on February 02, 2013, 02:34:10 am
Not really, since you're calling world1 from within the other event handling. It might "work" but it's not advised. But you can easily just poll the events in one location and then pass the polled event to different functions, where you can further process it.

How can i pass polled events through functions and use them in other functions?

btw thanks for help :)
Title: Re: Is it okay to have two pollevent() on one event?
Post by: Nexus on February 02, 2013, 12:25:58 pm
How can i pass polled events through functions and use them in other functions?
Write functions with a sf::Event parameter.

By the way, avoid global variables, especially with types from SFML. They will cause issues with initialization/destruction order sooner or later. Apart from that, maintenance will become much easier if you keep dependencies local. Even if it's just a test example here, I thought I'd mention it ;)
Title: Re: Is it okay to have two pollevent() on one event?
Post by: Assassinbeast on February 02, 2013, 01:59:33 pm
How can i pass polled events through functions and use them in other functions?
Write functions with a sf::Event parameter.

By the way, avoid global variables, especially with types from SFML. They will cause issues with initialization/destruction order sooner or later. Apart from that, maintenance will become much easier if you keep dependencies local. Even if it's just a test example here, I thought I'd mention it ;)

Ahh ok. But is it okay to make my renderwindow global? i mean... its gonna be ridiculous tedious to pass my renderwindow into almost every function and classes.
Title: Re: Is it okay to have two pollevent() on one event?
Post by: Nexus on February 02, 2013, 02:16:07 pm
Ahh ok. But is it okay to make my renderwindow global?
No.

i mean... its gonna be ridiculous tedious to pass my renderwindow into almost every function and classes.
It's rather ridiculous that you think you need to pass it everywhere ;)

In fact, there are only a few places where the render window is needed -- mainly for drawing and input handling. If you encapsulate both functionalities well, you only have a few classes that need access to the render window. And they can store a pointer as a member variable.

Almost always, global variables are a result of bad design. They seem handy in the beginning, but bring a lot of issues in the long term. You need to spend some time to reflect about code design, but it will certainly pay off.