Update origin in sprite before rendering?

[DasOhmoff]

Hi,

just wanted to ask if there is a way to update the origin of the sprite before drawing it.

This is not possible:

sf::FloatRect gb = sprite.getGlobalBounds();
sprite.setOrigin(gb.width / 2, gb.height / 2);
sprite.rotate(90);
sprite.setOrigin(0, 0);
 

I setted the origin to the center and rotated it but the rotation point is not in the center.
It rotates aroung the point 0, 0.
I think the code would work if the origin would not be updated when the sprite is drawen.

I NEED the origin to be at 0, 0 but I also want the sprite to rotate from in the center...

Is there a way to do it?

[Hapax]

The origin is the origin for all transformations. The rotate() method does not perform the rotation at that point, it performs it at the time of drawing, along with all the other transformations. So, when it gets to do all of the transformations, it uses what was last set for origin. If you want it to rotate around its center, first use getLocalBounds() to get the size (as getGlobalBounds() takes into account any transformations so far) and then don't reset the origin back to zero.

Can I ask why you need the origin at (0, 0)? You can simply offset its position.

[GraphicsWhale]

I NEED the origin to be at 0, 0 but I also want the sprite to rotate from in the center...

No, you don't. Or at least you shouldn't. What are you doing that you "NEED" the origin to be at 0,0? If you're properly separating logic from rendering, you shouldn't care about the translations/rotations that are necessary to place a sprite in a certain position on the screen.

I'm not aware of such a function that exists that does what you want. SFML's graphics module is just a wrapper around OpenGL (well, most of it), and you cannot rotate something in OpenGL around it's center without translating the center of the object so it's placed at the origin. Just how the matrices work. It could be abstracted to rotate around the center, but it would likely only complicate things. Also because the "center" of the sprite is a bit ambiguous.

[Nexus]

I NEED the origin to be at 0, 0 but I also want the sprite to rotate from in the center...

Is there a way to do it?

Use a custom sf::Transform when drawing the sprite. Highly inconvenient, but when you insist (probably unjustified) on a (0, 0) center...

SFML's graphics module is just a wrapper around OpenGL (well, most of it), and you cannot rotate something in OpenGL around it's center without translating the center of the object so it's placed at the origin.

There's no such thing as "object" or "center" in OpenGL, these are higher-level concepts.

SFML's graphics module is just a wrapper around OpenGL

As you see above, this statement is misleading. While SFML does wrap OpenGL, it adds a lot of additional higher-level functionality.

[GraphicsWhale]

There's no such thing as "object" or "center" in OpenGL, these are higher-level concepts.

They're higher-level concepts, but they still apply. You can't technically "draw a mesh" with OpenGL, either, you instead pass it an array of variables to rasterize into polygons. But that doesn't mean "I'm going to draw a mesh with OpenGL" is wrong in any way. By object, I mean the mesh or collection of meshes that make up a representation of an in-game entity.

I say object because it easier to understand "translate your object" than "tell SFML to set it the sprite's transformation matrix to translate".

SFML's graphics module is just a wrapper around OpenGL

As you see above, this statement is misleading. While SFML does wrap OpenGL, it adds a lot of additional higher-level functionality.

I said:

SFML's graphics module is just a wrapper around OpenGL (well, most of it)

I did not say that's all it did. It adds some other functionality, too, but in the end it mostly just simplifies OpenGL for 2D applications.

[Nexus]

They're higher-level concepts, but they still apply.

Your answer sounds like "SFML can't rotate around the center with a different origin being set because of a limitation in OpenGL" which is not true. It's not meaningful to talk about origins, centers and objects at an OpenGL level. This is entirely SFML's design, and if a limitation at all, then one in SFML. We could as well have chosen different origins for translation, rotation and scale, and it would have worked without a problem.

No big deal, I just wanted to clarify that

I said:

SFML's graphics module is just a wrapper around OpenGL (well, most of it)

I did not say that's all it did.

Yes, you said "just"

[DasOhmoff]

Thanks for you answers guys.

I understood what's the point.