Changing Image of a Sprite do not work

[Mr. X]

If I have a Sprite with an Image and I change the Image by

Code: [Select]

Sprite.SetImage(Img);
the Image is cut at the left and down side if it is bigger than the old one.
A workaround is

Code: [Select]

Sprite = sf::Sprite(Img);
but I think that is inefficient.

Is that a bug or a feature that the size of the new image is not assumed?

[Groogy]

Looks weird? Should be that the new size is set by itself.
A better workaround for that is that you set the Subrect yourself.

Code: [Select]


Sprite.SetImage(img);
Sprite.SetSubRect(IntRect(0, 0, img.GetWidth(), img.GetHeight()));


I think that should make it a bit more efficent than making an entire new sf::Sprite instance.

[Laurent]

It's not a bug, the fact that you want your subrect to automatically grow to display the whole new image is a special case, not a general behaviour. The subrect is a property which is separate from the source image, and there are a lot of situations where you want to keep your subrect constant while changing the source image (an animation, a skin, ...).

[Mr. X]

Maybe it would be a good idea, to change the function:

Code: [Select]

Sprite::SetImage(const sf::Image &Img, const bool ChangeSize = true) {
    //Functions code...
}

[Laurent]

And what if the subrect does not cover the old image? Do I keep the same ratio, or do I just ignore it and take the full size of the new image anyway?

Moreover, I think I'll get at least as many posts from users who do NOT want to have the subrect adjusted, and I'll keep on telling them to use the second parameter

I prefer keeping these properties separated, and let the user decide how he wants to link them together.

[Groogy]

So use the thingy I gave you ^^
Come on it's only 1 more line of code.

[Hiura]

Anyway, making you own function is very easy :

Code: [Select]

void ChangeImage(sf::Sprite& s, const sf::Image& i) {
    s.SetImage(i);
    s.SetSubRect(sf::IntRect(0, 0, i.GetWidth(), i.GetHeight()));
}

[Tank]

I'd also prefer to have at least an option to automatically apply the new image size. It's the behaviour I would expect when doing it. Just my 2 ct here.

[Laurent]

It's the behaviour I would expect when doing it

That's the problem. If I switch to a different default behaviour, I'll get as many posts from people that do not expect it. So I just keep things simple and people do their own stuff on top of it.
Just try to imagine the point of view of someone using images composed of several sub-images, like animations, skins, tilesets, items, ... such people won't expect all their sprites to grow to the whole image size just by changing the source image (which can be a "theme", or a different color for player 2, etc.).

[Tank]

If I switch to a different default behaviour

Nobody claimed that. It's okay like it is. But in my opinion a second parameter with a default value (that results in the current default behaviour) would solve the problem.
Of course an own function can be a workaround. But in this case I really think SetImage() should provide that functionality, since many people expect it (not proven, of course).

Edit: Also, when I expect that the sprite gets resized automatically, but it doesn't, and then looking at the documentation for finding out what the heck is going on, I'll find an immediate solution, which just works perfectly.

[Aval]

I'm working on a strategy game right now, and I simply make a sprite of the spritesheet, and set a subrect to whatever animation frame it is doing. If the unit's image is changed, the subrect would stay the same. It simply makes sense that it does that. Changing the image changes the image.

[Imbue]

I'm also using the library like Aval. I do several image changes, and I certainly don't want the sub-rect jumping around on me.

I think the rest of you guys should use Hiura's function, or use images of the same resolution. Isn't it kind of sloppy to be changing image resolutions anyway?

[Tank]

I don't get your points. Nobody's claiming that the default behaviour of SetImage() should change, it's okay like it is at the moment.

But I could also argue that when constructing a sprite, it's initial size should be (0, 0), independent from the image's size, because dimensions should not change when setting a new image (and personally I think that constructing an sf::Sprite with an sf::Image is for this matter the same as just setting a new image). But whatever, different people have different meanings of this, so none of both behaviours is correct, instead Laurent has to define the default behaviour depending on his meaning, which is perfectly fine.

Personally, I would expect that when I set another image for a sprite, it will get drawn completely, which is the most natural behaviour (change image, see image). But again, this is only my meaning of setting a new image.

To elimate this problem, thus satisfying all people, SetImage() could get a new parameter, for example "bool ChangeSize = false". And like you see in the signature, the size wouldn't be changed by default, since the default value is set to "false". That won't break compatibility, but support people having a different meaning of SetImage(). Also, that feature would be absolutely easy to find, since when I'm changing an image and recognize it doesn't change the sprite's size, I'll lookup SetImage() in the Doxygen docs, where I'll find that second parameter with a slight description. Voila!

Edit: Regarding to this:

I think the rest of you guys should use Hiura's function, or use images of the same resolution.

Laurent has declined some small enhancements in the past, thus forcing me to write a lot of those small functions, which are sometimes really elemental. But in this case, a second parameter wouldn't bloat the API nor be useless.
And: why should I *always* use images of the same resolution? That highly depends on what you're actually doing. Animations mostly work fine with that, but these can also have frames with different sizes, where you'd be happy to write "blah.SetImage( frame[5], true )", wouldn't you?