Messages

16

Graphique / [Résolu]linker error en utilisant openGL

« le: Septembre 18, 2014, 02:19:31 pm »

Bonjour

Je suis sous mac, et j'aimerais commencer à utiliser openGL, j'ai écrit ce code tout simple :

#include <SFML/Window.hpp>
#include <SFML/OpenGL.hpp>

int main()
{
    sf::Window window(sf::VideoMode(800,600), "Hello");
   
    glClearColor(1.0f,1.0f,1.0f,1.0f);
   
    while (window.isOpen())
    {
        sf::Event event;
       
        while (window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
        }
       
        glClear(GL_COLOR_BUFFER_BIT);
       
        window.display();
    }
   
    return 0;
}

Mais j'ai des erreurs de linkage pour glClearColor et glClear. Quelqu'un a-t-il eu le même problème ?

17

Général / Re : Faible sensibilité de la molette de souris pour event.mouseWheel.delta

« le: Septembre 13, 2014, 11:00:36 am »

Indeed

Par contre Laurent parle de Windows dans son premier post, mais du coup le problème existe aussi sur mac, faut lui dire :p Bon, mais s'pas bien grave tout de même, c'qu'une molette.

Merci de ta réponse G. et bon courage à Laurent !

PS : SFML rocks

18

Général / Faible sensibilité de la molette de souris pour event.mouseWheel.delta

« le: Septembre 13, 2014, 12:59:19 am »

Bonjour,

Ce post concerne la gestion des évènements sur SFML 2.1

Je remarque une faible sensibilité à la molette de souris : lorsque je la fais tourner d'un cran, la SFML détecte bien un mouvement de molette (event.type == sf::Event::MouseWheelMoved) mais le delta enregistré est de 0. Idem avec deux, voire trois crans. Ce n'est que lorsque je donne un bon coup de molette que le delta dépasse, en valeur absolue, le 0. Je suis sur mac, je ne sais pas si les autre systèmes sont concernés par ce petit désagrément

Y a-t-il une solution ? Sinon, j'espère que la SFML 2.2 prendra en compte ce petit post !

Bonne journée,

19

Graphique / Passage de plusieurs sf::Text sur une sf::RenderTexture [SFML 2.0]

« le: Janvier 04, 2014, 07:47:21 pm »

Bonjour, j'essaie de créer une console pour mon petit programme, comme sur cette image :
http://www.legendra.com/media/screenshots/pc/baldur__s_gate/screen_10.jpg

Pour pouvoir faire des mots de différentes couleurs sur une même ligne, j'utilise un pair de sf::Text. Un deque contient ces pair, chaque élément du deque représentant une ligne.

Cette console est donc un champ de texte et pour faire défiler ce texte, il me faudrait une slidebar. Je suis donc parti sur l'idée suivante : je crée une sf::RenderTexture sur laquelle je dessine tous mes sf::Text, je passe cette renderTexture sur un sprite et ensuite, pour faire défiler mon texte, j'utiliserai la méthode setTextureRect. C'est un peu barabare, je préfèrerai ne pas avoir à passer par une renderTexture, si vous avez une autre idée je suis bien sûr preneur..

Voici donc ma classe Console :

Console.h

class Console : public sf::Drawable, public sf::Transformable
{
public:
   
    Console();
       
    void type(std::string string1, std::string string2 = " ");
   
    void setColors(sf::Color color1, sf::Color color2 = sf::Color::White);

    void clear();

    void finalize();
       
private:
   
    std::deque<std::pair<sf::Text,sf::Text> > lines;
   
    std::pair<sf::Text,sf::Text> line;
   
    sf::Font font;
       
    int lineSpacing;
   
    sf::RectangleShape textField;

    sf::RenderTexture renderTexture;
   
    sf::Sprite sprite;
   
private:
   
    virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;
};

Console.cpp

Console::Console()
{
    font.loadFromFile("/Users/HéhéVousSaurezPaaas/Desktop/Data Files/Font/Chantelli_Antiqua.ttf.ttf");
   
    line.first.setFont(font);
   
    lineSpacing = font.getLineSpacing(12)-3; // -3 = pour rapprocher les lignes entre elles

    line.first.setCharacterSize(12);
   
    line.second.setCharacterSize(12);

    line.second.setFont(font);
   
    textField.setSize(sf::Vector2f(700,100));
   
    textField.setFillColor(sf::Color(0,0,0,175));
}


void Console::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    states.transform *= getTransform();
   
    target.draw(textField, states);
   
    /*
    for (int i=0; i<lines.size(); i++)
    {
        target.draw(lines[i].first, states);
        target.draw(lines[i].second, states);
    }
    */

    target.draw(sprite, states);
}


void Console::type(std::string string1, std::string string2)
{
    // On commence par assigner les chaines de caractère
    line.first.setString(string1);

    if (string2 == " ")
    {
        string2.clear();
    }
   
    line.second.setString(string2);
   
    // Puis on gère les positions : si c'est la première ligne qu'on écrit
    if (lines.empty())
    {    
        // on la palce en (0,0)
        line.first.setPosition(0,0);
    }
   
    // Sinon
    else
    {
        // Il faut revenir à la ligne
        line.first.setPosition(0,lines.size()*lineSpacing);
    }
   
    line.second.setPosition(line.first.getGlobalBounds().width,line.first.getPosition().y);
   
    lines.push_back(line);
}

void Console::setColors(sf::Color color1, sf::Color color2)
{        
    lines.back().first.setColor(color1);
   
    lines.back().second.setColor(color2);
}

void Console::finalize()
{
    renderTexture.create(700,300);
   
    renderTexture.clear(sf::Color::Transparent);
   
    for (int i=0; i<lines.size(); i++)
    {
        renderTexture.draw(lines[i].first);
        renderTexture.draw(lines[i].second);
    }
   
    renderTexture.display();
   
    sprite.setTexture(renderTexture.getTexture());
}

void Console::clear()
{
    lines.clear();
}

Et un petit exemple d'utilisation :

Console console;
   
   
   
    console.type("Bonjour", "je");
   
    console.setColors(sf::Color::Yellow, sf::Color::Green);
   
    console.type("suis le ", "capitaine sur ce navire");
 console.setColors(sf::Color::Blue);

    console.finalize();

// boucle du jeu...
window.draw(console);

 

Ce code ne marche pas, bien entendu, et cette méthode finalize() et appelée à disparaitre, du moins je l'espère.. Après des tests, j'ai compris que la partie "renderTexture.clear, renderTexture.draw, renderTexture.display()" devait se faire à chaque boucle, il serait donc logique de faire ces étapes dans la fonction draw mais puisqu'elle est const, je suis un peu embêté.

Tel quel, ce code donne un texte très flou, c'est même pas du flou en fait, c'est plus des barres, de même longueur et de même couleur que les mots. Pas vraiment exploitable, donc ^^

Comment faire ?

Merci de vos réponses.

20

Général / Re : SFML 2, version finale : erreur de compilation sous X Code ( mac )

« le: Avril 30, 2013, 01:23:48 pm »

Re !

@Hiura : J'avais effectivement commencé par faire cette bêtise, mais je l'avais corrigé ensuite, et puis... Ben c'était pas ça 

C'est donc Laurent qui m'a mis sur la piste : en fait, je n'avais pas remplacé les dossiers lib et include. Bon maintenant que c'est fait tout marche nikel mais je comprends pas trop : sur le tuto, j'ai compris qu'en gros on a le choix entre les framework et les dylib. Pourtant, il a fallu que j'installe les deux pour que mes projets re-compilent bien gentilment
En tous cas merci de m'avoir aidé, c'est bien cool de votre part

Mr Pchoun !

21

Général / SFML 2, version finale : erreur de compilation sous X Code ( mac ) [Résolu]

« le: Avril 30, 2013, 03:24:47 am »

Bonjour,

Voilà voilà, quand j'ai vu que la version finale de SFML était sortie je me suis précipité, vous pensez !

Je n'ai donc supprimé aucun fichier de mon ordinateur, j'ai juste remplacé les fichiers à remplacer, soit :
- Les frameworks,
- Les bibliothèques externes,
- Les templates

Seulement voilà, quand je lance mes anciens projets, qui tournaient sous SFML 2 RC, ou que j'en crée de nouveaux (et dans ce cas, je n'oublie pas de sélectionner " C++98 with GCC and libstdc++ and target 10.5 " dans les options du nouveau projet), j'ai toujours la même erreur de compilation, qui semble avoir un lien avec sf::RenderWindow, allez savoir Je mets une capture d'écran, je pense que c'est mieux, je ne comprends même pas la nature de l'erreur en fait. Je précise que je tourne sous X Code 4.2.

Please Help !

Mr Pchoun.

[attachment deleted by admin]

22

Graphique / Priorité d'affichage et gestion de profondeur

« le: Avril 21, 2013, 03:36:04 am »

Hello tout le monde

Alors voilà, je suis en train de faire un petit moteur 2d en SFML (non isométrique), et au fur et à mesure que les choses avancent je commence un petit peu à me demander si ma manière de coder est la bonne. Pour l'instant je "travaille" sur des environnements relativement peu gourmands en ressources : deux ou trois personnages animés, aucune gestion de collisions, pas de pathfinding, une map en 500x500, bref.. Je peux être content de mon framerate mais j'ai peur qu'à force d'ajouter des paramètres et des calculs à mon moteur, ça ne commence à ramer sévère ! J'ai donc deux questions, l'une relative à la manière d'afficher mes sprites, l'autre portera sur la gestion de la profondeur ( même si en fait, ces deux questions sont plutôt liées )

S'agissant de la manière dont j'affiche mes sprites ( animés ou non ), j'ai une classe "GameBoard" qui possède une méthode draw, et qui prend en argument une référence vers la fenêtre active, donc sf::RenderWindow &target, et une référence vers l'horloge du programme, sf::Clock &clock. Ce plateau de jeu (GameBoard) possède dans sa section private une vector de sprite. Ces sprites ne sont pas ceux de la SFML mais une version personnalisée, ils sont dessinés sur &target au moyen d'une boucle for qui "passe " tout le vector, et sont mis à jour grâce à &clock, pour ceux qui sont animés.
Je me demandais si la boucle for est un choix judicieux ? Il est évident que la méthode draw de ma classe GameBoard a tout intérêt à être rapide puisqu'elle est appelée à chaque fin de boucle dans mon main, alors déjà que chacun de mes sprites animés a besoin d'être mis à jour, je suis pas sûr qu'une boucle avec incrémentation soit la manière de faire la plus optimisée. En même temps, je ne vois que cette solution, mais peut être que je me trompe ?

Quant à la manière dont je compte gérer la profondeur, je n'ai encore rien testé, ce sont juste des idées, et je voudrais savoir ce que vous en pensez : je compte utiliser un vector de tous les sprites, animés ou non, que j'aurais à afficher (et là je vous renvoie à la question précédente, et hop… boucle infinie, héhé ), vector qui contiendra, dans l'ordre, les sprites à afficher. Pour tout ce qui s'agira du décor (par exemple, pour les arbres ou les maisons), on est d'accord que ça ne bougera jamais, donc chaque map aura un fichier de données associé, dans lequel il sera écrit quels décors doivent être affichés en premier, en fait ils y seront tous écrits, dans le bon ordre. Pas de problème de ce côté là.
Le vrai problème vient des personnages qui eux, sont mobiles, et qui par conséquent changeront de place dans les priorités d'affichage. Il suffira d'un std::swap pour les déplacer dans le vector, mais je me demande encore comment déterminer cette priorité d'affichage. J'ai donc pensé à associer une sorte de " ligne de masquer/afficher " à chaque sprite.
Cherchez donc dans les fichiers joints, et modérez vous dans vos compliments sur mes talents de graphiste, s'il vous plait. J'en ai marre qu'on me jette des fleurs. On voit, en haut, trois sprites : le bleu, pour celui du personnage vert, le rouge, pour la maison, le orange, pour le personnage violet. Dans la vrai vie, si l'on peut dire, le personnage vert est derrière la maison, qui est elle même derrière le personnage violet. Dans mon modèle, la ligne de masquer/afficher du sprite bleu se trouve au dessus de celle de la maison et il est donc affiché en premier. Idem ensuite pour déterminer les priorités d'affichage entre sprite orange et rouge. Cette méthode me permet, dans le dessin du bas, de déterminer des priorités d'affichage dans des cas où elles ne sont forcément évidentes, puisque les sprites sont dans des positions identiques. Pourtant, il va de soi que le personnage est affiché derrière l'arbre, à gauche, tandis qu'il est devant la maison, à droite.
Mais cette méthode est à mon avis bien trop gourmande en ressources, et c'est bien ce qui m'inquiète. Ma fonction draw ferait beaucoup de test, beaucoup de calculs, parfois des "swap", et c'est sans compter les mise à jour des sprites animés, bref..

Que pensez vous de tout ça ?

[attachment deleted by admin]

23

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 09, 2013, 07:08:20 pm »

D'accord ! Je vais essayer de me débrouiller avec ça, alors.

Merci !

Mr Pchoun

24

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 09, 2013, 04:26:18 pm »

Oui oui, mais j'aimerais que la méthode d'update soit "contenue" dans la méthode draw, pour ne pas avoir à updater tous mes objets à chaque fin de boucle. Et du coup faudrait que ma classe dérive toujours de sf::Drawable, sauf que ma méthode draw prendrait en paramètre un drawable et une clock. C'est possible ça ? Comment qu'on fait ?

25

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 09, 2013, 03:29:24 pm »

D'accord, bon je vais rester sur plusieurs fichiers pour l'instant, puis à la longue si ça devient vraiment trop long je testerai la feuille de sprite, au cas où.

Mais je rebondis sur ta réponse précédente, Laurent : souvent, quand on te demande de l'aide pour une classe d'animation, tu suggères de créer une classe propre, nouvelle, spécialement dédiée à la gestion d'animation, sans dériver de sf::Sprite ou de sf::Drawable. Aurais tu quelques pistes à me donner s'il te plait, pour que je puisse créer une telle classe ?

Enfin, je sais pas trop d'où vient le blocage en fait. D'un côté, les sf::Drawable nécessitent une fonction d'update avant d'être affichés à l'écran, de l'autre, je n'arrive pas à trouver la classe qui contient la méthode draw ( sinon ce serait facile, je dériverais de cette classe, et je ferais une nouvelle fonction draw.. ). L'idéal serait que cette nouvelle fonction draw prenne deux paramètres : &drawable et &clock. Mais comment faire ?

26

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 06, 2013, 02:50:37 pm »

Mais pour ce genre de choses, mieux vaut que tu fasses selon ce qui te semble le mieux, les "bonnes pratiques" viendront avec le temps et l'expérience

Au contraire, vaut mieux que je parte dans la bonne direction, c'est pour ça que je viens demander ( le coup du modulo d'ailleurs, royal, ça marche impec )

Pour revenir sur l'idée de la feuille de sprite, j'ai une question toute bête : en fait là j'ai chargé une animation un petit peu longue, et le chargement de toutes les images met à peu près une demie seconde. Je me demandais si le chargement serait plus rapide avec une feuille de sprite ? Je veux dire, toutes choses égales par ailleurs, est-il plus long de charger une image de 100x50, ou deux de 50x50 ?

Mr Pchoun.

27

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 05, 2013, 09:47:52 pm »

Rien de te choque dans le nommage de ces trois membres ?
Tableau
m_sprite
clock

À part ces variables, je veux dire Non, effectivement, tableau et sprite iraient mieux, mais pour clock je vois pas le problème.

C'est un bon argument. Ceci-dit généralement on anime des "petites" choses, pas des entités de 900x900. La plupart des classes d'animation fonctionnent comme ça, et je n'ai encore jamais vu personne s'en plaindre

À voir alors, pour l'instant je vais me pencher sur les autres problèmes que tu as souligné.

Dans une application complète, le code de plus haut niveau va forcément gérer le temps, il n'y a pas que ton animation qui a besoin du temps. En fait toute la logique de l'application dépend en théorie du temps, et si chaque classe s'amuse à gérer sa propre horloge, ça ce n'est pas très propre. Imagine que l'utilisateur implémente un algorithme de gestion du timestep, ou bien veuille ralentir/accélérer le temps, ou bien encore mettre en pause le jeu. Dans tous ces cas ta classe ne marche pas.
Quant à l'update, où voudrais-tu le mettre ? Typiquement, les classes vont avoir une fonction d'update (pour faire tous les calculs) et de dessin (qui elle est const !). Encore une fois, il faut voir plus loin que simplement ta classe, il faut la concevoir de manière à ce qu'elle puisse s'intégrer sans mal dans un squelette typique d'application.

On peut toujours envoyer un booléen dans la classe pour lui dire d'arrêter le temps. J'avais testé ça il y a quelques jours. Mais je vais essayer "d'externaliser" l'horloge, alors. Pour l'update, je sais pas, ce serait bien d'implanter cette fonction dans la fonction draw, tu vois. Malheureusement ça ne plait pas trop à mon compilateur.

Que dis-tu de ça (pas testé) :

void Anim::update()
{
    int frame = int(clock.getElapsedTime().asSeconds() / framerate) % Tableau.size();           
    m_sprite.setTexture(Tableau[frame]);
}

Ca corrige et améliore au passage d'autres trucs que je n'avais pas noté la première fois.
Ca va commencer à merder au bout de quelques heures car on ne redémarre jamais l'horloge, mais c'était plus joli comme ça

Je vais tester ça, je te tiens au courant

Mr Pchoun.

28

Graphique / Re : classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 05, 2013, 06:41:05 pm »

La variable "i" est redondante, utilise Tableau.size()

Check ! Au début j'avais mis sizeof(Tableau), ça marchait pas vraiment  , du coup j'ai mis cette histoire de i mais Tableau.size() marche très bien, merci.

Tes conventions de nommage sont pour le moins étranges, et surtout complètement hétérogènes ; la rigueur est ela première des bonnes habitudes à prendre

Ben ça pour le coup je vois pas trop ce que tu me reproches, toutes mes variables sont en minuscules, et le nom des fonctions commence par une minuscule puis les autres mots par des majuscules.

Même si ça a peu d'importance au final, essaye de baser ta classe d'animations sur une seule texture contenant toutes les poses, plutôt qu'une texture différente pour chaque pose ; du coup le paramètre de addFrame devient un sf::IntRect plutôt qu'un nom de fichier

Je suis pas trop pour : imaginons que j'ai besoin d'afficher une grosse animation à l'écran, une animation qui prenne quelque chose du genre 900x900, et que j'ai besoin de 50 étapes de mouvement par exemple. Tu me conseilles de faire une feuille de sprite si j'ai bien compris, mais j'avais vu sur un autre sujet que le chargement d'image est limité par un poids limite, fixé par la carte graphique. Si ma feuille de sprite a des dimensions trop grandes, j'ai peur qu'elle soit trop lourde que la carte graphique ( pas forcément la mienne, mais celle des éventuels autres utilisateurs ) n'accepte pas. Tu peux me dire ce que tu en penses ?

Tu peux dériver de sf::Transformable si tu veux hériter automatiquement de toutes les fonctions de transformation (du coup pas besoin de redéfinir setPosition) -- pour que ça marche il faut juste ajouter dans le draw : states.transform *= getTransform();

Check !

Laisse l'appelant donner à ta classe le temps écoulé, ne le gère pas directement

C'est à dire ? Il faudrait que je déclare un sf::Clock dans mon main, et que je l'envoie en argument de ma classe, lorsque j'initialise ma fontaine ? Ça me parait pas très propre.. À moins que ça m'évite, ensuite, d'avoir à écrire un fontaine.update() à la fin ? Parce que justement, ce update me parait pas très propre non plus 

Ton histoire de +1 et -1 c'est pas clair, et à mon avis pas utile

Faut croire que si.. Je l'ai pas bien expliqué dans le Anim.cpp mais en tous cas, si on enlève ces +1 et -1, un des frame est vide, du coup une de mes images est blanches. C'est pas très joli ! Je vais essayer de retravailler ça.

Tu stockes ton framerate comme étant 1/x, puis tu divises par la suite par framerate ; pourquoi ne pas stocker x directement puis faire "temps * framerate" ? (ça change pas grand chose, mais pourquoi faire compliqué quand on peut faire simple ?)

Check ! C'était juste pour la lisibilité du code en fait, mais j'aurais qu'à expliquer ça dans un " // ".

Trop de parenthèses inutiles dans tes calculs

Check.

Après "clock.restart()" tu ne remets pas la texture 0 ? tu laisses ton anim à la dernière frame ?

Bien sûr, on est dans une loop, ce clock.restart() n'est là que pour marquer la fin du séquençage d'un certain nombre d'images, et pas la fin du séquençage de toutes les images chargées .

Merci encore pour tes conseils ! 

29

Graphique / classe Anim ( une autre ! ), des suggestions ? [SFML 2.0]

« le: Mars 05, 2013, 02:54:50 pm »

Bonjour !

Alors voilà, je viens de faire ma propre classe Anim, pour gérer les animations à l'écran. Il n'y a pour l'instant aucune fonction de pause ou même de déplacement. Considérez donc que ce code marche pour quelque chose comme une fontaine. Dans les grandes lignes, on va demander à la classe de faire un vector de textures ( chaque texture contiendra un fichier png, soit une étape du mouvement ). Ensuite, selon le temps écoulé, on va charger un élément x du vector dans un sprite, sprite qu'on va ensuite dessiner à l'écran. Ma classe est une dérivée de la classe sf::Drawable, du coup je sais pas trop si c'est bien d'utiliser des sprite à l'intérieur de ma classe, sachant que les sprites sont eux mêmes dérivés de la classe sf::Drawable.

Enfi bref, voici la bête :

Anim.cpp :

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

/* À chaque appel de cette fonction, on charge un nouveau fichier dans m_texture, puis on place une copie de m_texture dans un nouvel
élément de Tableau. i compte le nombre de fois que l'on répète cette action, soit le nombre d'éléments de Tableau */
void Anim::addFrame(std::string chemin)
{
    sf::Texture m_texture;
    m_texture.loadFromFile(chemin);
    Tableau.push_back(m_texture);
    i++;
}

/* Simple réutilisation de la fonction setPosition de la classe sf::Sprite */
void Anim::setPosition(int x, int y)
{
    m_sprite.setPosition(x, y);
}

/* À chaque passage de la boucle while, on regarde le rapport suivant : temps écoulé/temps d'affichage de chaque image. Ce rapport,
tronqué à la première décimale grace à une pseudo conversion en entier, nous permet de nous déplacer dans Tableau. Chaque texture,
chaque élément du tableau est successivement chargé dans m_sprite, m_sprite étant ensuite affiché à l'écran par la fonction
virtuelle draw, présente dans le header de cette classe.
On remarque un décalage de 1 : juste après le lancement de clock, le rapport, encore inférieur à 1, est tronqué à sa première décimale
et vaut donc 0. Or, la première case de Tableau n'est pas la case [0] mais la case [1] puisque la première fois qu'on a modifié le
Tableau c'était après un push_back. L'erreur est ensuite corrigée dans la fonction setTexture, par a-1. Notons enfin le clock.restart() :
la fonction marche en boucle, il est donc normal de réinitialiser l'horloge une fois que l'on a dépassé le temps total d'affichage d'une
boucle */
void Anim::update()
{
    int a=((clock.getElapsedTime().asSeconds())/framerate)+1;          
    if (a>i)
    {
        clock.restart();
    }
    else if (a<=i)
    {
        m_sprite.setTexture(Tableau[a-1]);
    }
}

/* x est le temps d'affichage de chaque frame, framerate représente donc le nombre de frame par seconde */
void Anim::setFrameRate(float x)
{
    x=1/x;
    framerate=x;
}
 

Anim.h : 

#ifndef Anim_h
#define Anim_h

#include <SFML/Graphics.hpp>

class Anim : public sf::Drawable
{
public:
   
    virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const
    {
        target.draw(m_sprite, states);
    }
    void addFrame(std::string chemin);
    void setPosition(int x, int y);
    void update();
    void setFrameRate(float x);
   
private:
   
    std::vector<sf::Texture>Tableau;
    sf::Sprite m_sprite;
    sf::Clock clock;
    unsigned int i;
    float framerate;
};

#endif
 

main.cpp :

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

int main()

    Anim fontaine;
   
    fontaine.addFrame("/Users/blabla/0.png");
    fontaine.addFrame("/Users/blabla/1.png");
    fontaine.addFrame("/Users/blabla/2.png");
    fontaine.addFrame("/Users/blabla/3.png");
    fontaine.addFrame("/Users/blabla/4.png");

    fontaine.setFrameRate(20);
    fontaine.setPosition(300, 200);
     
    sf::RenderWindow window(sf::VideoMode(800, 600), "Fenetre");
   
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
        }
        window.clear();
        fontaine.update();
        window.draw(fontaine);
        window.display();
    }
    return 0;
}
 

Voilà voilà… Et donc je me demandais si vous aviez des suggestions d'améliorations à faire, enfin ma classe marche plutôt bien, mais je suis ouvert aux critiques donc je viens vous demander votre avis !

Mr Pchoun.

30

Graphique / Re : Déplacement de sprite avec la souris [SFML 2.0][Résolu]

« le: Février 28, 2013, 02:18:04 pm »

Non non tu as bien compris, et tu as même su y répondre ! En effet, j'étais dans l'optique de me rapprocher le plus possible d'un univers "pixélisé", et c'est pour ça que j'avais fait mon calcul de cette manière.

Enfin.. ne vas pas demander pourquoi, dans ce cas, je n'ai pratiquement déclaré que des float et des sf::vector2f .. C'était au cas où Par contre, qu'est ce qu'une rasterization ? J'ai cherché sur le net, j'ai pas trop compris.