[BUG SFML2] Utilisation de classe (texture/sprite) dans un objet

[Samuel Proulx]

Bonjour à tous et à toutes

Spécifiquement pour toi Laurent si tu comprends parce que moi je ne comprends pas

EDIT : j'ai décidé d'afficher simplement les codes sources pour une compréhension rapide du bug de la SFML 2.0 (à moins que tu connaisses la solution bien sûr ça serait vraiment cool )

Code qui devrait fonctionner, mais qui affiche uniquement un carré blanc au lieu de TopLeftCorner.png :

Code: [Sélectionner]

class Win{
public:
    Win(sf::RenderWindow*);
    void draw();
private:
    sf::RenderWindow *app;
    sf::Texture texture;
    sf::Sprite sprite;
};
Win::Win(RenderWindow* win){
    app = win;
    texture.loadFromFile("TopLeftCorner.png");
    sprite.setTexture(texture);
}

void Win::draw(){
    app->draw(sprite);
}
Voici la solution que j'ai trouvé pour l'instant, mais qui s'avère très encombrante puisqu'il faut appeler une fonction init alors que les constructeurs sont sensés servir à ça :

Code: [Sélectionner]

class Win{
public:
    Win(sf::RenderWindow*);
    void draw();
    void init();//..................................Nouvelle méthode
private:
    sf::RenderWindow *app;
    sf::Texture texture;
    sf::Sprite sprite;
};
Win::Win(RenderWindow* win){ //...................on a donc déplacé le setTexture......
    app = win;
    texture.loadFromFile("TopLeftCorner.png");
}

void Win::init(){ //..............................ici
    sprite.setTexture(texture);
}

void Win::draw(){
    app->draw(sprite);
}
On comprend donc que tout fonctionne normalement si on appelle le setTexture à l'extérieur du constructeur.
Est-ce un bug ? puisque Lo-X affirme que lui ça fonctionne)

Merci et bonne journée et tu fais un très bon boulot Laurent !

[Laurent]

Ben faudrait voir le code de ces fonctions, on ne peut pas deviner ce qui ne va pas

[Lo-X]

Je t'ai répondu la même chose sur le forum du SdZ, je pense que ton soucis c'est que la texture est supprimée à la fin de ton construteur, donc ton sprite pointe sur une texture qui n'éxiste plus.

Le meilleur moyen est de faire une classe qui gère toutes les textures (initialisation, accès, suppression à la destruction) et de toujours garder cet objet "en vie" tant que le jeu tourne et de la fournir aux classes qui ont besoin de textures

[Samuel Proulx]

Svp Lo-X, je te remercie beaucoup pour ta réponse sur le SdZ, mais maintenant si tu pourrais aller voir mon post (j'ajoute le lien, car je veux pas reposter pour les codes (le SdZ a une meilleures coloration d'ailleurs )
Il mène directement sur le post...
http://www.siteduzero.com/forum-83-758474-p1-sfml2-utilisation-de-classe-image-texture-dans-un-objet.html#r7288381

[Laurent]

Ta classe est correcte dans les deux cas, à mon avis ce qui merde c'est son utilisation -- plus précisément, je pense que tu la copies par mégarde, ce qui foire le lien entre le sprite et sa texture.

Ce forum a de la coloration syntaxique aussi, pour peu que tu utilises la bonne balise.

[Samuel Proulx]

Ah excuse-moi j'avais pas vu la liste Code pour changer le langage

Bon, là tu as touché un point important je pense, car si je déclare win dans mon main et que j'appelle simplement draw dans la boucle, ça fonctionne...

Je crois que c'est la std::list<Win> qui fonctionne pas comme je le veux... est-ce que vous pouvez me dire si ce code est correct (cette classe a un attribut std::list<Win> windows;)

void SFGUI::draw(){//On fait le tour de la liste pour dessiner toutes les fenêtres
    for(list<Win>::iterator it = windows.begin(); it != windows.end(); it++){
        (*it).draw();
    }
}

void SFGUI::addWindow(){//on ajoute une fenêtre à la liste
    windows.push_back(Win(app, 0, 0, 400, 300, false));
}

EDIT

J'ai touché juste !

Si je fais :

void SFGUI::addWindow(){//on ajoute une fenêtre à la liste
    Win *win = new Win(app, 0, 0, 400, 300, false);
    windows.push_back(win);
}

Ça fonctionne ! (bien sûr avec quelques changement comme des . pour des -> et std::list<Win*>...)

Maintenant, est-ce qu'il est possible d'écrire les deux lignes en une ?

Merci et bonne journée !

[Laurent]

Oui c'est bien là le problème : tu stockes dans ta liste des copies d'instances de Win, jamais les originales (qui sont temporaires et donc détruites aussitôt). Or tu ne gères pas bien la copie dans la classe Win : la copie automatique va faire pointer le nouveau sprite vers la texture de l'ancienne instance, il faut explicitement refaire le lien vers la bonne texture.

Mais une classe de fenêtre ne devrait théoriquement pas être copiable, pour commencer. Bien définir la sémantique de ses classes (copiable ou non), c'est primordial.

[Samuel Proulx]

Bon, je ne comprends pas pourquoi dans mon cas je devrais empêcher le constructeur de copie d'agir (d'ailleurs, comment fait-on cela ? J'ai seulement appris à modifier le constructeur de copie pour les pointeurs, pas à le bloquer ) parce que les fenêtres dont ce parle forme la GUI dans la fenêtre SFML. Ainsi, je pourrais très bien avoir deux fenêtre identique (input et button avec un string pour dire ce que le champ attend) sauf que je changerais par la suite juste string pour écrire une autre phrase.

Merci et bonne journée !

[Lo-X]

Il  faut définir explicitement le constructeur de copie et l'operator= dans la classe, mais en private ou protected. Comme ça leu accès n'est plus possible : plus de copie !
edit: il faut aussi rendre le constructeur protégé.
edit2: Si tu utilises boost, une classe non-copyable est déjà définie : http://www.boost.org/doc/libs/1_41_0/boost/noncopyable.hpp

[Laurent]

SFML a aussi une classe sf::NonCopyable.

Bon, je ne comprends pas pourquoi dans mon cas je devrais empêcher le constructeur de copie d'agir

Tu te rends bien compte que pour gérer la copie d'une fenêtre, il faut dupliquer tout son contenu ? Est-ce que ton framework sait gérer ça ?

[Samuel Proulx]

Actuellement, la classe contient très peu d'élément alors le constructeur de copie par défaut fait la job

Par la suite, je devrai créer mon C de C perso si nécessaire (pour je sais pas... un pointeur par exemple ?  )

Ensuite, je sais pas si on peut vraiment appeler ça un framework parce que ce ne sera pas quelque chose que je pourrais distribuer : c'est conçu uniquement pour l'application que je suis en train de faire.

C'est-à-dire que par exemple, ma GUI a des fonctions spéciales du genre addLoginWindow()... Ces fonctionne appelle en fait simplement la classe Win() pour ajouter une nouvelle fenêtre et se charge d'ajouter son contenu (child) comme pour addLoginWindow, on va ajouter deux label et input avec un button. Les événements qui y sont reliés sont aussi établient là.

Je sais très bien que ça ne la rend pas du tout portable pour une autre utilisation, mais ce n'est pas du tout mon but ici (bien qu'on pourrait me dire que je devrais le faire quand même, j'affirme qu'il y a déjà plein d'extensions de GUI pour la SFML qui fonctionnent très bien déjà

Merci beaucoup pour votre aide les gars, c'est vraiment apprécié