SFML1.6 to SFML2.1 brick wall #2. sf::Sprite FlipX and FlipY

[bobingabout]

Yeah, another one.

Most of my images are actually entire sprite sheets, consisting of a 2D array of smaller images.
This was done because changing the SubRect of a sprite was a very cheap and easy process, making it the most efficient means of making an animation I could think of.

think of a game like Terraria, rather than having seperately drawn images for facing left, and facing right, only one set is drawn, then the sprite is flipped to make them face the other direction, I used the same principle here.

So I looked for flipX... I can only find it in sf::Image...

Due to the fact that my Images are sprite sheets, where frame 0 is always in the top left, and flipX would move it to the top right instead, flipX on an image is definitely not an option, not even conceavable with maths. Plus an image is likely used by way more than just 1 sprite, so even if I were to flipX an Image, I'd basically need 2 images, 1 for normal, and 1 for flipped, keeping track of 2 Images, and 2 Textures per sprite.

So... this leaves me with 2 "logical" options.

1. Redraw every single sprite sheet to include a left facing and a right facing, and add lines to my config files to specify facings, doubling the size of my sprite sheets.

2. Forget SFML 2.1 and keep using SFML 1.6. Seriously, the lack of FlipX on sprite is a serious game-breaker for me.

and for the sake of it..
3. Someone show me how to add a flipX function to sf:Sprite, to make it work in SFML2.1 as it did in SFML1.6.

[Laurent]

Revert the texture coordinates by "inverting" the texture rect:

sprite.setTextureRect(sf::IntRect(right, top, -width, height));

[Nexus]

Seriously, the lack of FlipX on sprite is a serious game-breaker for me.

No, it's not. FlipX/FlipY were just redundancies in the API. Even now, you still have multiple options to achieve the same thing. Either you do as Laurent suggested, or you use a negative scale factor (in this case, it will be an advantage if the origin is centered).

[bobingabout]

Revert the texture coordinates by "inverting" the texture rect:

sprite.setTextureRect(sf::IntRect(right, top, -width, height));

Perfect answer there sir.
A simple check on a stored "Flipped" bool flag will allow me to choose weather I use positive or negative width.

Seriously, the lack of FlipX on sprite is a serious game-breaker for me.

No, it's not. FlipX/FlipY were just redundancies in the API. Even now, you still have multiple options to achieve the same thing. Either you do as Laurent suggested, or you use a negative scale factor (in this case, it will be an advantage if the origin is centered).

Perhaps I should have worded my statement a little better, it isn't the specific function FlipX/FlipY that is required, but an easy means on reproducing the effect.

The answer supplied by Laurent is basically my option 3: he explained to me how to recreate FlipX on an sf::Sprite object.

Small untested example.

Code: [Select]

FlipX(bool flipped)
{
Flipped = flipped; //store it in my class
if((flipped && getTextureRect().width > 0) || (!flipped && getTextureRect().width < 0))
{
sf::IntRect rect = getTextureRect();
rect.width = -rect.width;
setTextureRect(rect);
}
}
of course with something so simple as this, I'd need to encorporate the -width functionality into all my functions that change the SubRect as well, hence why I stored flipped in my class in the example.

[Nexus]

There's nothing that prevents you from providing global functions

void flipX(sf::Sprite& sprite, bool flipped);
void flipY(sf::Sprite& sprite, bool flipped);

for ease of use.

If you don't want the texture rect to be affected by the flipping, then use the scale approach.

[bobingabout]

There's nothing that prevents you from providing global functions

void flipX(sf::Sprite& sprite, bool flipped);
void flipY(sf::Sprite& sprite, bool flipped);

for ease of use.

If you don't want the texture rect to be affected by the flipping, then use the scale approach.

Already half way done adding it to my AnimSprite class. Though I'll have to go back to my collision detection and add in compensation to ignore the sign on width and height. I think there's a function in math.h to strip a sign, but I can't remember it's name. Still, an easy fix.

I thank you for your sugestion though, your help is much apreciated.

[Nexus]

I think there's a function in math.h to strip a sign, but I can't remember it's name.

std::abs()

And use the C++ header <cmath>, not <math.h>.

[bobingabout]

-width in the texturerect didn't work.
-# in scale did.

[G.]

If it didn't work you did it wrong.
Did you notice that the first argument of the IntRect is the right value instead of the left value for an unflipped sprite?

[bobingabout]

Did you notice that the first argument of the IntRect is the right value instead of the left value for an unflipped sprite?

nope x3

which makes sense, it was likely trying to draw a sprite off the left hand side of my image. if I was using it on a full sprite sheet (instead of a verticle tower sprite sheet that I was using in this instance), it would likely have worked, with a blank frame every now and then.

perhaps this might work:

Code: [Select]

FlipX(bool flipped)
{
Flipped = flipped; //store it in my class
if((flipped && getTextureRect().width > 0) || (!flipped && getTextureRect().width < 0))
{
sf::IntRect rect = getTextureRect();
rect.left += rect.width; //this line added
rect.width = -rect.width;
setTextureRect(rect);
}
}


[Nexus]

I don't want to annoy, but is there a specific reason why you don't use the scale?

Because then, checking for a sprite being flipped would be as simple as checking the sign of the scale components, and the flipping operation would correspond to negating these components.

[bobingabout]

I don't want to annoy, but is there a specific reason why you don't use the scale?

my current code:

Code: [Select]

void CAnimSprite::flipx(bool flippedin)
{
flipped.x = flippedin;
sf::Vector2f scale = getScale();
if(flippedin && scale.x > 0 || !flippedin && scale.x < 0)
{
sf::Vector2f center = getOrigin();
scale.x = -scale.x;
center.x = getimagesize().x - center.x;
setScale(scale);
setOrigin(center);
}
}
It even compensates for an origin that's off center.

I just want to try it both ways.