convertir une sf::RenderTexure

[mazertys17]

Bonjour.

J'essaye, sans succes, de convertir une sf::RenderTexture en pointeur de texture, afin de l'afficher comme les autres textures...

    renderTexture.clear(sf::Color::Red);
    for(vector<EI>::iterator it = vectorEI.begin() ; it != vectorEI.end() ; it ++)
    {
        renderTexture.draw(*it);
    }
    renderTexture.display();


    EI_test.recoitTexture(renderTexture.getTexture());

 

Ce qui donnerait ceci pour mon EI (tristement appelée EI, mais c'est trop tard pour changer mon EntiteImage de nom...Ce serait d'ailleurs accorder trop d'importance a ces malades  ).

    void recoitTexture(const sf::Texture &texture)
    {
        *m_texture = texture;
    }

private:

virtual void draw(sf::RenderTarget& cible, sf::RenderStates states) const
{

            states.texture = m_texture;
            cible.draw(m_tableauVertex,4,sf::Quads,states);

}

    float m_z;
    sf::Vertex m_tableauVertex[4];
    sf::Texture *m_texture;


 

plantage. (j'ai aussi des problèmes avec mon debugg, ce qui n'aide pas )...

Ma facon de faire est-elle cohérente?

[Cpl.Bator]

Y a un truc qui ne va pas ici :

void recoitTexture(const sf::Texture &texture)
    {
        *m_texture = texture;
    }

Ma facon de faire est-elle cohérente?

Non , pourquoi stocker un pointeur ?
Ta méthode draw à un sf::RenderState : http://www.sfml-dev.org/documentation/2.2-fr/classsf_1_1RenderStates.php profite de ce paramètre pour lui passer la texture et vire ta "méthode" recoitTexture() & ton pointeur.

[Laurent]

Réfléchis un peu à ce que tu fais, ne pense pas qu'un code est correct juste parce qu'il compile

    void recoitTexture(const sf::Texture &texture)
    {
        m_texture = &texture;
    }

Ta méthode draw à un sf::RenderState : http://www.sfml-dev.org/documentation/2.2-fr/classsf_1_1RenderStates.php profite de ce paramètre pour lui passer la texture et vire ta "méthode" recoitTexture() & ton pointeur.

Mauvais conseil... à ton avis pourquoi est-ce que sf::Sprite et sf::Shape ont toutes deux une fonction setTexture similaire à la sienne ?

[mazertys17]

Merci pour vos réponses.

J'ai bien essayé :

    void recoitTexture(const sf::Texture &texture)
    {
        m_texture = &texture;
    }
 

mais il me dit un message d'erreur:

"error: invalid conversion from'const sf::Texture*' to sf::Texture*' [~fpermissive]

pourquoi stocker un pointeur ?

Pour trier facilement les images, avec un z order. Ça me permet, en occurrence, de gérer plein d'objet qui vont partager, par exemple, la même texture, et dont leur emplacement dans le jeu va changer (l'un passe devant ou derrière l'autre etc...) .Plutôt que de stocker une véritable texture, lourde de poid, pour chaque objet, autant envoyer l'adresse, non?

Enfin ça me rassure un peu que Laurent n'approuve pas ce conseil...car pour l'instant ca marche très bien.


ps : sympas ton avatar, Cpl.Bator 

[Laurent]

"error: invalid conversion from'const sf::Texture*' to sf::Texture*'

Donc... ton membre doit être un const sf::Texture* (ce qui est de toute façon plus propre puisque tu ne vas effectivement pas modifier la texture dans cette classe).

[mazertys17]

Bien vu 

ca marche ! (enfin de ce qui est de la compilation, pour la suite je vais voir ).

Merci 

[Cpl.Bator]

Mauvais conseil...

Dans je ne sais plus quel post il parlais de lumière & de shader , Le RenderState permet de "bindé" la texture , donc je ne vois pas en quoi dans son cas c'est un mauvais conseil puisque de toute façon il touchera au renderstate , il s'épargne une méthode pourrie et un pointeur...

Pour trier facilement les images, avec un z order. Ça me permet, en occurrence, de gérer plein d'objet qui vont partager, par exemple, la même texture, et dont leur emplacement dans le jeu va changer (l'un passe devant ou derrière l'autre etc...) .Plutôt que de stocker une véritable texture, lourde de poid, pour chaque objet, autant envoyer l'adresse, non?

Enfin ça me rassure un peu que Laurent n'approuve pas ce conseil...car pour l'instant ca marche très bien.

J'en perd mon latin , tu trie des sf::Image ? selon un z order ? moi , c'est mes entités que je trie avec un foncteur selon la position en Y , je ne m'occupe même pas de son image...

Autre chose, ta classe "EI" , c'est des sprites ? si oui , pourquoi ne pas faire hérité cette classe de sf::Sprite directement ?

[mazertys17]

moi , c'est mes entités que je trie avec un foncteur selon la position en Y

bah je le dis différemment, mais c'est pareil...

Autre chose, ta classe "EI" , c'est des sprites ?

non, c'est des chaines de vertex...

de toute façon il touchera au renderstate

La dessus, c'est possible. En tout cas, j'espère que ca ne me forcera pas a revoir tout mon système d'affichage  .

[Laurent]

Dans je ne sais plus quel post il parlais de lumière & de shader , Le RenderState permet de "bindé" la texture , donc je ne vois pas en quoi dans son cas c'est un mauvais conseil puisque de toute façon il touchera au renderstate , il s'épargne une méthode pourrie et un pointeur...

Là on parle de conception, pas uniquement de technique. S'il s'agit de la texture de l'entité, alors il est logique de la lui assigner, et que ce soit ensuite elle qui la stocke et l'utilise à bon escient au moment de se dessiner. Sinon quoi, il faudrait se la trimballer et la gérer à côté ? Comme je l'ai dit, c'est exactement comme sf::Sprite et sf::Shape ; là tu ne te demandes pas pourquoi ces classes stockent elles-mêmes leur texture, si ?

[Cpl.Bator]

non, c'est des chaines de vertex...

C'est là que je ne comprend pas quand je vois cela :

cible.draw(m_tableauVertex,4,sf::Quads,states);

Un "EI" , c'est donc UN quad autrement dit , un sprite. Pourquoi dans ce cas ne pas faire hérité directement
EI de sf::Sprite ?

là tu ne te demandes pas pourquoi ces classes stockent elles-mêmes leur texture, si ?

Bien sur que non, la question n'est pas là , dans ce contexte je considère sa classe EI comme un sprite , autant en hérité si c'est le cas.

[Laurent]

Bien sur que non, la question n'est pas là

Ton conseil initial était quand même de virer recoitTexture et de passer la texture directement lors de l'appel à draw(). Donc si j'ai bien suivi, on oublie ça et maintenant le conseil c'est de dériver de sf::Sprite ?

Là encore, je dirais que c'est dans la plupart des cas une mauvaise idée. L'héritage est une relation très forte, qui implique de se coltiner toutes les fonctions de la classe de base dans l'interface publique de la classe dérivée. D'autant plus que sf::Sprite n'est pas particulièrement prévue pour l'héritage, elle n'offre donc pas ce à quoi tu pourrais t'attendre en terme de fonctions virtuelles.

A la limite il pourrait utiliser un sf::Sprite au lieu d'un tableau de sf::Vertex... mais bon là on s'en fout un peu je pense

Je ne vois pas trop l'intérêt de continuer à "débattre". A priori on a résolu son problème, et il semble être content de son architecture de classe, point sur lequel je le rejoins (du moins en ce qui concerne ce qu'il nous montre). Là tu voudrais lui faire changer des trucs dont il n'a pas forcément besoin, voire même qui pourraient rendre son code ou son architecture moins sympa.

[mazertys17]

Merci, Laurent !

Ca me fait quelque chose d'entendre que tu adère a l'architecture de mon EntiteImage    ! Faut dire que je revient de loin !  ...mais j'ai encore beaucoup de chemin a faire   

Bref,  la question a été résolu, et je peux confirmer d'ailleurs que maintenant, ça fonctionne très bien et que j'utilise dorénavant sf::RenderTexture pour gérer la lumière!

Donc merci a vous, pour l'aide et le soutient!