Messages

1

Graphics / Re: The "design" of sf::View is broken.

« on: October 20, 2013, 11:46:21 pm »

Yes, I understand that storing a reference is "bad" design, because you can incur in a lot of problem. I never meant that. But what I really meant is: why not store the sf::View within the classes that needs it (for example sf::RenderWindow), as I believe is right now, and be able to return a reference to it that is not constant.

Here's an example:

namespace sf {
    class RenderWindow {
    private:
        View m_view;
    public:
        // ...
        View& getView(); // this is key point here, this is the function I'd like
        const View& getView() const; // this already exists
    };
};

If sf::RenderWindow stores a copy (as apparently it does) why not allow to modify that copy? The above design is constant correct and avoid the creation of a new sf::View every time you have to really modify the current one.

By the way, performance is definitely not a concern here, and thus not a relevant factor for the design.

I agree that the performance loss of copying a sf::View in most cases can be ignored. But if you have a clean way to do something better, don't you do it just because it is not a relevant factor perfomance-wise?

2

Graphics / The "design" of sf::View is broken.

« on: October 20, 2013, 09:59:18 pm »

Considering a 2D game in which the camera is supposed to move often (actually at every frame). Why is the design of sf::View made so that the only way to edit an sf::View (e.g.: move it by a certain offset) involves the copying, the editing and the setting of the new view?

Does:

    sf::View copy = window.getView();
    copy.move(x);
    window.setView(copy);

makes more sense then:

    window.getView().move(x);

?

Also, what does it mean that sf::View is supposed to be used "by value"? What does it really contain? Why does it need to be used by value?

- Thanks