VertexArray drawing in wrong location

[pbortler]

I've been fighting with this for a few hours now, and I can't figure it out. I ended up making a bunch of debugging textures just to see what was going on, and I finally realized that sf::Sprite and sf::VertexArray think that position (0.f, 20.f) is different.

My vertex array is a 4 vertex Quad where the texture coords are the image corners, and the position coords are the image corners which are supposed to be offset by getPosition(), but when I call setPosition(0.f, 20.f) (which does indeed set the sf::Vertex::position value to (0.f, 20.f) it draws at (0.f, 40.f).

If I set the position to (0.f, 0.f) then it draws at (0.f, 0.f).

The Sprite is as simple as it can be. Load a texture of a small red rectangle, then set it's position to (0.f, 20.f).

The result is the following image (forum image links are apparently broken):

https://imgur.com/a/7Sizy6q

Why is this happening? I'm not using setScale() anywhere in my code. If I set the position of the sf::VertexArray to (0.f, 10.f) then it lines up, so it's screaming scaling error, but I am not setting a scale anywhere at any time.

How do I get sf::VertexArray coords of (0.f, 20.f) to draw 20 pixels down from the top of the window? Thanks.

edit: Apparently if I remove the line "states.transform *= getTransform();" from draw() it puts the vertex array in the correct position. Why would this cause the issue? isn't setting the transform on the renderstate required?

edit2: Apparently removing the aforementioned line breaks all over transformations like scaling, which makes sense. How the hell do you set the position of a transformed entity?!

edit3: Ugh, I finally figured it out. I really wish things like "Don't account for position in your position code" were more clear with SFML.

[Hapax]

Although you haven't actually shown any code or mentioned what you did to fix this, I'll try to clarify something that you may have overlooked.

When setting co-ordinates for a vertex array, they are "local" co-ordinates.
If they aren't transformed, the global co-ordinates are the same.
However, if those local co-ordinates are transformed (such as setting an offset from (0, 0) with setPosition), the global co-ordinates (where they actually end up) are the transformed versions.

Basically, if you want vertices to be exactly where you put them, don't transform them. This goes for anything you get from inheriting from sf::Transformable, including setPosition.
In this case, if you want to move a single vertex, change that one vertex. If you want to move all vertices, change all vertices together manually.

If you do want to be able to transform them, you should (most likely) approach the vertex co-ordinates in a different way. That is, design the shape at - or around - (0, 0) and then transform them together. For example, you could setPosition to move what was at (0, 0) to the new position and the other vertices would follow.

A compromise - and would possibly fix your problem temporarily (until the next time) - would be to place your vertices where you want them, then set the origin to where you think you would describe the entire vertex array's position, and then you can set the position to that position too.
For example, in what I estimate you are experiencing, you could setOrigin to (0, 20) and then set the position to (0, 20).

[pbortler]

Hapax, I think you have the right idea. I'll try to explain my view of it now.

Transformations in SFML will account for translations (movement), rotations, and scaling (making bigger or smaller). This means that if you derive from sf::Transformable and apply the getTransform() while rendering, then you mustn't account for any of these while determining either the texture coordinates, or the object's position.

It's pretty straight forward once you realize what the result of getTransform() is responsible for, and why it would lead to errors trying to account for these factors more than once.

[Hapax]

Sounds about right....

...except for texture co-ordinates. They are not transformed. They should always be the co-ordinates within the texture that you want for that vertex. The transformations can move the vertex positions, not the texture co-ordinates*.



* in standard situations. Shaders can affect this.