sf::View

[akhena]

I'm starting to use SFML2. I'm a bit surprised that the View in a RenderWindow is not a reference to an external view, but a copy of the View passed to the SetView method. I was expecting that one could use some code like this :

Code: [Select]


sf::RenderWindow window(sf::VideoMode(800, 600), "SFML test");
sf::View camera(sf::FloatRect(0.f, 0.f, 800.f, 600.f));
camera.SetViewport(sf::FloatRect(0.f, 0.f, 1.f, 1.f));
window.SetView(camera);

//and then later on
camera.Move(20.f, 0.f);
//But nothing happen until I call
window.SetView(camera);


Did I miss something ? Is there a design reason for not holding a reference but a local copy of the View object ? Thanks for clarifying.  

[Nexus]

Is there a design reason for not holding a reference but a local copy of the View object ?

The sf::RenderWindow can hold an independent view, and the user doesn't have to worry about its lifetime. Plus, you can pass temporary sf::View objects to SetView().

The semantics have changed in SFML 2, you will find some threads where this was discussed.

[akhena]

Ok, thanks.

Just also wondering why not make a non-const GetView() ? Is that also too "dangerous" ?

[Nexus]

Just also wondering why not make a non-const GetView() ? Is that also too "dangerous" ?

"Get" methods primarily return the object. A non-const reference would also allow to modify it (by accident or not), which is actually SetView()'s task.

The problem is, you reveal implementation details when you return references to non-constant objects. Like this, the sf::View must be a member variable of sf::RenderWindow, which prevents changes in the implementation. Additionally, it is not possible to check the validity of a view when modifying it.

SFML uses a typical practice concerning encapsulation and separation of read/write access. Generally, getters returning non-const references are rather rare.

[akhena]

All this makes sense. Thank you.

But then didn't we just bury the public interface of sf::View into the sf::RenderWindow ? Take for instance the

Code: [Select]

void sf::View::Move( const Vector2f & offset )  member function. You cannot apply it directly on the View of the window. You must create another View on the side, which is a replicate of the window View, move it, and every time copy it back with SetView().

Is it how it is intended to work ?

As a side question, I was wondering if the View makes any culling from the part of openGL. I guess yes, but as I'm no expert, I was wondering if it is more efficient to only draw what will be visible, or if the "graphic engine" takes care of that.

[akhena]

No answer on this one ? Is the question too "stupid" ?  :cry:

[Laurent]

You cannot apply it directly on the View of the window. You must create another View on the side, which is a replicate of the window View, move it, and every time copy it back with SetView().

In fact you're supposed to store and maintain your own copy of the view, instead of retrieving the current one everytime you want to change it.

As a side question, I was wondering if the View makes any culling from the part of openGL

No, so yes it is often a good idea to skip what's not in the view.