Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - kamui

Pages: « Précédente 1 2 3 [4] 5 6 ... 9 Suivante »
46
Graphique / Re : [SFML 2.0 RC]problème d'affichage
« le: Août 25, 2012, 11:32:58 am »
Bonjour, 

Je suis parti du code minimal, pour remonter jusqu'à ma version de base avec fichiers séparés :
  • A la seconde ou je colle le ctor et le dtor de la classe Carte dans un fichier séparé : Carré blanc
  • Tout le reste est à l'identique avec la version buggée
  • du coup je penses que je foire avec les namespaces


la version qui marche
#ifndef CARTE_HPP
#define CARTE_HPP

#include <iostream>
#include <SFML/Graphics.hpp>

namespace Cartes
{

    enum Valeur {As=0, Deux, Trois, Quatre, Cinq, Six, Sept, Huit, Neuf, Dix, Valet, Dame, Roi, Joker};
    enum Couleur {Trefle=0, Pique, Coeur, Carreau, Sans};
    const int taille_carte_x = 73;
    const int taille_carte_y = 98;
    static sf::Texture Cartes;


    static void InitTextureCartes()
    {
        if (!Cartes::Cartes.loadFromFile("Cartes.png"))
           std::cout << "erreur lors du chargement de la texture" << std::endl;
    }


    class Carte
    {
        public:
            Carte(Valeur v, Couleur c);
            ~Carte();

            inline Valeur Getv() { return v; }
            inline void Setv(Valeur val) { v = val; }
            inline Couleur Getc() { return c; }
            inline void Setc(Couleur val) { c = val; }
            sf::Sprite& Gets() { return s; }

        protected:
        private:

            Valeur v;
            Couleur c;
            sf::Sprite s;

    };


    Carte::Carte(Valeur v, Couleur c) :
    v(v),
    c(c)
    {
        s.setTexture(Cartes);
        s.setTextureRect(sf::IntRect(v*taille_carte_x,c*taille_carte_y,taille_carte_x,taille_carte_y));
        //ctor
    }

    Carte::~Carte()
    {
        //dtor
    }
}

 

et la version qui marche pas

#ifndef CARTE_HPP
#define CARTE_HPP

#include <iostream>
#include <SFML/Graphics.hpp>

namespace Cartes
{

    enum Valeur {As=0, Deux, Trois, Quatre, Cinq, Six, Sept, Huit, Neuf, Dix, Valet, Dame, Roi, Joker};
    enum Couleur {Trefle=0, Pique, Coeur, Carreau, Sans};
    const int taille_carte_x = 73;
    const int taille_carte_y = 98;
    static sf::Texture Cartes;


     static void InitTextureCartes()
    {
        if (!Cartes::Cartes.loadFromFile("Cartes.png"))
           std::cout << "erreur lors du chargement de la texture" << std::endl;
    }


    class Carte
    {
        public:
            Carte(Valeur v, Couleur c);
            ~Carte();

            inline Valeur Getv() { return v; }
            inline void Setv(Valeur val) { v = val; }
            inline Couleur Getc() { return c; }
            inline void Setc(Couleur val) { c = val; }
            sf::Sprite& Gets() { return s; }

        protected:
        private:

            Valeur v;
            Couleur c;
            sf::Sprite s;

    };
}

 

#include "Carte.hpp"

namespace Cartes
{

    Carte::Carte(Valeur v, Couleur c) :
    v(v),
    c(c),
    s(sf::Sprite())
    {
        s.setTexture(Cartes);
        s.setTextureRect(sf::IntRect(v*taille_carte_x,c*taille_carte_y,taille_carte_x,taille_carte_y));
        //ctor
    }

    Carte::~Carte()
    {
        //dtor
    }
}

 

C'est pas comme ça qu'on gère les namespaces entre un header et son implé ?

Bon sinon est-ce que j'aurais un intérêt à faire du header-only là ? A part pour le fait que cela corrige le bug s'il n'y a que l'header je veux dire (d'ailleurs quand c'est pas pour des API c'est quoi l'intérêt du header-only ?).

47
Graphique / Re : [SFML 2.0 RC]problème d'affichage
« le: Août 25, 2012, 01:06:49 am »
Bon j'ai voulu vous faire un petit code minimal, pour que vous puissiez tester chez vous, mais dès que je mets tout le code dans le même fichier, plus de problème...je ne comprend plus rien... alors je vous donne la seule chose que je ne vous ai pas donné, mon main :

#include <iostream>
#include <SFML/Graphics.hpp>
#include "Carte.hpp"
#include "President.hpp"

using namespace std;
using namespace Cartes;
using namespace President::Jeu_54_cartes;

int main()
{

    //on initialise le jeu de 54 cartes
    Init();

    //on charge la texture
    InitTextureCartes();
    //on construit une carte
    Carte as_de_pique(As, Pique);


    sf::RenderWindow App(sf::VideoMode(800,600,32), "testSFML");

    while (App.isOpen())
    {
        sf::Event event;
        while (App.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                App.close();
        }
        App.clear();
        App.draw(as_de_pique.Gets());
        App.display();
    }

    return 0;
}


 

48
Graphique / Re : [SFML 2.0 RC]problème d'affichage
« le: Août 24, 2012, 11:40:10 pm »
je joue pas mal avec les namespaces ça vient peut-être de là (mais je suis tellement naze que j'arrive pas à suivre le cheminement ;D)

49
Graphique / Re : [SFML 2.0 RC]problème d'affichage
« le: Août 24, 2012, 11:28:10 pm »
carré blanc^^

50
Graphique / [SFML 2.0 RC]problème d'affichage
« le: Août 24, 2012, 06:09:35 pm »
Bonjour,

Petite erreur classique, mais j'ai tellement le nez dans le guidon que je ne pige pas :

J'ai un jeu de 54 cartes...

namespace Jeu_54_cartes
    {
        using namespace Cartes;
        static std::vector<Carte> Jeu;
        static void Init()
        {
            Jeu = {
                    {Deux, Carreau}, {Trois, Carreau}, {Quatre, Carreau}, {Cinq, Carreau},  {Six, Carreau},  {Sept, Carreau},
                    {Huit, Carreau}, {Neuf, Carreau},  {Dix, Carreau},    {Valet, Carreau}, {Dame, Carreau}, {Roi, Carreau}, {As, Carreau},
                    {Deux, Coeur},   {Trois, Coeur},   {Quatre, Coeur},   {Cinq, Coeur},    {Six, Coeur},    {Sept, Coeur},
                    {Huit, Coeur},   {Neuf, Coeur},    {Dix, Coeur},      {Valet, Coeur},   {Dame, Coeur},   {Roi, Coeur},   {As, Coeur},
                    {Deux, Pique},   {Trois, Pique},   {Quatre, Pique},   {Cinq, Pique},    {Six, Pique},    {Sept, Pique},
                    {Huit, Pique},   {Neuf, Pique},    {Dix, Pique},      {Valet, Pique},   {Dame, Pique},   {Roi, Pique},   {As, Pique},
                    {Deux, Trefle},  {Trois, Trefle},  {Quatre, Trefle},  {Cinq, Trefle},   {Six, Trefle},   {Sept, Trefle},
                    {Huit, Trefle},  {Neuf, Trefle},   {Dix, Trefle},     {Valet, Trefle},  {Dame, Trefle},  {Roi, Trefle},  {As, Trefle},
                    {Joker, Sans},   {Joker, Sans}
                  };
        };
    }
 

Une grosse texture (cartes.png) que je gère dans le même namespace que la classe Carte :

#ifndef CARTE_HPP
#define CARTE_HPP

#include <iostream>

#include <SFML/Graphics.hpp>

namespace Cartes
{
    enum Valeur {Deux=2, Trois, Quatre, Cinq, Six, Sept, Huit, Neuf, Dix, Valet, Dame, Roi, As, Joker};
    enum Couleur {Carreau, Coeur, Pique, Trefle, Sans};
    static sf::Texture Cartes;
    const int taille_carte_x = 72;
    const int taille_carte_y = 98;


    class Carte
    {
        public:
            Carte(Valeur v, Couleur c);
            ~Carte();

            inline Valeur Getv() { return v; }
            inline void Setv(Valeur val) { v = val; }
            inline Couleur Getc() { return c; }
            inline void Setc(Couleur val) { c = val; }
            sf::Sprite& Gets() { return s; }

        protected:
        private:

            Valeur v;
            Couleur c;
            sf::Sprite s;
    };

    static void InitTextureCartes()
    {
        if (!Cartes.loadFromFile("Cartes.png"))
              std::cout << "erreur lors du chargement de la texture" << std::endl;
    }
}
#endif // CARTE_HPP
 

le constructeur de Carte :
Carte::Carte(Valeur v, Couleur c) :
    v(v),
    c(c),
    s(sf::Sprite())
    {
        //InitTextureCartes(); //si je décommente OK, sinon, carré blanc
        s.setTexture(Cartes);
        s.setTextureRect(sf::IntRect(v*taille_carte_x,c*taille_carte_y,taille_carte_x,taille_carte_y));
        //ctor
    }
 

et dans mon main je créé une carte et je la draw.


Ce qui me fait chier, c'est que ça n'a pas de sens de charger à chaque construction la grosse planches avec toutes les cartes, mais si je fais l'InitTexturesCartes() dans mon main c'est un coup d'épée dans l'eau...

Vous voyez ce que je ne vois pas ?



51
Discussions générales / Re : Présentation TheSilverWebsurfer
« le: Août 21, 2012, 12:03:51 pm »
Bienvenue ( sympa la démarche ;) )

Tu es graphiste pro et musicien pro, ou tu te qualifie toi-même comme ça car tu as un bon niveau dans ces domaines ?

Tu cherches une équipe ?

dernière question ;D : tu as quel niveau de noob exactement ?

52
Graphique / Re : Modifier sprite au pixel
« le: Juillet 27, 2012, 02:36:58 pm »
Tu as essayé de manipuler des pointeurs plutôt que des copies (j'ai l'impression que tu as tes m_bidule dans une classe et que tu appelle m_sprite ailleurs pour le draw et que du coup tu as une image blanche ^^

53
Graphique / Re : Modifier sprite au pixel
« le: Juillet 26, 2012, 10:30:28 am »
Bonsoir à tous,

Tout d'abord, je tiens à dire que j'ai bien lu les topics suivants :
http://fr.sfml-dev.org/forums/index.php?topic=8390.0
et surtout
http://en.sfml-dev.org/forums/index.php?topic=3543.0

Pourtant, je ne comprends pas pourquoi le code suivant :
    m_image.create(w, h);
    m_image.setPixel(0,0,sf::Color::Red);
    m_texture.loadFromImage(m_im);
    m_sprite.setTexture(m_texture);
laisse le m_sprite blanc sans le pixel rouge (mais de bonne taille au mois)

La solution est surement évidente, mais là je sèche   :-[

Merci d'avance

tu modifies m_image et tu charge m_im

55
Je suis un peu comme le facteur cheval

T'as répondu avec ton iPhone ou quoi ?  ;D Sinon faut que tu me dise où tu habites que je vois cela de mes propres yeux !   :D

Sinon, tu as l'air plutôt convaincu depuis le départ de ton choix (pour quelqu'un qui est venu demander "quel choix faire"...). Personnellement j'utilise SFML dès que j'en ai l'occasion, et si un jour à mon taf je pouvais le glisser (ce qui n'arrivera jamais) je le ferais. Mais si on me demande de faire une IHM, je crois qu'utiliser SFML ne va même pas me traverser l'esprit.

Donc pour résumer (mon avis personnel) : utiliser SFML serait contre-productif, si tu as du temps alors tu peux très bien te mettre à Qt, et le résultat n'en sera que meilleur puisque Qt a tellement de bouteille que ses dev ont du penser à des trucs (cas particulier, concepts, etc) dont on ne se doute même pas (comme pour Laurent et la couche bas-niveau de SFML que nous utilisateurs nous ne voyons jamais). apprendre à te servir d'un GUI style SFGUI sera surement moins évident que d'apprendre Qt, et restreindra tes possibilités (en plus le support n'est pas le même, la doc non plus je penses, etc).

J'aimerais bien avoir l'avis du créateur de SFGUI justement, je penses que bien qu'ayant fait une super GUI, il te dirait la même chose (à quelques nuances près).

Mais bon je me doute qu'il sera difficile ("qui a dit impossible ?") de te faire changer d'avis donc : feu vert !!



56
Tu appelles d'abord array1 (le vert) dans la méthode draw, puis array2(le bleu) qui du coup est dessiné par dessus. Juste à inverser les deux instructions normalement.

57
Discussions générales / Re : Recherche d'une GUI mais pas seulement...
« le: Juillet 13, 2012, 11:48:59 am »
Je comprends tout à fait ton amour et ton envie d'utiliser SFML^^. En effet, avec SFGUI par exemple en complément je penses que tu pourrais réussir à avoir quelque chose, et surtout ça te permettra de le faire avec une API que tu affectionne. Mais honnêtement, tu vas pas mal t'embêter pour pas grand chose, car comme déjà dit, Qt est faite exprès pour cela. Elle est très facile d'utilisation, très bien automatisée sur pas mal de points, très biens organisée, trèèèèès bien documentée (tu trouveras même les pages principales de la documentation entièrement traduites en français sur le site developpez.com), et il existe de bon tutos pour t'aider à rapidement la prendre en main.

Maintenant, c'est toujours difficile de se lancer dans quelque chose où tout le monde attend de toi des résultats et de partir sur une lib qu'on connait pas. Mais je penses que tu sera beaucoup plus efficace et que ça aura vraiment "plus de gueule" qu'avec SFML complété par une SFGUI (qui n'a pas encore fait ses preuves comme Qt (de toute façon c'est même pas comparable je penses)).

Enfin, si tu souhaites créer une IHM sans SFGUI ou autre, tu vas devoir tout faire toi même et là niveau productivité tu perdras beaucoup de temps ;)

En tout cas bon courage ! ;)

58
Général / Re : Impossible d'executer un programme
« le: Juillet 11, 2012, 11:52:55 am »
Merci pour cette explication, je me coucherai moins con ce soir ;)

59
Général / Re : Re : Impossible d'executer un programme
« le: Juillet 11, 2012, 10:12:00 am »
Citer
pourquoi ne pas tout simplement avoir fait une libraire avec une compatibilité descendante infaillible dès la 1.0 ? C'est tellement simple
Là on parle de la compatibilité entre les versions de gcc, pas de SFML ;)
Ah oui au temps pour moi.

Citer
En fait ce qui pose problème c'est qu'une même version de gcc peut être compilée avec différentes options (modèle de threading, modèle d'exceptions, bibliothèque standard, ...), qui rendent ces versions incompatibles entre elles. Là on parle de compatibilité binaire, pas de ce que le compilo implémente du langage.

Euhh... en fait je croyais comprendre quelque chose à notre conversation mais je me suis peut-être un peu enflammé  ;D :
- modèle de threading, modèle d'exceptions, bibliothèque standard, ... : tu veux dire qu'on peut recompiler gcc à sa sauce et qu'en le faisant on obtiens des versions qui sont incapables de compiler le même projet ?
- ce que le compilo implémente ça a pas un impact sur les binaires et donc sur la compatibilité binaire ?


Mes question ont l'air bêtes je crois que j'ai rien compris, donc on va faire plus simple :
C'est quoi la compatibilité binaire ?

60
Général / Re : Impossible d'executer un programme
« le: Juillet 11, 2012, 09:35:08 am »
pourquoi ne pas tout simplement avoir fait une libraire avec une compatibilité descendante infaillible dès la 1.0 ? C'est tellement simple  ;D

Sinon pour la version de gcc, je le dis même si tu dois être encore plus au courant que moi, mais la dernière version téléchargeable de CodeBlocks (qui doit être l'IDE le plus utilisé par nous les débutants) propose gcc-4.6.2 je crois, qui permet d'utiliser une grosse partie (suffisante pour débuter et un peu plus) des nouvelles fonctionnalités de la dernière norme (je crois que la 4.7 ne rajoute que les mots-clés final et override (surcharge explicite) et les constructeurs délégués, y'a  surement d'autres trucs mais bon, c'est pas primordial pour tout le monde je penses) ou pas, et j'ai pas constaté autant de problèmes qu'avec 4.7, puisque j'ai du recompiler que les lib statiques pour la 2.0RC, à part ça ça fonctionnait niquel avec la 1.6 (et j'ai pas testé avec de plus vieilles) donc pour ce qui est de la rétrocompatibilité avec cette version t'aurais pas trop à te torturer le ciboulot  ;D.

En espérant que ça puisse t'aider ;)

Pages: « Précédente 1 2 3 [4] 5 6 ... 9 Suivante »
anything