Rotating a sprite about a point?

[Nexus]

No, you cannot use sf::Transform with sf::Sprite. sf::Sprite is a high-level class with a simplified API, which is enough for most purposes.

If you need more, take the low-level classes sf::Transform, sf::Vertex and sf::VertexArray.

[FRex]

You can pass transform to draw while drawing sprite.

[Laurent]

What I meant by order of operations is that, for example, I can't translate1, rotate, translate2.   The first translate will just never happen.

And I realize the API is called 'move' and 'setPosition', but in my head it's still just a glorified translate.

No it's not. It is exactly what it means: the position of the entity. Not a translation that could occur anywhere in a transform chain, and would depend on what has been done before.

And this is exactly what the component approach is: you set the final position, orientation, scale of the entity. You don't combine custom transformations to produce the final one. It is a totally different approach -- even though it internally uses the same low-level class.

What's important with this approach is that you can get the transformation components back.

Unless you mean by passing a transform in directly to RenderTarget::draw?

This is what I mean, yes.

That did work, it just feels clunky to me.  Not the draw aspect, I like that API, just having to do that instead of dealing directly with the sprite feels clunky.

Dealing with a custom transform directly in the high-level entities (such as sf::Sprite) would have major drawbacks, number one being the inability to get the position/rotation/scale as I said above.

If I missed something, please let me know, but otherwise I doubt I'll be using the Transformable API.  For me it isn't about simple needs as much as I understand the use of the Transform stuff better than the Transformable stuff.  The limitations of it are a bit wacky to me.

So I think SFML did its job wonderfully: you were able to find a set of classes/functions that exactly fit your needs

[ichineko]

And this is exactly what the component approach is: you set the final position, orientation, scale of the entity. You don't combine custom transformations to produce the final one. It is a totally different approach -- even though it internally uses the same low-level class.

This is why I think the extra documentation is so important.  To me, when I see something 'high level' like a sprite, I think of something I can push and pull around the screen, not necessarily something that's meant to save the final combination of translation, rotation, and scale.  Documentation explaining how it's meant to be used can go a long way to prevent someone from wasting time on it.

Unless you mean by passing a transform in directly to RenderTarget::draw?

This is what I mean, yes.

So that's one part of SFML I do like.  I haven't really dug into the view/viewport stuff yet, but the ability to specify a final transform that goes into the draw is fairly elegant.  It's always there but you guys leave it open and available in a structured manner.

So I think SFML did its job wonderfully: you were able to find a set of classes/functions that exactly fit your needs

There's a lot I like about SFML, but there's also things I don't.

[Laurent]

This is why I think the extra documentation is so important.

I know. It's frustrating to have to answer this kind of questions on the forum, because I know that everything will be explained in the tutorials -- I just have to write them

So that's one part of SFML I do like.  I haven't really dug into the view/viewport stuff yet, but the ability to specify a final transform that goes into the draw is fairly elegant.  It's always there but you guys leave it open and available in a structured manner.

Thanks. You can't imagine how long it took me to redesign the drawable API, trying to make things simple and flexible enough for both high-level and low-level usage.

There's a lot I like about SFML, but there's also things I don't.

And I'll always be happy to talk about things you don't like