Messages

1

Graphique / Différence entre constructeur de copie et opérateur = avec des sprites/textures

« le: Avril 27, 2016, 01:03:07 pm »

Bonjour,

J'ai un soucis que je n'arrive pas à comprendre (encore un !).
J'ai une classe SpriteManager qui a pour but de gérer des animations de sprites. On lui fournit un "spriteFile", c'est-à-dire une image contenant plusieurs sprites, et ma classe se charge d'afficher un certain sprite à un instant t. Les différents sprites affichés les uns après les autres forment une animation (un personnage qui bouge par exemple). SpriteManager fonctionnait très bien avec un seul spriteFile.
Désormais, je cherche à pouvoir utiliser plusieurs spriteFiles pour avoir plusieurs "couches". L'objectif est le même, mais on décomposera cette fois le personnage en une couche "pieds", puis "corps", puis "tête", ce qui permettra par exemple de ne pas afficher les pieds lorsqu'on est dans l'eau (sinon on marcherait sur l'eau !).

J'ai aussi une classe Entity qui possède un attribut SpriteManager. En mettant exactement le même code dans le constructeur de copie du SpriteManager ou dans operator=, je n'obtiens pas le même résultat...

Constructeur de copie :

(click to show/hide)

SpriteManager::SpriteManager(const SpriteManager &sm)
{
    textures = sm.textures;
    spriteFiles = sm.spriteFiles;
    sprites = sm.sprites;

    for (unsigned int i = 0; i < textures.size(); i++)
    {
        if (!textures[i].loadFromFile(spriteFiles.at(i)))
        {
            error("impossible d'ouvrir le fichier " + spriteFiles.at(i));
        }

        sprites[i].setTexture(textures.at(i));
    }

    spriteSize = sm.spriteSize;
    uniqueSprite = sm.uniqueSprite;
    positionCurrentSprite = sm.positionCurrentSprite;
    positionLastSprite = sm.positionLastSprite;
    timeLastUpdate = sm.timeLastUpdate;
    defaultMsecPerSprite = sm.defaultMsecPerSprite;
    coeffAnimationSpeed = sm.coeffAnimationSpeed;
    reverse = sm.reverse;
    looping = sm.looping;
    loopsCycle = sm.loopsCycle;
    numberOfSpritesForAnimation = sm.numberOfSpritesForAnimation;
    animationComingAndGoingBackward = sm.animationComingAndGoingBackward;
}

Opérateur = :

(click to show/hide)

SpriteManager & SpriteManager::operator=(const SpriteManager &sm)
{
    textures = sm.textures;
    spriteFiles = sm.spriteFiles;
    sprites = sm.sprites;

    for (unsigned int i = 0; i < textures.size(); i++)
    {
        if (!textures[i].loadFromFile(spriteFiles.at(i)))
        {
            error("impossible d'ouvrir le fichier " + spriteFiles.at(i));
        }

        sprites[i].setTexture(textures.at(i));
    }

    spriteSize = sm.spriteSize;
    uniqueSprite = sm.uniqueSprite;
    positionCurrentSprite = sm.positionCurrentSprite;
    positionLastSprite = sm.positionLastSprite;
    timeLastUpdate = sm.timeLastUpdate;
    defaultMsecPerSprite = sm.defaultMsecPerSprite;
    coeffAnimationSpeed = sm.coeffAnimationSpeed;
    reverse = sm.reverse;
    looping = sm.looping;
    loopsCycle = sm.loopsCycle;
    numberOfSpritesForAnimation = sm.numberOfSpritesForAnimation;
    animationComingAndGoingBackward = sm.animationComingAndGoingBackward;

    return *this;
}

Et ci-dessous la liste des attributs avec leur type :

(click to show/hide)

    std::vector<sf::Texture> textures;
    std::vector<std::string> spriteFiles;
    std::vector<sf::Sprite> sprites;
    sf::Vector2u spriteSize;
    bool uniqueSprite;

    int positionCurrentSprite;
    int positionLastSprite;
    sf::Time timeLastUpdate;
    unsigned int defaultMsecPerSprite;
    double coeffAnimationSpeed;
    bool reverse;
    bool looping;
    LoopsCycle loopsCycle; // enum
    int numberOfSpritesForAnimation;
    bool animationComingAndGoingBackward;

Dans le constructeur d'Entity, si j'utilise l'opérateur =, tout va bien :

Entity::Entity(const std::vector<std::string> &spriteFiles, sf::Vector2u spriteSize, unsigned int msecPerSprite)
    : sprite(spriteFiles, spriteSize, msecPerSprite), speed(0), vectorSpeed(0,0), phi(0)
{
    sprite = SpriteManager(spriteFiles, spriteSize, msecPerSprite);
}

L'initialisation en utilisant le constructeur de SpriteManager après les ":" ne sert à rien ici. C'est juste qu'il n'y a pas de constructeur sans paramètre, mais c'est bien le "sprite = ..." qui m'intéresse.

Si par contre j'appelle le constructeur de copie, ça ne fonctionne plus tout à fait (et idem si j'appelle simplement le constructeur, comme je l'avais fait dans l'exemple précédent) :

Entity::Entity(const std::vector<std::string> &spriteFiles, sf::Vector2u spriteSize, unsigned int msecPerSprite)
    : sprite(SpriteManager(spriteFiles, spriteSize, msecPerSprite)), speed(0), vectorSpeed(0,0), phi(0)
{}

J'ai alors certaines couches de sprite qui s'affichent et s'animent correctement (les 2 dernières), et d'autres qui sont remplacées par des rectangles blancs (les 2 premières, il y en a 4 dans mon cas). Je ne comprends pas où est la différence. Alors je veux bien supposer que mon constructeur "classique" ne fonctionne pas, mais dans ce cas-là pourquoi ça fonctionne sur l'opérateur = (et pas sur le constructeur de copie qui est identique) ?

Merci par avance pour vos réponses !

2

Graphique / Re : Comportement anormal de la méthode push_back d'un std::vector<sf::Sprite>

« le: Avril 25, 2016, 10:41:59 pm »

Ok, eh bien merci pour ces réponses ! Je marque le sujet comme résolu.

3

Graphique / Re : Comportement anormal de la méthode push_back d'un std::vector<sf::Sprite>

« le: Avril 25, 2016, 03:39:32 pm »

Ah oui tiens, avec la console j'ai une taille correct (1 pour le vecteur "test")...
Ca va être sympathique pour débugger mes textures qui ne s'affichent pas toutes sans debugger !

Par contre, pourquoi le debugger affiche n'importe quoi du coup ?

4

Graphique / [Résolu] Comportement anormal de la méthode push_back de std::vector<sf::Sprite>

« le: Avril 25, 2016, 03:10:20 pm »

Bonjour,

J'ai un souci pour le moins étrange :

std::vector<sf::Sprite> test;
test.push_back(sf::Sprite());

Ces 2 lignes devraient en théorie créer un vector et y ajouter un Sprite. Eh bien chez moi je me retrouve avec 272 fois le même Sprite (c'est le debugger qui me le dit) !
Si je fais une boucle pour ajouter 4 Sprites par exemple, alors je me retrouve avec 4x272 fois le même Sprite...
Si je créé 2 vecteurs différents et que j'ajoute un Sprite différent sur chacun d'entre eux, les Sprites des 2 vecteurs seront différents (mais identiques au sein d'un même vecteur).
Enfin, si je fais un vecteur de pointeur de Sprites, tout se passe comme prévu (1 seul sf::Sprite* ajouté). De même, un vecteur de sf::Texture fonctionne correctement (sans même parler de pointeurs).

Je vous joins mon bout de code où ça coince. Ma classe personnelle SpriteManager a pour but de gérer des animations de sprites. On lui fournit un "spriteFile", c'est-à-dire une image contenant plusieurs sprites, et ma classe se charge d'afficher un certain sprite à un instant t. Les différents sprites affichés les uns après les autres forment une animation (un personnage qui bouge par exemple). SpriteManager fonctionnait très bien avec un seul spriteFile.
Désormais, je cherche à pouvoir utiliser plusieurs spriteFiles pour avoir plusieurs "couches". L'objectif est le même, mais on décomposera cette fois le personnage en une couche "pieds", puis "corps", puis "tête", ce qui permettra par exemple de ne pas afficher les pieds lorsqu'on est dans l'eau (sinon on marcherait sur l'eau !)

(click to show/hide)

SpriteManager::SpriteManager(const std::vector<std::string> &pSpriteFiles, sf::Vector2u pSpriteSize,
                             unsigned int pDefaultMsecPerSprite)
    : spriteFiles(pSpriteFiles), ... // autres initialisation de variables inutilisées dans le constructeur
{
    if (spriteFiles.empty())
    {
        // méthode (dans un autre fichier) qui écrit simplement dans un fichier texte et sort du programme si le 2e paramètre est vrai.
        error("SpriteManager::SpriteManager : pSpriteFiles est vide", true);
    }

    for (unsigned int i = 0; i < spriteFiles.size(); i++)
    {
        textures.push_back(sf::Texture());
        if (!textures[i].loadFromFile(spriteFiles.at(i)))
        {
            error("impossible d'ouvrir le fichier " + spriteFiles.at(i));
        }
        textures[i].setSmooth(true);

        sprites.push_back(sf::Sprite());
        sprites[i].setTexture(textures.at(i));
        sprites[i].setTextureRect(sf::IntRect(0, 0, spriteSize.x, spriteSize.y));
        sprites[i].setOrigin(spriteSize.x / 2, spriteSize.y / 2);
    }

    positionLastSprite = textures.at(0).getSize().y - spriteSize.y;
    std::vector<sf::Sprite> test;
    test.push_back(sf::Sprite());

    ...
}

Les lignes sprites.push_back(sf::Sprite()); et test.push_back(sf::Sprite()); ont le même problème.

Le .h :

(click to show/hide)

#ifndef SPRITE_MANAGER_H
#define SPRITE_MANAGER_H


#include <SFML/Graphics.hpp>


//----------------------------------------------------------------------------------------------------------------
// Rôle de la classe <SpriteManager>
// Gère et change le sprite lorsque c'est nécessaire. Permet également l'affichage du sprite.
//----------------------------------------------------------------------------------------------------------------

class SpriteManager : public sf::Drawable, public sf::Transformable
{
public:

    //--------------------------------------------------------------------------------------- Constantes statiques
    static const int DEFAULT_MSEC_PER_SPRITE = 20; // Temps d'affichage de chaque sprite par défaut (en msec)
    static const int ALL = 0; // Pour indiquer combien de sprites doivent être pris en compte dans l'animation actuelle

    //-------------------------------------------------------------------------------- Constructeurs - destructeur
    SpriteManager(const std::string &pSpriteFile); // Un seul sprite : pas d'animation
    SpriteManager(const std::vector<std::string> &pSpriteFiles, sf::Vector2u pSpriteSize,
                  unsigned int pDefaultMsecPerSprite = DEFAULT_MSEC_PER_SPRITE); // Plusieurs sprites : animation possible
    SpriteManager(const SpriteManager &sm); // Constructeur de copie
    virtual ~SpriteManager();

    ...

private:
    std::vector<sf::Texture> textures;
    std::vector<std::string> spriteFiles;
    std::vector<sf::Sprite> sprites;
    sf::Vector2u spriteSize; // Taille d'un sprite (en pixels)
    bool uniqueSprite; // Indique s'il n'y a qu'un seul sprite : pas d'animation

    ...

};

#endif // SPRITE_MANAGER_H

Et je joins 2 petits screenshots pour illustrer mes propos.

Merci d'avance pour vos réponses !

5

Général / Re : Conception d'une classe Bouton

« le: Février 12, 2016, 11:29:39 pm »

Oui je vois. Je crois que je vais prendre un peu des 2.
Déjà je vais utiliser les entrées temps réel, ça sera mieux en effet, et ça supprimera la 2e méthode (lors d'un clic gauche : indiquer à tous les boutons si la souris est désormais enfoncée ou non).
Ensuite je vais peut-être faire comme tu as dit pour la 2e méthode. Ca allègera un peu l'exécution des actions liées au bouton (on n'aura plus un gros switch pour faire ce qu'il faut suivant le bouton. Le menu s'en occupera lui même en appelant la bonne méthode de la classe principale, et cette dernière n'aura plus qu'à indiquer au menu qu'il y a eu un clic.

Merci pour ta réponse très utile !

Edit : Je mets en [Résolu] mais si quelqu'un voulait ajouter un élément à la discussion, qu'il n'hésite pas !

6

Général / [Résolu] Conception d'une classe Bouton

« le: Février 10, 2016, 09:28:23 pm »

Bonjour !

Je suis actuellement en réflexion pour la conception d'une classe Bouton.
En fait, cette classe est déjà codée mais je ne suis pas très satisfait de son fonctionnement actuel.

Tout se déroule dans 3 classes : une classe "principale" qui gère le jeu de manière générale (ainsi que l'affichage), une classe "interface" qui va représenter par exemple un menu, et la classe Bouton.
Actuellement, la classe principale instancie la classe Menu. Menu instancie à son tour des boutons. On retourne ensuite dans la classe principale. Celle-ci traite les évènements dans une boucle :

• Lors de l'évènement mouseMoved, on appelle une méthode de la classe Menu qui va indiquer à chaque bouton la position de la souris. Si la souris est sur un bouton particulier, celui-ci changera de texture.
• Lors de l'évènement "clic gauche", on appelle une méthode de la classe Menu qui va indiquer à chaque bouton que la souris est enfoncée. Si la souris est sur un bouton, celui-ci changera de texture. Si la souris bouge par la suite (mais que le clic gauche est maintenu), on saura qu'elle est enfoncée et d'autres boutons changeront éventuellement de texture si la souris se pose dessus.
• Lors de l'évènement "clic gauche relâché", on appelle la méthode précédente pour indiquer que le bouton n'est plus enfoncé et on appelle une méthode pour récupérer une enum indiquant quel bouton a été cliqué. Suivant le retour, on exécute le code approprié (dans un switch, dans la classe principale). Il peut s'agir de sauvegarder la partie, quitter le jeu, etc.

Cette solution est donc un peu lourde à utiliser. Il faut penser à appeler ces 3 méthodes à différents endroits du code de la classe principale. C'est un peu compliqué au début. Bref, ce n'est pas très bien pensé.

Je réfléchis donc à une autre solution, et celle-ci m'est venue en tête : utiliser des pointeurs de fonction.
Chaque bouton disposera d'un pointeur de fonction sur une méthode-membre de la classe principale permettant d'exécuter son code. Dans la boucle principale, on appellera également une méthode handleEvent des boutons leur indiquant l'évènement. Ensuite, le bouton change de texture si l'évènement est mouseMoved / buttonClicked, utilise le pointeur de fonction si l'évènement est buttonReleased...
Les avantages : c'est beaucoup plus facile à utiliser. On appelle une méthode pour donner quelques pointeurs au bouton quand on le crée, et on fait un for pour appeler la méthode handleEvent de chaque bouton à chaque fois qu'un nouvel évènement se produit. Le reste est géré par la classe Bouton.
Les inconvénients : chaque bouton doit désormais disposer de 4 pointeurs supplémentaires : un pointeur de fonction, comme je l'ai indiqué précédemment ; un pointeur vers l'instance de la classe principale pour utiliser le pointeur de fonction ; un pointeur vers la fenêtre (ou un getter dans la classe principale) pour savoir où se trouve la souris par exemple ; et un pointeur vers une éventuelle View (si le bouton est dans une View, il faudra disposer de la View pour convertir les coordonnées comme il faut et savoir si la souris est sur le bouton ou non).
En plus de ces 4 pointeurs, il y aura un for pour chaque bouton pour appeler handleEvent, même si l'évènement n'a rien à voir (on appuie sur une touche du clavier par exemple). Ce n'est pas très optimisé...


Là non plus, ce n'est pas idéal je trouve. J'aimerais donc savoir ce que vous pensez de ces 2 solutions, et si vous en avez d'autres à proposer, je vous écoute !

7

Fenêtrage / Re : Problème de scintillement malgré le framerate ou la VSync

« le: Décembre 20, 2015, 01:26:59 pm »

En effet, j'ai modifié la méthode move de la classe TiledMap (qui reprend l'exemple d'un tuto du site). Le problème semble réglé.
En fait, le personnage-joueur est toujours au centre de l'écran, donc lors des déplacements c'est la carte qui bougeait. Cependant, les déplacements sont calculés en fonction du temps écoulé, ce qui donnent des nombres non-entiers. J'ai donc modifié la méthode move de la carte pour qu'elle "retienne" les nombres non-entiers mais ne garde que la partie entière pour l'affichage.

Merci pour ton aide

8

Fenêtrage / [Résolu] Problème de scintillement malgré le framerate ou la VSync

« le: Décembre 17, 2015, 09:24:03 pm »

Bonjour,

J'ai un problème de scintillement de manière assez régulière mais pas non plus en continu. Comme le tuto "Ouvrir et gérer une fenêtre SFML" l'indique, j'ai essayé d'utiliser la synchronisation verticale ou de bloquer le framerate (sans utiliser les 2 en même temps), mais cela ne change rien.

En pièces jointes 2 images illustrant le problème.

Avez-vous des pistes pour m'aider ?
Merci d'avance

9

Général / Re : Qt Creator 3.2.2 et SFML 2.3.2

« le: Octobre 13, 2015, 07:26:39 pm »

En effet, j'utilisais la version TDM (SJLJ) de la SFML, qui fonctionne parfaitement sous CodeBlocks. Pour QtCreator il faut la version MinGW (DW2).

Désolé pour cette erreur récurrente, j'étais persuadé que le problème venait de ma configuration de QtCreator...


Merci !

10

Général / [Résolu] Qt Creator 3.2.2 et SFML 2.3.2

« le: Octobre 12, 2015, 08:23:51 pm »

Bonjour à tous !

Je sais que beaucoup de topics ont déjà été postés sur ce sujet, mais aucun ne correspond au problème que j'ai.

Vous l'aurez deviné, il s'agit d'utiliser Qt Creator (version 3.2.2) pour un projet utilisant la SFML (version 2.3.2). J'avais déjà réussi à configurer Qt Creator pour la SFML 1.6, puis plus tard pour la 2.1, mais là je bloque.

Venons-en au problème !
Alors tout d'abord, le projet compile parfaitement. Je n'ai aucune erreur ni aucun warning, tout se passe très bien jusqu'ici.
En revanche, lorsque je lance l'application avec Qt Creator, j'obtiens le message "[Application].exe a cessé de fonctionner". Je clique alors sur "Fermer l'application", et là j'ai 3 fenêtres d'erreur qui s'ouvrent :
- La 1ère a pour titre "Arrêt inattendu de GDB" et m'indique que "le processus gdb s'est terminé de façon inattendue (code 0)" ;
- La 2nde a pour titre "Erreur d'exécution" et m'indique qu'il est "impossible de continuer le processus débogué : The program is not being run." ;
- La 3ème a pour titre "Echec de l'exécutable" et m'indique qu' "une exception a été déclenchée : Exception at 0x77f08d92, code: 0xc000007b: , flags=0x0. During startup program exited with code 0xff.".

Si maintenant je décide de lancer moi-même le .exe, sans passer par Qt Creator, il me faut préalablement ajouter le fichier "libgcc_s_sjlj-1.dll". Je n'ai pourtant jamais eu à ajouter cette DLL auparavant...
Je double-clique sur mon .exe et j'obtiens cette fois un seul message d'erreur : "L'application n'a pas réussi à démarrer correctement (0xc000007b)."


Je vous joins mon fichier .pro au cas où, même si l'erreur ne semble pas venir de là :

TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

INCLUDEPATH += ../SFML-2.3.2/include
DEPENDPATH += ../SFML-2.3.2/include
LIBS += \
    -L../SFML-2.3.2/lib/ -lsfml-graphics -lsfml-window -lsfml-audio -lsfml-system

SOURCES += main.cpp \
    Game.cpp \
    Parametres.cpp \
    fonctionsPratiques.cpp

include(deployment.pri)
qtcAddDeployment()

HEADERS += \
    define.h \
    Game.h \
    Parametres.h \
    fonctionsPratiques.h

 

11

Général / Re : Qt Creator et SFML 2.1

« le: Juin 16, 2014, 09:58:15 am »

C'est bon, ça fonctionne !!!

Merci beaucoup, et désolé pour les tutoriels. J'avais pourtant regardé mais je n'ai rien trouvé pour Qt et SFML 2.x. Et concernant le SFML_DYNAMIC j'avais vu le SMFL_STATIC, du coup je ne me suis pas posé plus de questions que ça et ai supposé que ça existait encore...

Je poste le contenu de mon .pro si d'autres avaient le même souci à l'avenir :

TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

INCLUDEPATH += C:/SFML-2.1/include
LIBS += \
    -LC:/SFML-2.1/lib/ -lsfml-graphics -lsfml-window -lsfml-system

SOURCES += main.cpp

Encore merci 

12

Général / [Résolu] Qt Creator et SFML 2.1

« le: Juin 15, 2014, 09:47:24 pm »

Bonjour !

J'essaie de compiler un projet SFML 2.1 sous Qt Creator mais je n'y arrive. J'ai déjà réussi à le faire avec SFML 1.6 pourtant.

Les erreurs sont les suivantes :
:-1: erreur : cannot find -lsfml-window
:-1: erreur : cannot find C:/SFML-2.1/lib/: Permission denied
:-1: erreur : cannot find -lsfml-system
collect2.exe:-1: erreur : error: ld returned 1 exit status

Ci-dessous le .pro :

TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

DEFINES += SFML_DYNAMIC

INCLUDEPATH += C:/SFML-2.1/include
LIBS += \
    -L C:/SFML-2.1/lib/ -lsfml-graphics \
    -L C:/SFML-2.1/lib/ -lsfml-window \
    -L C:/SFML-2.1/lib/ -lsfml-system

SOURCES += main.cpp

J'ai vu de nombreux autres sujets du même genre mais je n'y ai pas trouvé de réponse satisfaisante. Par contre je n'ai ni recompilé SFML, ni utilisé CMake (je n'en avais pas eu besoin pour SFML 1.6).

Merci d'avance !