Messages

16

Général / Re : SIGSEGV plantage du prog

« le: Avril 16, 2015, 06:18:20 pm »

Il y a toujours le problème de tes sprites et textes qui cessent d'exister à chaque fin d'itération de la boucle. Fais-toi un vector de sprite (ajoutant une nouveau sprite avec la bonne texture et la bonne position à chaque ble ou orge récupéré) et fais :

for( std::size_t i(0) ; i < mesObjets.size() ; i++)
    window.draw(mesObjets[i]);[/cpp]

17

Général / Re : SIGSEGV plantage du prog

« le: Avril 15, 2015, 06:18:45 pm »

std::to_string

18

Général / Re : SIGSEGV plantage du prog

« le: Avril 15, 2015, 05:20:23 pm »

Premièrement, tu charges une texture à chaque itération de la boucle, ce qui est extrêmement mauvais pour les performances, encore plus que d'avoir une texture par entité.
Normalement, tu avais déjà chargé les texture, mettons que tu les as nommées textureBle et textureOrge, remplace :

str_texture += ".png";
if (myTexture.loadFromFile(str_texture)) {
    mySprite.setTexture(myTexture);

Par :

if(str_texture == "Ble")
    mySprite.setTexture(textureBle);
else
    mySprite.setTexture(textureOrge);

Cela ne résoudra pas ton problème mais c'est important. Enfin en fait, le résoudra peut-être? Tu sais, un texture, c'est fait pour être chargé une fois, par pour changer à tout bout de champ. Tu es sensé la créer, charger son image, puis ne t'en servir que pour la plaquer sur des entités comme les sprites. Peut-être que ce sont ces changements intempestifs d'images qui empêchent le dessin de se dérouler correctement.

Sinon, peut-être est-ce parce que myText, myText2 et mySprite sont des variables temporaires, supprimées à chaque fin d'itération de la boucle ? Essaie de mettre des sprites dans ton inventaire, puis de dessiner le tout avec par exemple une fonction Inventaire.makeDraws(window) qui ferait tous les window.draw() nécessaires.

19

Général / Re : SIGSEGV plantage du prog

« le: Avril 12, 2015, 02:47:54 pm »

C'est bien dans ton main et pas en variables globales ? Parce que si oui...ben, ton compilo est fou et j'y peux rien

20

Général / Re : SIGSEGV plantage du prog

« le: Avril 11, 2015, 07:57:51 pm »

Déj), c'est j'ai bien compris, deadBle est global. Tetete. On ne t'as jamais appris que les variables global c'était mal ?

Crée ta texture dans ta fonction main. Change le prototype de RInter pour que sont paramètre texture soit effectivement une sf::Texture et non un std::string et modifie des RObject pour que leur fonction load() prenne directement la texture plutôt que de prendre son adresse et de la charger. (pareil pour ble.png, orge.png et deadOrge.png, bien sûr)
Si une même texture est chargée plusieurs fois dans ton programme, c'est qu'il y a un problème de conception. Perso j'utilise une classe textureCore qui s'occupe de charger les texture et de distribuer leurs adresses aux classes qui les demandent.
(par exemple une class Champignon va faire :
 m_texture = textCore->giveMeTexture("champignon");
)
Où textCore est un pointeur global qui pointe sur l'unique instance de textureCore (bon, les variables globales son pratique dans ce genre de cas, mais d'après moi c'est le seul)

21

Général / Re : SIGSEGV plantage du prog

« le: Avril 11, 2015, 07:13:34 pm »

J'ai décortiqué ta fonction RInter() :

if (p.inter(e) == e.getType())

Mettons que e soit de type 0, donc une simple entité. p.inter(e) renvoie 0, et e.getType() aussi, donc la condition vaut vrai. Les tests suivants seront donc exécutés, ce qui est idiot puisqu'un RObject de type 0 n'a aucune interaction. La première ligne de cette fonction devrait être

if (e.getType() == 0)
    return false;

Ensuite, appel à p.inter(e). Oh, cette fonction est inutilement compliquée, puisqu'un test de collision, sur ce type de configuration, se résume à ça :

bool inter(Entity e)
{
    return ( e.getX() == x && e.getY() == y )
}

Et ta fonction RInter devient :

bool RInter(Perso& p, RObject& e, const std::string& texture, Inventory& inv)
{
   if (e.getType() == 0)
        return false;

    // Comme tes QDebug() affichaient (je suppose) les numéro de ligne, je les ai enlevés, puisque ça ne va plus correspondre à rien.
    // À propos c'est une mauvaise façon de procéder, si tu veux savoir où en est ton programme, tu utilises le debugger en mode pas-à-pas.

    if (p.inter(e) && e.inter()) // Si le perso est bien au même endroit que e et que e est disponible...
        {
            e.changeU(false);   // Eh ben e n'est plus dispo, puisque p vient de le ramasser.

            if (!e.load(texture))   // Tu devrias plutôt ne charger qu'une seule fois la texture, le la donner à ton entité quand elle en a besoin
                 return false;      // Parce que là tu as une texture par entité alors qu'elles utilisent toutes la même, ce genre de truc bouffe vite de la mémoire pour rien.

            string e_name = e.getName();

            if (e_name == "ble")
            {
                int nb = inv.recupInt(0);
                int nbr = nb+1;
                inv.modifier(0, nbr, e_name); // On le met dans l'inventaire.
            }
            if (e_name == "orge")
            {
                int nb = inv.recupInt(1);
                int nbr = nb+1;
                inv.modifier(1, nbr, e_name); // Idem.
            }
            // D'ailleurs, si ton inventaire est plein et que tu essaies d'ajouter un truc, je crois que ton programme va planter. Mais ce n'est pas le problème.

            return true; // Et on dit "oui, cette entité a été ramassée".
    }

    return false; // Ou pas.
}

Lis bien les commentaires, ils pourraient t'apprendre un truc ou deux.
Cette version de p.inter(e) et de RInter() devrait fonctionner, tu me confirmes ça ?

22

Général / Re : SIGSEGV plantage du prog

« le: Avril 11, 2015, 03:15:55 pm »

        int eXY = eY+eX;
        if (e.getType() == 0)
            return 0;
        if (e.getType() != 0 && eXY == xy)

Première erreur. Tu ne peux pas juste additionner les coordonnées. Si son perso est en (3;6) et ton blé en (5;4), ils ne sont pas du tout au même endroit et pourtant ton programme va croire que si. Tu dois comparer les x et le y séparément.
Ensuite j'aimerais comprendre : c'est quoi getType() ? Ça renvoie un int, mais qui correspond à quoi ? Usuellement, pour définir un type, on crée une énumération, on ne se contente pas d'un int...

23

Général / Re : SIGSEGV plantage du prog

« le: Avril 11, 2015, 01:38:26 pm »

Avant tout, une petite chose :

RObject ble(49, 13, "ble"), \
            ble2(47, 13, "ble"), \
            ble3(48, 12, "ble"), \
            ble4(45, 11, "ble"), \
            ble5(44, 12, "ble"), \
            ble6(47, 11, "ble");

Alors ce code est correct, pas de problèmes. Sache juste que les \ sont inutiles vu qu'en C++ il n'y a aucune notion de fin de ligne. Par exemple, si tu avais écrit :

RObject ble(49, 13, "ble"),



            ble2(47, 13, "ble"),
            ble3(48, 12, "ble"),

            ble4(45, 11, "ble"),
            ble5(44, 12, "ble"),                           ble6(47, 11, "ble");

Cela fonctionnerait tout aussi bien.

Pour ce qui est de ton problème...je ne suis pas sûr d'avoir très bien compris ton code, mais si c'est le cas, quand on appuie sur E, ça appelle la fonction RInter sur tous les objets ble ou orge, selon. Or cette fonction fait deux choses : ajouter le blé/orge dans ton inventaire et transformer celui au sol en blé/orge mort.
Ton programme fait exactement ce que tu lui demande : récupérer tout. Tu dois faire en sorte de vérifier pour chaque blé si ton perso est dessus, et si oui, récupérer le blé/orge. Là ,aucun test de hitbox n'est fait, donc évidemment, il récupère tout.

24

Général / Re : SIGSEGV plantage du prog

« le: Avril 11, 2015, 10:42:03 am »

unsigned int invInt[]; // Nombre d'objets dans la place de l'inventaire X
std::string invName[]; // Nom de l'objet dans l'inventaire X

C'est simple. Tu n'as pas donné de taille à tes tableaux. invInt et invName sont des tableaux de 0 cases.
Donc évidemment si tu essaies d'accéder à la case 4 (par exemple), ça plante, et ta condition ne l'empêche pas puisque 4 est bien inférieur à 16 (maxTalleX).

unsigned int invInt[16]; // Nombre d'objets dans la place de l'inventaire X
std::string invName[16]; // Nom de l'objet dans l'inventaire X

25

Général / Re : Re : Re : SIGSEGV plantage du prog

« le: Avril 09, 2015, 07:20:16 pm »

ble4.getAvb ? Bah je vais pas non plus écrire tous les noms des fonctions en entier, je suis feignant moi...

Eh bien, je ne vais pas m'embêter à comprendre ton code plus que ça, je suis fainéant moi...
Plus sérieusement, si tu ne donnes pas de noms explicites dans ton code, si un jour tu veux réutiliser ce code mais que tu n'y as pas touché depuis des mois, tu vas toi-même avoir beaucoup de mal à comprendre comment cela fonctionne.

invStr ou invName, ça change pas grand chose

Ah ben à l'exécution, c'est sûr, ça ne change absolument rien. Mais comme je l'ai dit, c'est plus clair. Une chaîne de caractères c'est pas forcément un nom, ça peut être par exemple un texte qui s'affiche quand tu ouvres l'inventaire, ou encore plein d'autres trucs qu'on pourrait imaginer.

Il est important de donner des noms clairs. Si tu refuses de le faire, ne t'attends pas à recevoir de l'aide rapide et efficace.

26

Général / Re : fatal IO error 11 - Thread - Event

« le: Avril 09, 2015, 12:03:22 pm »

En tant que tel ça ne va pas faire planter le programme, mais c'est vrai que pour ce qui est d'avoir une exécution correcte ça va coincer sévère

EDIT : En relisant mieux l'intégralité du sujet je me rend compte que si, c'est peut-être la cause de tout de barouin.

27

Graphique / Re : Une question sur le draw()

« le: Avril 09, 2015, 11:59:27 am »

S'il n'y a qu'un seul appel à draw(), je dirais que tes performances d'affichage sont optimales, et dit comme ça, ça a l'air relativement facile à gérer. Par contre au niveau opération en mémoire, aie aie aie...recréer un tableau assez énorme à chaque dessin, ta RAM va pas aimer. Pour le coup c'est peut-être là que ça va pêcher.

Il n'y a pas 40 façons de vérifier ça : utilise ta méthode, vois les FPS, puis utilise la méthode de base avec plein de sf::Sprite pour dessiner exactement la même scène, et vois les FPS. Compare les deux. La méthode qui donne le plus de FPS est la meilleure.
Perso j'utilise une méthode similaire mais de manière locale, par exemple si j'ai un gros boss constitué de plein de sprites pour des animations de ouf je crée une classe personnalisée qui gère tous les sprites en un seul tableau de vertex, ça donne de bons résultats et sans grosses opérations en mémoire.

28

Général / Re : fatal IO error 11 - Thread - Event

« le: Avril 09, 2015, 11:48:50 am »

Avant tout, il y a un truc qui me chiffonne.
_window->pollEvent(event);
      while (_window->pollEvent(event))
Un explication ?...Pourquoi appeler pollEvent dans le vide juste avant ta boucle de pollEvent ?
Je ne dis pas que c'est une source d'erreurs mais ça me semble bizarre.

29

Général / Re : SIGSEGV plantage du prog

« le: Avril 09, 2015, 11:31:19 am »

Ah, l'éternel sigsev...le terrible, le redouté sigsev.
Il n'y a pas quarante solutions. Lance le debugger, exécute le programme pas-à-pas, et au moment où ça plante, trouve l'erreur.
SIGSEV apparaît dans les cas suivants :
– Quand tu essaies de déréférencer un pointeur nul.
Exemple :

MaClasse *ptr = nullptr;
ptr->fonctionMembre(); // ERREUR : Le pointeur est nul, la fonction ne peut être appelée.

– Quand tu essaies d'accéder à une case de mémoire qui n'est pas allouée à ton programme.
Exemple :

int *entier = new int(0);
*entier = 5; // pas de problème, la case de mémoire pointée est à toi.
delete entier;
*entier = 0; // ERREUR : la case de mémoire pointée n'est plus allouée à ton programme.

Dans tous les cas tu as un problème de pointeurs quelque part, et le seul moyen de trouver où est d'y aller à grands coups de debugger.


EDIT : J'avoue avoir répondu sans lire ton post.
Conseil : Pour stocker une position, prend un entier non signé, basiquement unsigned int plutôt que juste int.
Je te conseillerais même d'utiliser std::size_t qui est là exprès pour ça. Ça t'évitera des problèmes de positions négatives qui sont parfois source de problèmes.

Autre conseil : donne des noms explicites. J'ai pris une ligne au pif et ai trouvé ble4.getAvb(). Comment suis-je supposé comprendre ce que cela signifie ?! Chage tes noms, là c'est incompréhensible, personne ne va vouloir t'aider avec un code pareil.
Pareil, dans ta classe inventaire, il y a : std::string invStr[];
Je suppose que invStr signifie "inventory string". La chaîne de caractères de l'inventaire. Cool, ça correspond à quoi ? À quoi sert cete attribut ? C'est son nom ? Si c'est son nom, appelle-le name, ne lui donne pas un nom à la noix. Et surtout pas un nom qui contient celui du type, n'appelle pas un string str, il y a std::string juste avant, je voir bien que c'est un string, pas la peine de le remettre dans le nom de l'instance.
D'ailleurs au début j'avais pas pigé que inv c'était pour inventory, je croyais que c'était inverse...comme quoi...

30

Graphique / Re : RenderTexture, draw() et autres questions de ce genre

« le: Mars 31, 2015, 08:29:09 am »

Oui. Alors j'ai exactement :
-Wall -Wextra -std=c++11 -Wzero-as-null-pointer-constant -pedantic -pedantic-errors -Wmain -Wswitch-default -Wmissing-include-dirs -Wmissing-declarations -Wunreachable-code -Winline -Wfloat-equal -Wundef -Wcast-align -Wredundant-decls -Winit-self -Wshadow et -Wnon-virtual-dtor