Messages

16

Suggestions de nouvelles fonctionnalités / Re : Paquet NuGet

« le: Septembre 21, 2013, 01:42:47 am »

Bon finalement, en rentrant de soirée j'ai été voir comment créer un paquet nuget pour du c++ et bah... c'est pas bien dur. Donc je l'ai fait.

Voici le code de création du paquet :

nuget {
        nuspec {
                id = sfml;
        version : 2.1.0.0;
        title: SFML;
        authors: {Laurent Gomila};
        owners: {Laurent Gomila};
        licenseUrl: "http://www.sfml-dev.org/license.php";
        projectUrl: "http://www.sfml-dev.org";
        iconUrl: "http://www.sfml-dev.org/images/logo.png";
        requireLicenseAcceptance:false;
        summary: "SFML provides a simple interface to the various components of your PC, to ease the development of games and multimedia applications. It is composed of five modules: system, window, graphics, audio and network." ;

        description: @"SFML provides a simple interface to the various components
                of your PC, to ease the development of games and multimedia applications.
                It is composed of five modules: system, window, graphics, audio and network.

        With SFML, your application can compile and run out of the box on the most
                common operating systems: Windows, Linux, Mac OS X and soon Android & iOS.

        SFML has official bindings for the C and .Net languages. And thanks to its
                active community, it is also available in many other languages such as Java,
                Ruby, Python, Go, and more.
        ";
        releaseNotes: "Release of SFML 2.1 libraries.";
        copyright: Copyright 2013;
        tags: { sfml, native, CoApp };
    }
       
        files {
                #defines {
                        SRC = sources\;
                }
               
                include: { "${SRC}include\**" };
                docs: { "${SRC}doc\**" };
               
                [x86,v90,debug] {
                        bin: "${SRC}bin\x86\v90\debug\bin\*";
                        lib: "${SRC}bin\x86\v90\debug\lib\*";
                }
               
                [x86,v90,release] {
                        bin: "${SRC}bin\x86\v90\release\bin\*";
                        lib: "${SRC}bin\x86\v90\release\lib\*";
                }
               
                [x64,v90,debug] {
                        bin: "${SRC}bin\x64\v90\debug\bin\*";
                        lib: "${SRC}bin\x64\v90\debug\lib\*";
                }
               
                [x64,v90,release] {
                        bin: "${SRC}bin\x64\v90\release\bin\*";
                        lib: "${SRC}bin\x64\v90\release\lib\*";
                }
               
                [x86,v100,debug] {
                        bin: "${SRC}bin\x86\v100\debug\bin\*";
                        lib: "${SRC}bin\x86\v100\debug\lib\*";
                }
               
                [x86,v100,release] {
                        bin: "${SRC}bin\x86\v100\release\bin\*";
                        lib: "${SRC}bin\x86\v100\release\lib\*";
                }
               
                [x64,v100,debug] {
                        bin: "${SRC}bin\x64\v100\debug\bin\*";
                        lib: "${SRC}bin\x64\v100\debug\lib\*";
                }
               
                [x64,v100,release] {
                        bin: "${SRC}bin\x64\v100\release\bin\*";
                        lib: "${SRC}bin\x64\v100\release\lib\*";
                }
               
                [x86,v110,debug,desktop] {
                        bin: "${SRC}bin\x86\v110\debug\bin\*";
                        lib: "${SRC}bin\x86\v110\debug\lib\*";
                }
               
                [x86,v110,release,desktop] {
                        bin: "${SRC}bin\x86\v110\release\bin\*";
                        lib: "${SRC}bin\x86\v110\release\lib\*";
                }
               
                [x64,v110,debug,desktop] {
                        bin: "${SRC}bin\x64\v110\debug\bin\*";
                        lib: "${SRC}bin\x64\v110\debug\lib\*";
                }
               
                [x64,v110,release,desktop] {
                        bin: "${SRC}bin\x64\v110\release\bin\*";
                        lib: "${SRC}bin\x64\v110\release\lib\*";
                }
        }
       
        targets {
                Defines += HAS_SFML;
        }
}
 

Suffit de regarder le code ci-dessus pour déduire l'arbo que j'ai utilisé. (Tous les fichiers ont été obtenus en downloadant toutes les versions Visual Studio que tu proposes au téléchargement ici, il manque les symboles car tu ne les fournits pas).
Ce qui me donne deux paquets que j'héberge ici (home serveur, donc pas beaucoup de bande passante) :
sfml.2.1.0.0.nupkg
sfml.redist.2.1.0.0.nupkg

Il faut impérativement prendre les deux !
Donc si ça te conviens on peut publier ça sur nuget.org. Dès que ce sera le cas je stopperai l'hébergement et les liens ci-dessus seront morts.

J'ai testé sur Visual Studio 2012 avec un projet console en debug/release en ciblant x86 et x64. Ca a l'air de bien fonctionner (vraiment génial d'ajouter ses dépendances comme ça en tout cas).

Quelques petites remarques :
- Ca serait cool de changer l'url du logo pour une version qui ne contient que "l'image", pas le texte "SFML". Parce que dans le gestionnaire de paquet ça rend pas terrible et SFML est déjà affiché vu que c'est le nom du paquet.
- Il faut impérativement >=NuGet-2.5. Sinon on ne peut installer le paquet que pour la solution et non le projet. Donc c'est quasi useless (il faut se taper toute la conf du projet à la main alors que c'est justement le but de NuGet d'éviter ça)
- Je n'ai pas réussit (pas vraiment cherché non plus) a permettre une configuration automatique du mode "statique". Mais je les inclus dans le paquet tout de même donc on peut changer ça à la main.
- Je n'ai pas géré les dépendances de SFML (libsndfile-1.dll et openal32.dll). Je les distribue avec le paquet tout comme toi. Idéalement il faudrait créer une dépendance vers des paquets nuget qui fourniraient ces dll. Je n'ai pas pris le temps de vérifier si ces paquets nuget existent.
- J'ai été obligé d'ajouter un fichier "SFML.hpp" dans le répertoire parent de celui contenant "Graphics.hpp" et autre. En effet, la commande qui génère le paquet ne conserve pas l'arborescence si je ne fais pas ça, du coup on doit faire #include <Graphics.hpp> au lieu de <SFML/Graphics.hpp>. Le fichier que j'ai ajouté se contente de faire un include SFML/*.hpp.
Si ça dérange je chercherai un moyen de le dégager tout en gardant la structure.

Voilà, je crois que c'est tout.

17

Suggestions de nouvelles fonctionnalités / Re : Paquet NuGet

« le: Septembre 20, 2013, 02:58:20 pm »

Je ne suis pas familier de la création de paquets nuget pour le moment, mais j'envisage d'en faire pour utilisation interne dans ma boite (pour du C# par contre). Une fois que j'aurais joué un peu plus avec le système, si j'ai un peu de temps et que personne ne s'y est collé d'ici là, je verrai a tenter de créer un tel paquet. Mais bon, je ne promet vraiment rien.

18

Suggestions de nouvelles fonctionnalités / Paquet NuGet

« le: Septembre 20, 2013, 02:28:55 pm »

Salut,
J'ai suivi avec attention l'évènement Going Native de cette année et j'y ai découvert que la gestion des bibliothèques via NuGet était maintenant possible pour les bibliothèques C et C++.
Est-il prévu que la SFML distribue un tel paquet ?

Au passage, Herb Sutter à fait un peu de pub pour SFML (a environ 1h18).

19

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Juin 03, 2013, 12:37:26 pm »

Ah d'accord, effectivement j'étais passé à côté de cette ligne.
Vu comme ça, ça simplifie grandement les choses.
Comme quoi on a bien fait de continuer d'en discuter parce que j'avais vraiment pas fait attention à la présence de cette ligne alors qu'elle est le point central de la solution...
Du coup je vais avoir un gros nettoyage à faire parce que j'ai déjà tout implémenté 

20

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Juin 03, 2013, 11:57:39 am »

En fait je crois qu'on dis la même chose depuis le début, ce n'est qu'une légère différence de vocabulaire qui donne l'impression qu'on est pas d'accord.

class AbstactNode
    : public sf::Drawable, public sf::Transformable
{
};

class SpriteNode
    : public AbstractNode
{
private:
    sf::Sprite mSprite;

public:
    // Un get/set sur le sprite
    sf::Sprite& getSprite() { return mSprite; }
    void setSprite(const sf::Sprite& s) { mSprite = s; }

    // Ré-implémentation de sf::Transformable
    void setPosition(float x, float y) { mSprite.setPosition(x, y); }
    void setPosition(const sf::Vector2f& p) { mSprite.setPosition(p); }
    // etc...
};

class RectangleShape
    : public AbstractNode
{
private:
    sf::RectangleShape mShape;

public:
    // Un get/set sur le sprite
    sf::RectangleShape& getShape() { return mShape; }
    void setShape(const sf::RectangleShape& s) { mShape = s; }

    // Ré-implémentation de sf::Transformable
    void setPosition(float x, float y) { mShape.setPosition(x, y); }
    void setPosition(const sf::Vector2f& p) { mShape.setPosition(p); }
    // etc...
};

AbstractNode* n = new SpriteNode();
n.setPosition(24, 73);
// etc...
 

Si je veux pouvoir faire du polymorphisme afin d'avoir un code capable de manipuler et dessiner les nodes, peut importe le type réel qu'il y a derrière, je suis bel et bien obligé d'implémenter sf::Transformable et sf::Drawable.
Si je me contente du get/set, alors je ne peux pas faire de .setPosition() sur mon node. Je suis obligé de savoir qu'il s'agit d'un SpriteNode pour faire un .getSprite().setPosition().
Pour autant, comme je disais plus haut, écrire un "proxy" me procure toujours un petit sentiment de gène, j'ai l'impression de faire un truc que je ne devrais pas.

C'est pour ça que, dans la mesure où tu as les Sprites et les Shapes qui héritent déjà de Transformable ET de Drawable, je ne comprend pas quelles sont les raisons qui font qu'il n'y a pas un héritage intermédiaire qui donnerai un parent unique à toute ces classes. Ce qui permettrait d'utiliser cette classe comme base pour le polymorphisme, sans pour autant m'en servir comme un framework ou un moteur.
Je ne compte pas dériver Sprite pour en faire un personnage par exemple.

En supposant que :

namespace sf
{
    class Transformable { /* ... */ };
    class Drawable { /* ... */ };
    class DisplayableObject :  public Transformable, public Drawable { /* ... */ };
    class Sprite : public DisplayableObject { /* ... */ }:
    class Shape : public DisplayableObject { /* ... */ };
}
 

J'aurai alors pondu un code de ce genre là :

class Node
{
// Tout ce qu'il faut pour gérer un arbre, un pointeur sur le parent, une liste d'enfant, etc...
};

class AbstractEntity
    : public Node
{
    virtual sf::DisplayableObject& getObject() = 0;
};

class CharacterEntity
{
private:
    sf::Sprite mSprite;
public:
    virtual sf::DisplayableObject& getObject() { return mSprite; }
};

void MoveAndDraw(AbstractEntity* entity, sf::RenderTarget& target)
{
    entity->getObject().setPosition(27, 93);
    target.draw(entity.getObject());
}
 

21

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Juin 02, 2013, 11:51:11 am »

@Eroy C'est à peu près comme ça que j'ai fait oui.
@Laurent Oui, ton code de ta première réponse et celui que j'ai utilisé (template en plus). Et cette méthode m'impose d'implémenter sf::Drawable et sf::Transformable. Et pour éviter d'implémenter ces deux interfaces tu m'a ensuite proposé un simple get/set du sprite, ce à quoi j'ai répondu que ça m'empêche de faire du polymorphisme et donc je préfère la solution 1.
Après rien ne m'empêche de faire un get/set de sf::Sprite sur le SpriteNode, mais pour autant je suis tout de même obligé d'implémenter sf::Drawable et sf::Transformable afin d'avoir une classe de base possédant les 2 interfaces et sur laquelle faire le polymorphisme.

22

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Juin 01, 2013, 11:27:26 pm »

Désolé pour le temps de réponse ...
Si je fais un getter/setter je ne peux à nouveau plus faire de polymorphisme.
Mon but c'est de faire un code qui parcourt le scenegraph et qui pourra call "draw" sur chaque noeud, mais également des setPosition, move, etc...
L'objet manipulé doit donc posséder l'interface Drawable ET l'interface Transformable.

Donc si je fait un SpriteNode qui expose un get/set de type sf::Sprite, mon "visiteur" devra savoir qu'il est sur un SpriteNode et non sur un ShapeNode ou autre, ce qui ne m'arrange pas du tout.
Alors que si j'expose toute l'interface, mon visiteur peut parcourir des "AbstractNode" et appeller ces méthodes quelque soit le type de noeud concret.

23

Graphique / Re : Polymorphisme Drawable&Transformable

« le: Mai 31, 2013, 05:05:21 pm »

J'avais effectivement considéré cette méthode.
Simplement je trouve lourd de devoir tout wrapper. J'ai franchement un mauvais sentiment quand je dois encapsuler un objet pour exposer 90-100% de son interface.
Enfin bon, y'a pas 30 types à encapsuler non plus donc c'est pas un drame.

J'ai vu, peu après avoir posté, que quelqu'un avait suggéré sensiblement la même chose. Ma question fait donc un peu doublon, désolé.

Enfin bon, je vais faire comme ça, merci d'avoir répondu.

24

Graphique / Polymorphisme Drawable&Transformable

« le: Mai 31, 2013, 04:27:54 pm »

Bonjour,
Je commence à peine a jouer avec la SFML que je connais donc très mal.

Je cherche à faire un système d'arbre pour gérer une scène. Chaque noeud est un Drawable&Transformable, autrement dit soit une Shape, soit un Sprite.

Cependant, il n'y a pas d'ancêtre unique commun aux shape et aux sprites. Du coup je ne vois pas comment faire pour faire quelque chose du genre :
sf::DrawableAndTransformable* item = new [RectangleShape|CircleShape|ConvexShape|Sprite]();

Je ne vois pas pourquoi cet ancêtre n'existe pas. Généralement quand je fais de l'héritage multiple je met toujours une interface entre les les parents et les enfants afin de pouvoir faire du polymorphisme tous les enfants ayant les mêmes parents en commun.
Est-ce volontaire ? Pourquoi ? Et du coup, une suggestion sur comment je pourrais faire autrement ?

25

Graphique / Re : problème d'optimisation, de fonction clock et de coordonnées.

« le: Décembre 15, 2012, 12:59:55 am »

Testé les deux, même perfs (ou plutôt absence de perfs) dans les deux, a peu de chose près (un léger avantage pour le release évidemment, mais rien de violent)

26

Graphique / Re : problème d'optimisation, de fonction clock et de coordonnées.

« le: Décembre 15, 2012, 12:31:51 am »

Hé bien comme je disais, je ne suis pas familier de la SFML, je n'ai pas fais le tour des docs, tutos, etc...

Du coup, si le redimensionnement de la fenêtre met à tout à l'échelle tout seul, ca expliquerai le résultat étrange obtenu...
Personnellement je trouve ça étrange que ce soit fait en automatique, c'est perturbant, j'ai l'impression de ne pas avoir la main sur l'affichage du coup.

Pour le coups de la division par 1000, je dois avouer que je n'ai pas fait attention au type de retour de asSeconds(), étant donné que asMilliseconds() retourne un int32, j'ai bêtement pensé que ce serait pareil pour asSeconds, et du coup la valeur retournée serait arrondie et d'une précision insuffisante pour effectuer un calcul de position.

Le t.resetGLStates(), c'est de ma faute ^^' Je l'avais mis pour faire un test d'un truc, et quand j'ai viré mon test j'ai zapé cette ligne ...
Ceci dit lors de mes tests cette après midi, je l'avais bien viré, sans résultat apparent (sauf peut être un rafraichissement plus fréquent de la fenêtre, mais toujours aussi chaotique)

27

Graphique / Re : problème d'optimisation, de fonction clock et de coordonnées.

« le: Décembre 14, 2012, 11:26:30 pm »

Je n'arrêtes pas de tenter de lui expliquer comment formatter son source pour qu'il soit lisible, mais bon...
Voila la version reformattée : http://pastebin.com/7rwf3LiN

EDIT:
J'ai tenté tout à l'heure de voir ce qui n'allait pas. Mais j'étais au boulot et je ne suis pas familier de la SFML, du coup je n'ai rien vu qui m'ai sauté aux yeux.
Cependant les problèmes que j'ai vu sont les suivants :
- Lors de l'ouverture de la fenêtre, un damier est dessiné, si la fenêtre change de dimensions, les dimensions du damier son recalculées. Ces dimensions sont bonne à l'ouverture de la fenêtre, mais si on maximise celle-ci le résultat est ... étrange...
- Faire un clock.restart à chaque itération de la boucle principale tue litérallement les perfs, on se retrouve avec 10-15 FPS.
Si, au lieu de faire un restart, on calcul un diff entre deux itérations (donc on laisse la clock courrir), les perfs reviennent à la normale.
- La fenêtre ne semble pas être rafraichit à chaque itération de la boucle. Genre le pion rouge ne semble pas bouger, déplacez la fenêtre et paf il change de position. Pourtant si je met un breakpoint dans son while, je m'y arrête bien. Chose étrange d'ailleurs, si je réduit et réouvre la fenêtre, elle se met a tourner "normalement".

Tout ces tests ont étés faits avec visual studio 2010, une SFML 2.0 que j'ai compilée via les sources, j'ai linké en static (avec SFML_STATIC de définit pour le preprocesseur). Le tout tournant sur un Vista sur un portable tout moisie (mais pas au point d'avoir 10 fps sur le dessin d'un damier...)