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 - Cmdu76

Pages: « Précédente 1 ... 4 5 [6] 7 8 ... 12 Suivante »
76
Général / Problème de deboggage avec un code du Livre SFML
« le: Novembre 15, 2013, 10:26:00 pm »
Bonjour,

Je suis sur un projet de mini-framework avec SFML en m'inspirant du livre sorti sur SFML

J'ai copié un bout de code du chapitre des States de la fonction registerStates() dans le StateStack.


template <typename T>
void StateManager::registerState(unsigned int id) //contrairement au livre j'ai décidé de ne pas utiliser les ID, car, contrairement au livre, l'utilisateur de mon mini-framework n'est pas sensé toucher aux fichiers.
{
        mFactories[id] = [this] ()
        {
                return State::Ptr(new T(*this, mContext));
        };  /* LIGNE QUE LE DEBUGGER SIGNALE COMME  PROBLEMATIQUE */
}
 

Erreurs du debugger :
- operator() (__closure=0xa27418)
- std::_Function_handler<std::unique_ptr<State, std::default_delete<State> > (), void StateManager::registerState<MenuState>(unsigned int)::{lambda()#1}>::_M_invoke(std::_Any_data const&)(__functor=...)
- std::function<std::unique_ptr<State, std::default_delete<State> > ()>::operator()() const

Voilà, je ne mis connais pas en functor ou en lambda expression ou même avec l'emploi des std::function donc si je pouvais avoir un petit coup de main je vous en serais reconnaissant :)








77
Projets SFML / Re : Projet d'extension de SFML. (SFML 3D)
« le: Novembre 13, 2013, 02:28:02 pm »
Tu pourrais mettre le code sur GitHub ou autre afin qu'il soit disponible n'importe quand et qu'on puisse t'aider au passage ?

Sinon au niveau du titre, SF3DML serait plus adapté mais c'est plus dur à dire xD

78
Graphique / Re : Stocker et utiliser une image depuis une std::string
« le: Octobre 17, 2013, 10:10:05 pm »
C'est pas vraiment le fait de les cacher, mais plutôt pour permettre de ne donner qu'un seul .exe sans rien à côté.

En tout cas merci pour vos réponses :)

79
Graphique / Stocker et utiliser une image depuis une std::string
« le: Octobre 16, 2013, 11:24:35 pm »
Bonjour,

Je suis en train de travailler sur un programme et j'aimerais le distribuer.

Ducoup j'aimerais donner juste le .exe sans filer des documents et fichiers (images/sons/...)

J'aimerais savoir s'il est possible de créer un fichier .cpp à part qui me retourne une std::string contenant le code d'une image (quand on fait clic-droit, ouvrir avec notepad++ ou autres logiciels du même type) et de charger cette string en tant que Texture avec loadFromStream ou un truc du genre...

Voilà, j'aimerais savoir si c'est faisable et surtout si ça a déjà été fait :)

80
Discussions générales / Re : SFML Game Development -- Un livre sur SFML
« le: Septembre 29, 2013, 06:20:15 pm »
Super livre !

J'en suis actuellement à la partie sur les States.
Je pensais maîtriser le concept de ResourceHolder avant de lire le livre et sérieusement, celui du livre est vraiment 10x plus puissant...
Pareil, la partie sur les States s'annonce aussi plutôt pas mal par rapport au système simpliste que j'utilisais pour gérer mes States...
Et comme dit un peu plus haut, la partie sur les Commands/Events est vraiment énorme !

J'ai hâte de le finir ce super bouquin !

81
Général / Re : Concept des States
« le: Août 14, 2013, 12:00:12 am »
Finalement c'est bon après une recherche rapide j'ai fini pas trouvé un bon exemple suffisamment clair

82
Général / Concept des States
« le: Août 13, 2013, 11:46:41 pm »
Bonjour,

Je poste ici car depuis pas mal de temps je suis en train de chercher à faire un truc plutôt optimisé et donc je vois pas mal de gens utilisant des States et StateManager.

Donc je sais que ce n'est pas à proprement parler une partie intégrante de SFML mais beaucoup d'utilisateurs utilisent ce concept (si je suis pas dans la bonne catégorie bougez -moi, je pense avoir choisi la plus appropriée)

Est-il possible d'avoir des explications sur le fonctionnent d'un tel système (rapide) ou un morceau de code "clair" ?

Merci d'avance :)

83
Système / Re : TextEntered trop rapide...
« le: Août 13, 2013, 11:39:25 pm »
Enfin pardon 6 caractères en ... juste le temps d'une pression :)
Du coup j'ai ralenti avec un sleep mais bon c'est pas terrible... enfin bref pour le moment je vais me contenter de ça

84
Système / Re : TextEntered trop rapide...
« le: Août 13, 2013, 10:49:20 pm »
Trop rapide du genre 6 caractères en une seconde...

while(app.isOpen()) //inclut les fonctions display, clear et draw (ce dont on avait débattu sur un autre sujet xD)
    {
        while(app.pollEvent()) //inclut ma fonction onEvent
        {
            if(CmEvent::clicLeft(app.getEvent()) && boutonT.isHover(app.getWindowPtr()))
            {
                boutonT.centerText("Bim! Centré!");
            }
            if(CmEvent::clicLeft(app.getEvent()) && boutonI.isHover(app.getWindowPtr()))
            {
                boutonI.centerImage();
            }
            if(CmEvent::enterPressed(app.getEvent()) && Input::getActiveInputPtr() != NULL)
            {
                boutonT.centerText(Input::Input::getActiveInputPtr()->returnString());
            }
        }
    }

bool Application::pollEvent()
{
    bool retour = mWindow.pollEvent(mEvent);
    if(mEvent.type == sf::Event::Closed)
        close();
    else
        mGuiMgr.onEvent(mEvent,&mWindow);
    return retour;
}

Est-ce que ça peut avoir un rapport avec le fait que j'utilise un FrameRateLimit un peu trop élevé ?
Eh bien nan... Je viens de tester....

85
Système / TextEntered trop rapide...
« le: Août 13, 2013, 10:24:55 pm »
Bonjour à tous !

Je travaille sur des zones de saisies de textes mais l'entrée est trop rapide...

Pourtant j'utilise bien la gestion de TextEntered et pas KeyPressed... Ensuite j'ai essayé d'activer setKeyRepeatEnabled(false) mais rien ne change...

Mon code :

void Input::onEvent(sf::Event event,sf::RenderWindow* window)
{
    if(isHover(window) && event.type == sf::Event::MouseButtonPressed && event.mouseButton.button == sf::Mouse::Left)
    {
        select(this);
    }//Select permet de définir quel est le champ séléctionné

    if((InputSelected == this && event.type == sf::Event::TextEntered && event.text.unicode > 64 && event.text.unicode < 91)  /* 64 < a < 91 = MAJ */
    || (InputSelected == this && event.type == sf::Event::TextEntered && event.text.unicode > 96 && event.text.unicode < 123) /* 96 < a < 123= MIN */
    || (InputSelected == this && event.type == sf::Event::TextEntered && event.text.unicode > 47 && event.text.unicode < 58)) /* 47 < a < 58 = NUM */
    {
        addChar(event.text.unicode);
    } // Donc ici on ajoute un caractère à ma string dans la zone de saisie
 

    if(InputSelected == this && event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::BackSpace)
    {
        removeChar();
    } //et ici on enlève le dernier
}

Quelqu'un a-t-il une solution ? Merci d'avance :)

86
Rien à redire, en fait tu as raison :)

87
Très bon arguments, je m'incline :)

Le premier est le moins percutant mais je comprends que pour une lib de cette qualité ce n'est pas possible.

J'avoue ne pas du tout avoir pensé au second...

Et le troisième je savais que ça n'avait pas de sens mais c'était plus pour le côté "pratique" xD

Pourquoi ne pas ajouter alors une fonction isRunning() qui ferait ça, du coup 1-On ne ment pas car elle est prévue pour, 2-Bah du coup elle est prévue pour donc les gens peuvent utiliser isOpen() quand même pour leurs tests, 3-Tant pis pour la couleur en argument ou une couleur par défaut

Je te laisse jeter un coup d'oeil à mon code où justement j'utilise cette technique, même si comme tu me le dis avec l'exemple du CPU/GPU, ici c'est une petite application et que pour les grosses cela ne fonctionne pas terriblement bien...

#include <SFML/Graphics.hpp>
#include "include/Application.h"

int main()
{
    Application app;

    BoutonText bouton = app.newBoutonText(app.getTexture("gui.png"),sf::IntRect(0,0,396,35),sf::IntRect(0,35,396,35),sf::IntRect(0,70,396,35),sf::Vector2f(0,0),4,10,"Clique pour centrer",23,app.getFont("cloister.ttf"),sf::Color(255,255,255));
    BoutonImage boutonI = app.newBoutonImage(app.getTexture("gui.png"),sf::IntRect(0,0,396,35),sf::IntRect(0,35,396,35),sf::IntRect(0,70,396,35),sf::Vector2f(50,50),4,10,app.getTexture("gui.png"),sf::IntRect(0,70,180,10));

    while (app.isOpen()) //Application::isOpen inclut les fonctions display, clear et drawGui
    {
        while (app.pollEvent()) //Application::pollEvent inclut la gestion de la fermeture de la fenêtre mais ça c'est encore autre chose et je comprends que tu ne veuilles pas
        {
            if (CmEvent::clicLeft(app.getEvent()) && bouton.isHover(app.getWindowPtr()))
            {
                bouton.centerText("Bim! Centré!");
            }
            if (CmEvent::clicLeft(app.getEvent()) && boutonI.isHover(app.getWindowPtr()))
            {
                boutonI.centerImage();
            }
        }
    }
    return 0;
}

88
Bonjour à tous !

Je suis en train de travailler sur un petit projet ici : http://fr.sfml-dev.org/forums/index.php?topic=12617.0

Et je viens de réfléchir à comment simplifier au maximum ma fonction main (j'ai sûrement pas encore uploadé ma dernière version)

Donc premièrement je suis venu repenser l'ordre d'affichage "traditionel" qui est :
window.clear()
window.draw(...)
window.display()

Je me suis dit que finalement, vu que la boucle se lit "vite", que le code du haut et celui-ci revenait au même :
window.draw(...)
window.display()
window.clear()

J'ai fait des tests, aucuns problèmes :)

Maintenant c'est la que j'ai poussé à la simplification "extrême", j'ai ajouté les fonctions display() et clear() dans la fonction isOpen() comme ceci :

bool Application::isOpen()
{
    bool running = mWindow.isOpen();
    display();
    clear();
    return running;
}

//Dans mon projet, je travaille sur une classe Application qui comporte une RenderWindow et ses méthodes (que je peux donc modifer)

et donc après ça je peux dessiner tranquillement dans ma boucle isOpen() sans me soucier des display et clear :)

Bon voilà c'est pas grand chose mais finalement quand on compte le nombre de fois qu'on écrit ces fonctions :)

Ensuite j'ai essayé de voir les avantages de "l'ancienne" méthode, finalement le seul inconvénient c'est le fait que clear peut prendre un paramètre... Mais en fait, il suffit d'ajouter la couleur du clear en paramètre à isOpen() ;)

Voilà, je pense que cette petite chose peut être simplifiée :)




89
Projets SFML / Re : [Gui] CmGui
« le: Août 12, 2013, 10:01:00 pm »
Je suis d'accord mais ici tu les crées rapidement et tu les dessines facilement => Simple and Fast :)

Nan enfin sérieusement, je trouve que c'est plus complet et ça va faciliter ma façon de faire et donc je le partage au cas où :)

Et oui, même dans le cas où tu affiches directement une image, la classe Bouton est beaucoup plus simple :)

C'est aussi vachement plus simple quand tu as plusieurs boutons, ici tu ne te galères pas à les gérer un par un, car certaines actions sont groupées, mais tu peux quand même manipuler tes boutons un par un si tu le désires.

Edit : Bop ! Je viens d'ajouter un systeme de gestion des ressources et l'activation/désactivation des objets ainsi qu'une classe Application qui comprends la RenderWindow et le ResourceManager! Je l'uploaderai peut-être demain :)

Edit : Je vais refaire un Edit de la présentation car ce que je viens de faire simplifie vraiment encore plus le truc xD

90
Projets SFML / [Gui] CmGui
« le: Août 12, 2013, 07:21:28 pm »
Bonjour à tous !

Je présente rapidement un projet que j'ai commencé hier soir (le 11/08/13).
Donc mon but lorsque j'ai démarré ce projet était de réaliser principalement des Boutons
Avant je me compliquait la tâche en utilisant environ 10 lignes par bouton entre la texture, la sprite, la position, le textureRect, le BoundingRect, le texte à l'intérieur... et je ne vous parle pas de la gestion du survol et du clic...
Et je ne vous en parle même pas quand on arrive à un page avec plusieurs boutons...

Enfin bref, j'ai donc crée quelques classes afin de simplifier tout ça :)

Voici un exemple d'un fichier main.cpp :

#include <SFML/Graphics.hpp>
#include "include/Application.h"

int main()
{
    Application app;

    BoutonText bouton = app.newBoutonText(app.getTexture("gui.png"),sf::IntRect(0,0,396,35),sf::IntRect(0,35,396,35),sf::IntRect(0,70,396,35),sf::Vector2f(0,0),4,10,"Clique pour centrer",23,app.getFont("cloister.ttf"),sf::Color(255,255,255));
    BoutonImage boutonI = app.newBoutonImage(app.getTexture("gui.png"),sf::IntRect(0,0,396,35),sf::IntRect(0,35,396,35),sf::IntRect(0,70,396,35),sf::Vector2f(50,50),4,10,app.getTexture("gui.png"),sf::IntRect(0,70,180,10));

    while (app.isOpen()) //Application::isOpen inclut les fonctions display, clear et drawGui
    {
        while (app.pollEvent()) //Application::pollEvent inclut la gestion de la fermeture de la fenêtre
        {
            if (CmEvent::clicLeft(app.getEvent()) && bouton.isHover(app.getWindowPtr()))
            {
                bouton.centerText("Bim! Centré!");
            }
            if (CmEvent::clicLeft(app.getEvent()) && boutonI.isHover(app.getWindowPtr()))
            {
                boutonI.centerImage();
            }
        }
    }
    return 0;
}
 

Comment ça marche :

Je crée mon Application qui contient donc la fenêtre et un CmGui (GuiManager). Quand je crée un bouton je le crée depuis la méthode de l'Application car elle me retourne le bouton mais ajoute aussi un pointeur vers celui-ci dans un tableau. Quand j'appelle ma fonction drawGui, les boutons testent le survol et s'affichent.

Donc j'explique certains de mes choix que vous pouvez trouver bizarre ou peu adapter :

- Passer la RenderWindow en pointeur à certaines fonctions : Je me sert habituellement beaucoup des pointeurs sur les Window dans des applications plus conséquentes, voilà pour ce choix.

- Le grand nombre d'argument pour créer un bouton : Je préfère mettre tous les paramètres d'un coup même si cela et un peu galère mais au moins c'est fait en une ligne et une fois que cette ligne est bien on est tranquille :)

Liste des classes :

- Application : Contient le CmGui et une RenderWindow
- ResourceManager : Stocke les Textures, Fonts, et SoundBuffers afin de ne les charger qu'une seule fois et d'y accèder facilement.
- CmGui : Classe qui gère un paquet de GuiObject pour l'affichage ou le survol
- GuiObject : Classe mère de tous les objets (Bouton,BoutonText,BoutonImage)
- Bouton : Hérite de GuiObject, classe mère de BoutonText et BoutonImage, affiche un bouton vide
- BoutonText : Hérite de Bouton, et rajoute un texte à l'intérieur du bouton
- BoutonImage : Hérite de Bouton, et rajoute une image à l'intérieur du bouton
- CmEvent : Hérite de sf::Event, peu utile je l'avoue mais reste pratique avec ses fonctions static pour les test des clic (un peu plus lisible)

Sources : http://charles.mailly.free.fr/CmGui.rar

Pourquoi poster quelques choses de pas fini, incomplet, et pas optimisé ?

En présentant mon "projet" je cherche à avoir des avis différents, de gens sûrement plus expérimenté que moi mais aussi des idées nouvelles, des améliorations....

Futur :

- Un constructeur Bouton() qui permet de définir des Boutons par défaut
- Un fichier (XML ou autres) afin de définir les propriétés d'un bouton dedans
- Rajouter des méthodes de manipulation pour les boutons
- Rajouter d'autres GuiObjects :
    - Zone de texte
    - Fond d'écran
    - HUD
- Réglé quelques bugs et optimiser au maximum :)

Voilà, je vous remercie d'avoir pris le temps de me lire, et je vous remercie d'avance pour vos idées d'améliorations et commentaires :)

PS : Ah oui aussi, je savais vraiment pas quoi prendre comme nom donc j'ai copié sur CEGUI en mettant mes initiales xD


Pages: « Précédente 1 ... 4 5 [6] 7 8 ... 12 Suivante »
anything