ability to use rotated images with setTextureRect

[binary1248]

And what about shapes? If we go this way, there's no reason to limit shape texturing to an AABB rectangle, we should be able to set each point's texture coordinates as well.

Isn't this a good thing? We don't want to limit peoples' creativity just because we aren't as creative as them . This would also solve the "cookie cutter" problem where a texture might not be properly spanned across a polygon if it isn't a quad, since that is currently the assumption of shape texturing.

Now for the implementation... sf::Sprite's local geometry is directly deduced from the texture rectangle. What if now we can set any shape composed of 4 points? The sprite will no longer be a quad.

This is also a good thing to have. Imagine how happy all of the people making isometric tile games would be if they could have sprites that are rhombuses instead of quads. Tighter texture atlas packing, less overdraw (more GPU performance) and less headaches among many other things.

[kimci86]

Hi,
In my humble opinion, this feature already exists with sf::VextexArray.
What do you think ? Are you against using it ?

[thomas9459]

In my humble opinion, this feature already exists with sf::VextexArray.
What do you think ? Are you against using it ?

There are many cases where an sf::Sprite would be preferred because of the other functions provided by the class, especially the rotation/position/origin ones.

[wintertime]

Why is this needed so much when in the end the output from rotating the texture coordinates would look the same as rotating the sprite? Some adjustment to client code would always be needed when using such a weird rotating texture packer.

[superjoe]

Why is this needed so much when in the end the output from rotating the texture coordinates would look the same as rotating the sprite? Some adjustment to client code would always be needed when using such a weird rotating texture packer.

It's not weird. Many texture packers have this feature.

[binary1248]

I think the question is whether SFML should explicitly support rotating texture rectangles because of these packers, whether it should leave the image rotating to the user to do in their code (e.g. somewhere in a resource manager) or whether SFML should support generic texture source specifications like I proposed. I still feel like if we were to implement something that made texturing sprites more flexible, we should go all the way, for the reasons I already mentioned. Locking rotations to multiples of 90 degrees sounds too much like catering to a specific subset of packers. After all, there might be obscure packers that rotate sprites in angles that are not multiples of 90 degrees... what do we do then?

[Laurent]

The good thing with rotated rectangles is that modifications to the public API are minimal, while providing a feature which can be useful in multiple areas.

The full flexibility of providing the 4 texture coordinates directly solves more obscur problems, makes the public API and implementation much more complicated, for something that can already be done easily with vertex arrays. Don't forget that sprites are just a higher-level abstraction, the class itself exists only to makes things simpler, it doesn't do anything that can't already be done with vertex arrays. Making it more complicated would make it quite useless.

[binary1248]

The most "annoying" thing about using an sf::VertexArray instead of a regular sf::Sprite is the fact that sf::VertexArray isn't derived from sf::Transformable like sf::Sprite is. Even if you mean to use it as a rigid body, which implies that all rigid body transformations are applicable to it as well, SFML doesn't allow you to do that. I can't tell how annoying this is to those who actually care because I don't make extensive use of it myself, but I can imagine that some people might be put off by the fact that they have to sacrifice the transformable interface just because their texture data doesn't fit perfectly to sf::Sprite's assumptions.

[Laurent]

class MyFlexibleSprite : public sf::Drawable, public sf::Transformable
{
    ... vertex array ... texture coordinates ...
};

[superjoe]

Locking rotations to multiples of 90 degrees sounds too much like catering to a specific subset of packers. After all, there might be obscure packers that rotate sprites in angles that are not multiples of 90 degrees... what do we do then?

I don't think this makes sense. Rotating 90 degrees you're guaranteed to be able to fit all the pixels in there perfectly and pretend that you never rotated the texture. Any other value and you give up 1:1 pixel mapping.

[binary1248]

I guess if sf::Sprite were to be limited to usage with axis-aligned sprite sheets your code would be fine with me as well .

[Juhani]

probably with having, let say, top/left being the top right corner and a negative width and let SFML do the work (for a 90 CW rotation) but probably too much hassle.

IMHO this is a good idea.

Edit: Just realized that this would cause mirroring but not rotating.

How about taking as arguments the top left and bottom right corner? If bottom right is more left than top left the texture is rotated 90 degrees, if higher it is -90 degrees, and if bottom right is both above and left of top left 180 degrees.