Conteneur de sf::Drawable - fonction draw()

[Zekko]

Bonjour à toutes et tous !
J'aimerais créer une classe héritant de sf::Drawable dont la fonction est de contenir des sf::Drawables.
Elle hérite donc de sf::Drawable, de sf::Transformable et de std::vector<sf::Drawable*> puisque qu'il s'agit d'un conteneur.

Fichier Container.h :

(click to show/hide)

class Container : private std::vector<sf::Drawable*>, public sf::Drawable, public sf::Transformable
{
public:
    Container();
    ~Container();

    sf::Drawable* addElement(sf::Drawable& element);
    void removeElement(size_type n);
protected:
    sf::RenderTexture m_texture;

    void update();
    virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;
};

Fichier Container.cpp :

(click to show/hide)

Container::Container()
{}
Container::~Container()
{}

sf::Drawable* Container::addElement(sf::Drawable& element)
{
    push_back(&element);
    update();
    return back();
}
void Container::removeElement(size_type n)
{
    Container::iterator it(begin());
    it += n;
    erase(it);
    update();
}


void Container::update()
{
    m_texture.create(/* Que mettre ici ?? */);
}
void Container::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    sf::Vertex vertices[4];
    vertices[0].position = sf::Vector2f(0, 0);
    vertices[1].position = sf::Vector2f(0, m_texture.getSize().y);
    vertices[2].position = sf::Vector2f(m_texture.getSize().x, 0);
    vertices[3].position = sf::Vector2f(m_texture.getSize().x, m_texture.getSize().y);

    states.transform *= getTransform();
    states.texture = &m_texture.getTexture();

    target.draw(vertices, 4, sf::TrianglesStrip, states);
}

Le problème vient de la fonction update(). En effet, pour remplir ma sf::RenderTexture, il me faudra utiliser la méthode create(unsigned int width, unsigned int height, bool depthBuffer=false). Mais quelles dimensions lui donner ?
Ou plutôt : Comment connaitre les dimensions des sf::Drawables du conteneur ?
Car par leur nature, je n'ai pas accès aux fonctions des sf::Transformables comme getGlobalBounds().
Et si je fais un conteneur de sf::Transformables*, je ne pourrais pas utiliser la fonction draw()...

Je tourne en rond et je n'en vois plus le bout...
Quelqu'un a-t-il une solution ?

[victorlevasseur]

std::vector<sf::Drawable*> puisque qu'il s'agit d'un conteneur.

Mauvais idée, il faut plutôt une variable membre qui est de type std::vector<sf::Drawable*>.

[Zekko]

std::vector<sf::Drawable*> puisque qu'il s'agit d'un conteneur.

Mauvais idée, il faut plutôt une variable membre qui est de type std::vector<sf::Drawable*>.

Ah bon ? Pourtant ici l'héritage me semblait approprié, ainsi l'utilisateur de la classe aurait eu un contrôle plus fin sur le contenu avec les méthodes héritées des std::vector ... Et ma classe étant un conteneur, ça paraîtrait logique qu'on puisse effectuer les mêmes opérations que sur un conteneur classique, avec cependant les fonctionnalités de sf::Drawable et de sf::Transformable en plus.


De toute manière, d'une façon ou de l'autre, le problème reste inchangé : je n'ai pas accès aux bounds des sf::Drawables.

[Zekko]

Je vois deux solutions à mon problème. Cependant, il faudrait pour cela modifier la SFML.


La première serait tout simplement d'inclure dans sf::Drawable une méthode pour avoir les bounds de l'objet. Par définition, un sf::Drawable peut être dessiné et possède donc des bounds accessible. Cela n'est cependant pas dans la vision SFML de la gestion de GUI.

Pour palier l'inélégance de la solution précédente, on pourrait créer une classe "interface" qui se contenterait d'hériter de sf::Drawable et de sf::Transformable. On aurait ainsi un conteneur de sf::DrawableTransformable dans lequel on aurait accès aux méthodes getGlobalBounds() etc. Il faudra alors se passer de sf::VertexArrays, ou alors les rendre transformables.


Je ne sais pas s'il existe des solutions à mon niveau d'utilisateur de la SFML, mais si vous en avez, n'hésitez pas à m'en faire part. Sinon, je n'ai plus qu'à espérer une évolution de la bibliothèque dans ce sens et me contenter en attendant d'un code non modulable...