Remove texture from sprite

[Haze]

I would like SFML users were able to remove a texture from a sprite, because sometimes a plain colored rectangle is just what you need.

I am thinking about something like :

Code: [Select]

void sf::Sprite::RemoveTexture();
or maybe :

Code: [Select]

mysprite.SetTexture(NULL);
by using a pointer instead of a reference.

[Laurent]

It would be weird because then you would set the sprite's size with a call to SetSubRect -- but a subrect of nothing.

Why don't you use a sf::Shape instead?

[Haze]

you would set the sprite's size with a call to SetSubRect -- but a subrect of nothing.

Nope, I would use sf::Sprite::Resize !

Why don't you use a sf::Shape instead?

1. When you just need to display a plain colored, border-less rectangle, I find sf::Sprite more convenient than sf::Shape (and aren't they lighter?). That's quick and easy :

Code: [Select]

sf::Sprite sprite;
sprite.Resize(10, 10);
sprite.SetSolor(sf::Color::Red);
But once you set a texture, you cannot go back to the previous behavior.

2. Also, let's say I'm using a sf::Sprite memory pool, some sprites use a texture, the others don't. I would like to "recycle" a textured sprite into a texture-less one.
I understand that sf::Sprite were meant to be used with a texture, but the API allows us to use sprites without any texture, until sf::Sprite::SetTexture is called...

[Laurent]

Nope, I would use sf::Sprite::Resize !

This function only changes the scale factors. The initial size (unscaled) is always computed from the subrect.

1. When you just need to display a plain colored, border-less rectangle, I find sf::Sprite more convenient than sf::Shape (and aren't they lighter?). That's quick and easy

It's even shorter with sf::Shape:

Code: [Select]

sf::Shape shape = sf::Shape::Rectangle(0, 0, 10, 10, sf::Color::Red);
Both have the same rendering complexity.

2. Also, let's say I'm using a sf::Sprite memory pool, some sprites use a texture, the others don't. I would like to "recycle" a textured sprite into a texture-less one.

Sprites (and texts and shapes) are lightweight objects, they have almost no internal data. You definitely don't need a pool for them, you're just adding complexity for no gain.

I understand that sf::Sprite were meant to be used with a texture, but the API allows us to use sprites without any texture, until sf::Sprite::SetTexture is called...

This inconsistent behaviour will be fixed in the new API, you won't be able to use texture-less sprites

[Nexus]

Nope, I would use sf::Sprite::Resize !

There is still a method SetSubRect() which is meaningless when the sprite has no texture. Operations that sometimes don't make sense often indicate a design flaw.

1. When you just need to display a plain colored, border-less rectangle, I find sf::Sprite more convenient than sf::Shape (and aren't they lighter?).

But that's exactly sf::Shape's task, sf::Sprite requires a texture.

I understand that sf::Sprite were meant to be used with a texture, but the API allows us to use sprites without any texture, until sf::Sprite::SetTexture is called...

That's a good point. I guess the intention was to allow default-constructibality for delayed initialization. But from a strict class invariant point of view, the initialization should be enforced.

[Haze]

Both have the same rendering complexity.

Good to know!

Sprites (and texts and shapes) are lightweight objects, they have almost no internal data. You definitely don't need a pool for them, you're just adding complexity for no gain.

(off-topic) Am I? I was referring to my own sprite-based particle system, this memory pool was meant to avoid tens of thousands sprites allocations/deallocations and heap memory fragmentation, while the game I'm working one is hardly displaying more than ~2000 sprites at the same time.

This inconsistent behaviour will be fixed in the new API, you won't be able to use texture-less sprites

Well, I guess that settles my problem!
I'm also curious about this, are you planning to remove the default ctor?

But that's exactly sf::Shape's task, sf::Sprite requires a texture.

Got it, I will stick to sf::Shape now.

[Laurent]

I was referring to my own sprite-based particle system, this memory pool was meant to avoid tens of thousands sprites allocations/deallocations and heap memory fragmentation, while the game I'm working one is hardly displaying more than ~2000 sprites at the same time.

Ok I see. That makes sense. But I think you can easily handle two different kinds of pools, one for sprites and one for shapes.

Well, I guess that settles my problem!

With the new API your problem will even disappear: typically, for particle systems, you'll use the low-level API (sf::Mesh) rather than sprites and shapes.

I'm also curious about this, are you planning to remove the default ctor?

Nop. That would make the class almost impossible to use:
- you can't have fixed-size arrays of sf::Sprite
- you can't have a sf::Sprite as a class member, unless the class' constructor takes the texture as an argument
- etc.

[Nexus]

This inconsistent behaviour will be fixed in the new API, you won't be able to use texture-less sprites

I'm also curious about this, are you planning to remove the default ctor?

Nop. That would make the class almost impossible to use

But how can you remove this inconsistency when you keep the default constructor and with it the possibility to have invalid object states?

[Laurent]

But how can you remove this inconsistency when you keep the default constructor and with it the possibility to have invalid object states?

It will still be possible to have a sprite without a texture -- I don't know how to solve this without getting rid of the default constructor. But drawing such a sprite won't show anything, which will be more consistent with other classes (shapes with no point, texts with no string).

It's not perfect, but at least it's more consistent than the current code, where you can have a valid sprite with no texture, which "works" as you would expect, but you have no explicit support for this behaviour in the API.

[Haze]

With the new API your problem will even disappear: typically, for particle systems, you'll use the low-level API (sf::Mesh) rather than sprites and shapes.

Sounds great Thanks for these explanations.