best practice

[lorence30]

hello, is it only alright to update an object outside the event loop?
since it doesnt have to do anything with events.
 

while(window.isOpen())
    {
        sf::Event e;
        while(window.pollEvent(e))
        {
            if ( sf::Event::Closed == e.type)
                window.close();
        }

        w.update(timer.getElapsedTime().asSeconds());
        timer.restart();

        window.clear();
        w.draw(window);
        window.display();
    }

[Jesper Juhl]

You can update an object whenever you like. Whether or not it makes sense to update an object at any given time (inside or outside the event loop) depends entirely on your program and the logic associated with the object etc. So the only real answer is "yes" and also "no" and "it depends"...

[Evan Bowman]

Say you were to move w.update(...), a function not having to do with events, into the event loop. It may be updated multiple times, or not at all, which most likely isn't what you want. My understanding is that control flow only enters the body of the event loop when a valid I/O event occurs (such as a key press/release, etc.). If you have an object or variable that records keyboard states, then that would be a good candidate for updating inside the event loop. Otherwise I wouldn't really mess around with it.

EDIT: this is how I typically use event loops, inside some sort of wrapper class:

(click to show/hide)

#pragma once
#ifndef inputController_hpp
#define inputController_hpp

#include "SFML/Graphics.hpp"

class InputController {
private:
        bool left, right, up, down, x, z, c;
       
public:
        InputController();
        bool leftPressed() const;
        bool rightPressed() const;
        bool upPressed() const;
        bool downPressed() const;
        bool xPressed() const;
        bool zPressed() const;
        bool cPressed() const;
        void update(sf::RenderWindow &);
};

#endif /* inputController_hpp */
 

#include "inputController.hpp"

InputController::InputController()
        : left{false},
          right{false},
          up{false},
          down{false},
          x{false},
          z{false},
          c{false}
{}

bool InputController::xPressed() const {
        return x;
}

bool InputController::zPressed() const {
        return z;
}

bool InputController::leftPressed() const {
        return left;
}

bool InputController::rightPressed() const {
        return right;
}

bool InputController::upPressed() const {
        return up;
}

bool InputController::downPressed() const {
        return down;
}

bool InputController::cPressed() const {
        return c;
}

void InputController::update(sf::RenderWindow & window) {
        sf::Event event;
        while (window.pollEvent(event)) {
                if (event.type == sf::Event::Closed) {
                        window.close();
                }

                if (event.type == sf::Event::KeyPressed) {
                        switch(event.key.code) {
                        case sf::Keyboard::Escape:
                                window.close();
                                break;

                        case sf::Keyboard::Left:
                                left = true;
                                break;

                        case sf::Keyboard::Right:
                                right = true;
                                break;

                        case sf::Keyboard::Up:
                                up = true;
                                break;

                        case sf::Keyboard::Down:
                                down = true;
                                break;

                        case sf::Keyboard::X:
                                x = true;
                                break;

                        case sf::Keyboard::Z:
                                z = true;
                                break;

                        case sf::Keyboard::C:
                                c = true;
                                break;

                        default:
                                break;
                        }
                } else if (event.type == sf::Event::KeyReleased) {
                        switch(event.key.code) {
                        case sf::Keyboard::Left:
                                left = false;
                                break;

                        case sf::Keyboard::Right:
                                right = false;
                                break;

                        case sf::Keyboard::Up:
                                up = false;
                                break;

                        case sf::Keyboard::Down:
                                down = false;
                                break;

                        case sf::Keyboard::X:
                                x = false;
                                break;

                        case sf::Keyboard::Z:
                                z = false;
                                break;

                        case sf::Keyboard::C:
                                c = false;
                                break;

                        default:
                                break;
                        }
                }
        }
}

 

[Laurent]

this is how I typically use event loops

Leaving the InputManager handle the whole event loop is questionnable. What about non-input events?
And it's also not clear why you track key press/release events manually and not use sf::Keyboard/sf::Mouse.

[Evan Bowman]

this is how I typically use event loops

Leaving the InputManager handle the whole event loop is questionnable. What about non-input events?
And it's also not clear why you track key press/release events manually and not use sf::Keyboard/sf::Mouse.

First, I don't use sf::Keyboard/Mouse because they don't work reliably on all operating systems. For example, for a fullscreen sfml app running on a 2014 macbook air and OS 10.11, if the computer suspends, upon waking sf::Keyboard/Mouse become unresponsive, but events still work. Maybe this is an isolated incident, but I would still be apprehensive about using them.

Additionally, I am defining all events as input here. Events would not appear to occur if a user were not interacting with the host computer, or a process were not interacting with the application, therefore events are arguably input. But that's more of a semantic thing.

I guess what I'm trying to say is this; I don't see the issue with moving the event loop from the main loop to a function called at the beginning of the the main loop. There is no significant difference.

Also, isn't tracking the events manually objectively faster? At least better than doing a system call for key presses for every iteration of the main loop in the 30 odd places I need to know if a key is pressed. Additionally, having a class wrap sfml input functions makes it easier for me to add joystick support. Rather than check for a joystick button and a key press everywhere, I can handle that internally in a centralized location, and have the input manager's accessor functions correspond to the current selected input device.

[Laurent]

First, I don't use sf::Keyboard/Mouse because they don't work reliably on all operating systems. For example, for a fullscreen sfml app running on a 2014 macbook air and OS 10.11, if the computer suspends, upon waking sf::Keyboard/Mouse become unresponsive, but events still work.

If you've found a bug then you should report it

Additionally, I am defining all events as input here. Events would not appear to occur if a user were not interacting with the host computer, or a process were not interacting with the application, therefore events are arguably input. But that's more of a semantic thing.

Ok I see. What I had in mind were window-related events: resized, lost/gained focus, etc. But yes, they can fit in if your definition of "input" is "event".

I guess what I'm trying to say is this; I don't see the issue with moving the event loop from the main loop to a function called at the beginning of the the main loop. There is no significant difference.

There's no issue, it was just a design question

Also, isn't tracking the events manually objectively faster? At least better than doing a system call for key presses for every iteration of the main loop in the 30 odd places I need to know if a key is pressed.

It certainly is faster. But I doubt anyone will get performance issues with this stuff At this level, it's better to use the cleanest/simplest solution (which is events for you anyway, because of the bug you explained).

Additionally, having a class wrap sfml input functions makes it easier for me to add joystick support. Rather than check for a joystick button and a key press everywhere, I can handle that internally in a centralized location, and have the input manager's accessor functions correspond to the current selected input device.

Yes, I never said it was bad to wrap SFML stuff

[Evan Bowman]

Also, isn't tracking the events manually objectively faster? At least better than doing a system call for key presses for every iteration of the main loop in the 30 odd places I need to know if a key is pressed.

It certainly is faster. But I doubt anyone will get performance issues with this stuff At this level, it's better to use the cleanest/simplest solution (which is events for you anyway, because of the bug you explained).

Yeah I agree, I've found horribly inefficient old code while refactoring some things lately, but if I'm not careful about limiting draw calls, things slow down right away

There's no issue, it was just a design question

Sorry about that, I took it a bit too seriously.