View wont move.

[ostkaka]

My class Camera : public sf::View stopped to work properly after I updated to sfml 2.0. It worked with sfml 1.6. In the constructor I can change its size, rotate and move it. But then it wont do anything of that in its methods  .

This is the method I use:

Code: [Select]

void Camera::Update(App& app)
{
if (currentEntity != nullptr)
{
float deltaX = currentEntity->getX()+8-getCenter().x;
float deltaY = currentEntity->getY()+8-getCenter().y;
float speedFactor = atan(app.getFrameTime()*speed)*2/3.14159265358979323846264338327950288419;

std::cout << speedFactor << " ;( ;( ;( :(\n";

setCenter(getCenter().x + deltaX*speedFactor, getCenter().y + deltaY*speedFactor);
}
}
What's wrong? 

[hipsterdufus]

I was actually working on the same problem with my code, planned to get back at it tonight. I'll let you know if I figure anything out. I've never had a working view before though, this is my first shot at it. It just seemed like setCenter wasn't doing anything for me.

[mateandmetal]

Why dont you use aggregation instead of inheritance?

Inside your class:

private:
    sf::View m_view;
 

[ostkaka]

It's easier with camera.getCenter(). 

[hipsterdufus]

I figured out that you have to call setView on your window (EACH TIME YOU CHANGE THE VIEW LOCATION) after calling setCenter on the view. After reading the documentation I was under the impression you just had to set the view to your window and any subsequent changes to it would automatically be binded to the window. In any case, this is what you have to do each frame:

m_View.setCenter(<vector location>)
mWindow.setView(m_View)

Let me know if that works for you.

[Laurent]

Wow, it seems that the more I emphasize an important point, the less people see it.

From the tutorial, in a big red box:

When you call setView, the render-target keeps a copy of the view, not a pointer to the original one. So whenever you update your view, you need to call setView again to apply the modifications.

This is really disappointing, I've spent one year to rewrite the complete set of tutorials, trying to put every important point in them.

 

[binary1248]

Wow, it seems that the more I emphasize an important point, the less people see it.

From the tutorial, in a big red box:

When you call setView, the render-target keeps a copy of the view, not a pointer to the original one. So whenever you update your view, you need to call setView again to apply the modifications.

This is really disappointing, I've spent one year to rewrite the complete set of tutorials, trying to put every important point in them.

 

You try too hard to document SFML well . You should adopt the SFGUI documentation philosophy, minimal doxygen and tell people to go read code if they want more information .

On a serious note, you shouldn't be surprised if people "overlook" such things or don't read the documentation properly or at all. Since you intend on making SFML so easy to use, even for beginners, people get the impression that their auto-complete is all they need to get something done, even when switching from 1.6 to 2.0 . You need to add booby traps to the interface to force people to read every single word of the documentation/tutorials and lock threads that are created because they failed to do so. We all know it's in everyone's best interest if people learn to do a bit of (proper) troubleshooting on their own . A side effect of this is a lot of hate that will circulate, but everybody knows that negative emotions drive humans to do things more than positive ones .

[hipsterdufus]

Heh, sorry. I was just looking at the API documentation for sf::View, not the tutorial. Guess I should look there more often.

In any case, SFML is the easiest library I've ever used. The tutorials and documentation are super easy to read.

[ostkaka]

I read the tutorial, but I missed that somehow.