Really this is two suggestions, but they are tightly coupled to each other.
Convert MouseX/Y to worldX/Y.
This would have be done through the view. I suppose it could be done through the sf::RenderWindow, but that would artificially limit which views could be used to translate the coordinates. I am not suggesting this be done automatically, but be provided as a method of the sf::View class.
The major hurdle here is the View will need to know the screen dimensions to correctly convert the coordinates. I would suggest passing the App as a reference to the method so that it can access the window dimensions. Or if that is sharing too much information, just a sf::Vector2i that stores the X and Y dimensions of the window.
This is just boring when the user has a default view. It is a nicety when using a custom view, It is very useful if the custom view is scaled or a different size than the window, It is absolutely necessary if the View where allowed to rotate.
-
Rotating sf::View
Allow the sf::View to rotated. It's very simple at the OpenGL layer, but a bit more complicated at the SFML API layer. The View would be defined as a lookAt point, a view width and height, and a rotation. This provides absolute flexibility with how the View is placed.
The current way sf::View is defined (Right, Top, Left, Bottom) is incompatible with a rotating view. So I would suggest a new class sf::ViewEx or whatever the name doesn't matter. The old sf::View class would inherit from sf::ViewEx and constrain it to hide the new functionality.
-
Why do I care:
In my game the players are playing on circular world, a planet. Gravity is not +/-Y, it is to the center. When a player is on the "south" side of the world I want to rotate the view so that all the controls work as he would imagine, left button moves his player left on the screen.
I was performing translations in game. Then I got to problem of mapping the screen coords back to world coords. It's difficult once you through in rotations. There is a function gluUnProject that does all this for you. However, this information is abstracted away in the library (thank goodness). Which means the library is in much better situation to perform the call than I am.
-Nick
