SFML 2.0 vector of drawable

[virelio]

Hi,

I was looking at the new API of SFML 2 graphics. It looks nice.

I used to manage text, sprite and shape with std::vector<sf::Drawable*>. Now there is no more common ancestor because they inherite from sf::Transformable too.

Is there a way to do such vector organisation with SFML 2.0 ?

best regard,

[Laurent]

What features do you need to use on the objects stored in your container? Which functions would you like to access?

[virelio]

Thanks for your (as usual) quick answer,

I used to add all my "drawables" and inherited objects in one vector ; then I can test each in queue and draw them without knowing if it's a text or a sprite. I have a vector<sf::Drawable*> and the right "render" was called.


I think that this class diagram is convenient to handle all "drawable". (You could have BaseDrawable and Drawable). I would like to inherite from "sf::Whatever"
You have, at least, to give a position to each "Drawable" you plan to draw, so Transformable is quite always here (unless you use fixed position VertexArray)

So what is your thought about this ?

Olivier/Virelio

[pdinklag]

I have thought about this exact connection between Transformable AND Drawable myself, and in the same context (polymorphism).

The question I couldn't find an answer to is what to call it... TransformableDrawable? Anyway, I would like if SFML could provide this additional abstraction layer. Not necessarily because it'd be better design or anything, but because of its practical use.

[virelio]

Hi !

I agree with you. Polymorphism is a powerfull C++ feature.

In SFML, you should use basic class to make your own while keeping the easy way to move and render. I think SFML is easy to use and manage except this little minus  :?

sf::Whatever only need one empty constructor and a virtual destructor... Am I right ?

best regard,

Olivier/Virelio

[Mikademus]

The two standard names for objects of this type (a graphical object that combines high-level facilities and act as a virtual base for subclasses) are Glyph and Body. I think there is already a sf::Glyph used for text drawing (and that name is also a bit abstract, specialised, overloaded and potentially confusing for some users) but Body might work. A very precise name would be Pictograph or Pictogram, which meaning in computers is "A symbol which is a picture that represents an object or concept". Otherwise GraphicsBody or GraphicsBase would be less academic or technical terms.

Anyway, even if there is no such intermediary class in SFML it could be achieved through a proxy/adapter class that uses templates and virtual dispatch to handle the concrete instances uniformly.

[Laurent]

sf::Transformable is provided for convenience, one can use a sf::Transform directly.

Code: [Select]

foreach (sf::Drawable* drawable, drawables)
    window.Draw(*drawable, transform);

[virelio]

Ok Laurent, I have to dive deeper in the API.

I glanced on... I'll test some basic. I'll be back to tell you my feeling.

thank you for your workssssss !

[virelio]

Back,

Laurent, Don't change anything it's perfect and incredibly easy !

You can mix all together if you want to draw with polymorphism. You can apply complex transformations very easily with sf::transform or sf::transformable appart of rendering.

I have to think how to rewrite my code but it sure give me more clearness...


 

Olivier/Virelio

[pdinklag]

Hm, true, since transformations are also part of render states, there is no problem really. You'd just have to manage your own structure keeping both the Drawable and the render states.

Got to arrive at SFML 2.0 property.

[Nexus]

Such a sf::Whatever class for high level entities is sometimes indeed useful, but I don't know if its worth to make the SFML inheritance hierarchy even deeper. It could also be added in a later version without breaking code.

For a quick solution, one can use a std::pair<sf::Drawable*, sf::Transformable*>. Or write an own class that derives from sf::Drawable and sf::Transformable and that is internally able to store sf::Sprite, sf::Shape and sf::Text via type erasure.

[virelio]

Hello !

via type erasure

How to do that ? I know you have to use template but I do not see how to write such  class... If I well understand, it's a way to create an common ancestor afterwards. Do I mistake myself ?

thanks in advance,

Olivier/Virelio

[Nexus]

A quick example:

Code: [Select]

class GraphicObject : public sf::Drawable, public sf::Transformable
{
public:
template <class D> // D can be sf::Sprite, for instance
explicit GraphicObject(D* derivate)
: sf::Drawable()
, sf::Transformable(*derivate)
, mDrawable(derivate)
{
// Reset transforms of original SFML object
derivate->SetPosition(0.f, 0.f);
derivate->SetRotation(0.f);
derivate->SetScale(1.f, 1.f);
derivate->SetOrigin(0.f, 0.f);
}

void Draw(sf::RenderTarget& target, sf::RenderStates states) const
{
states.Transform *= GetTransform();
target.Draw(*mDrawable, states);
}

private:
std::unique_ptr<sf::Drawable> mDrawable;
};
A side note: In case you need value semantics, you can use thor::CopiedPtr instead of std::unique_ptr. This smart pointer copies the object every time it is itself copied, even through polymorphic hierarchies. It is however not as flexible as it could be, I will improve (not to say reimplement) it in the future.

[virelio]

Thank you very much for this complete and clear example.

I've made one more step into c++

I've also read :
http://alp.developpez.com/tutoriels/type-erasure/ (in french)
http://www.cplusplus.com/forum/articles/18756/ (in english)

but your little example is far clearer for me.  

Olivier/Virelio