Quelques remarques

[Cpl.Bator]

  J'ai quelques remarques concernant "les shapes" et ceux qui en dérivents.
Je trouve dommage de ne pas avoir accès à ces membres privé , notamment les vertex array.
cela empêche de modifier un vertex quelconque, cela oblige le programmeur à refaire un custom drawable pour une forme qui existe déjà , cf: le cercle par exemple.
Des méthodes d’accès aux vertices dans sf::Shape serait un plus.

  Concernant la modélisation hiérarchique d'objet , se serait un plus si on avait une classe de type "node" qui s'occupe uniquement de la partie mathématique, avec les méthodes qui vont avec : getPosition( local ou globale ) , setPosition(local ou global) , etc...

  je sais que SFML n'est pas un framework , ces classes ne coûte rien , c'est de la "plus value" à la librairie.
la plupart qui codent avec la SFML utilise la librairie à tel point quelle fait partie intégrante de leur programme, c'est peu être une erreur de faire ainsi dans le domaine professionnel , mais dans le "monde d'amateur éclairé", si on utilise la SFML, c'est parce que on veut utilisé la SFML et pas autre chose. rendre son programme indépendant de la SFML comporte trop de travail pour un projet amateur.

 

 

[Laurent]

Je trouve dommage de ne pas avoir accès à ces membres privé , notamment les vertex array.
cela empêche de modifier un vertex quelconque, cela oblige le programmeur à refaire un custom drawable pour une forme qui existe déjà , cf: le cercle par exemple.
Des méthodes d’accès aux vertices dans sf::Shape serait un plus.

Tu n'expliques pas pourquoi tu penses qu'il faudrait ajouter ça. Ce qui est quand même le principal pour moi quand quelqu'un fait une demande de fonctionnalité

Mais ce que je peux déjà te répondre, par rapport à ce que tu as dit, c'est que si tu modifies un vertex d'un cercle, ce ne sera plus un cercle. D'où l'encapsulation fournie par sf::Shape et ses dérivées, pour justement éviter de dénaturer la forme. Après si tu veux une forme custom alors construis ton propre VertexArray, je ne vois pas le problème.

Concernant la modélisation hiérarchique d'objet , se serait un plus si on avait une classe de type "node" qui s'occupe uniquement de la partie mathématique, avec les méthodes qui vont avec : getPosition( local ou globale ) , setPosition(local ou global) , etc...

Ca c'est trop haut niveau. D'une part chacun voudra différentes fonctionnalités, d'autre part les gens auront souvent déjà un "cadre" (un scene manager, ou autre) dans lequel il faudra faire rentrer cette classe ; du coup c'est vraiment mieux si c'est l'utilisateur qui écrit sa classe. SFML n'est qu'un outil, je ne vois pas l'intérêt de fournir des interfaces / classes de base. Le seul effet que ça aura c'est que les gens vont venir se plaindre sur le forum que telle classe de base est mal foutue, ou n'as pas telle ou telle fonction. Comme c'était le cas avec sf::Drawable dans SFML 1.6.

Sinon, dommage d'avoir mélangé dans une même conversation deux sujets qui n'ont rien à voir. Ca n'aide pas vraiment à la lisibilité du forum

[Cpl.Bator]

c'est que si tu modifies un vertex d'un cercle, ce ne sera plus un cercle.

Je peu vouloir modifier uniquement la couleur , ca restera un cercle , ou les UV , ca restera aussi un cercle
L'exemple qui me viens à l'esprit , c'est le moteur de lumière d'un membre du forum , il aurais pu le faire avec un sf::CircleShape.

Sinon, dommage d'avoir mélangé dans une même conversation deux sujets qui n'ont rien à voir. Ca n'aide pas vraiment à la lisibilité du forum

Je ne voulais pas "floodé" avec 2 messages à la suite.

[Laurent]

Je peu vouloir modifier uniquement la couleur , ca restera un cercle , ou les UV , ca restera aussi un cercle

Si tu modifies la couleur d'un vertex alors getFillColor renverra un résultat incohérent.
Si tu modifies une coordonnée de texture alors getTextureRect renverra un résultat incohérent.

Faire le choix d'une API simple, c'est aussi s'imposer certaines limitations. On ne peut pas avoir le beurre et l'argent du beurre. Si je donnais accès aux vertexs, il faudrait que je revoie toute l'API des formes. D'ailleurs il n'y aurait plus vraiment d'API ; en donnant un accès au plus bas niveau d'implémentation, on se coupe la possibilité d'implémenter des fonctions par dessus.

Je ne voulais pas "floodé" avec 2 messages à la suite.

Je ne comprends jamais pourquoi les gens ont l'impression de mal faire en postant deux messages à la suite. Si ces messages étaient espacés de plusieurs jours au lieu de quelques minutes, ou s'ils étaient écrits par deux utilisateurs différents, personne n'aurait cette impression n'est-ce pas ? Et ça ne viendrait à l'idée de personne de les mélanger n'est-ce pas ? Donc, que ce soit par un même utilisateur et à quelques minutes d'intervalle, franchement ça ne change rien. L'important est que les sujets soient correctement organisés sur le forum.

[Lolilolight]

Moi, je la trouve bien la SFML comme elle est là, je l'ai modifiée un peu mais bon...

Avec la SFML 1.6 il n'y avais pas encore cet héritage avec sf::Drawable, donc, du coup, j'ai utiliser un std::vector de Vertex pour faire une Ellipse. (C'est pas un CircleShape mais une éllipse.)

Bon, pour la couleur, c'est dommage par contre qu'on ne sait plus faire de dégradé comme avant sans devoir passer par un VertexArray.

Une classe EllipseShape avec un dégradé aurait été parfait dans mon cas.

Je peux toujours m'amuser à faire une classe gradient si je veux avec une classe EllipseShape qui dérive de Drawable. ^^

SceneManager je suis pas trop pour personnellement, tout le monde ne fait pas toujours comme ça..., moi par exemple, je hais se système de scenenode comme on retrouve dans J3D, car, si je veux stocker les entités dans une grille, ou bien, un arbre binaire, bah..., ce sera plus compliqué, et, plus difficile à comprendre aussi je trouve se système de nodes.

[Lolilolight]

Sinon, j'ai une question, pourquoi ne peut on plus faire de setPosition, setRotation, etc..., donc en gros, pourquoi ne peut-on plus changer la géométrie d'un Shape ou Sprite à partir d'un Drawable ?

Avec la sfml1.6 je pouvais utilisé le polymorphisme en stockant tout mes Sprite et Shape dans un std::vector de type Drawable* et changer la géométrie de mes ombres, ici, je ne peu plus, je suis obligé de faire un dynamic_cast ou un static_cast vers un Shape ou un Sprite..., pour changer la gémotrie de mes ombres, qui sont soit un Shape pour les murs, ou bien un Sprite pour es éléments du décors.

[Hiura]

Parce que ce sont des méthodes de sf::Transformable.

[Lolilolight]

Ha, ok, bref, j'aurai préféré que un Drawable puisse contenir la géométrie des entités et la modifier.

[Laurent]

Note que tu peux toujours :
- cross-caster de sf::Drawable vers sf::Transformable si toutes les classes que tu stockes dérivent de ces deux bases (pas bien)
- concevoir ta propre hiérarchie de classes transformables / dessinables, en n'utilisant les classes SFML que comme détail d'implémentation (bien)

[Lolilolight]

Ok, donc, je dois avoir mes propres classes qui dérivent de sf::transformable, pour modifier la géométrie d'une entité et de plusieurs entité dessinable qui en héritent, ça va, j'ai compris.

[Cpl.Bator]

Je ne comprends jamais pourquoi les gens ont l'impression de mal faire en postant deux messages à la suite.

Je ne me suis même pas posé la question en fait, j'ai l'habitude des Forums, je poste comme je l'entends , je tacherais de faire plus attention la prochaine fois.

Si tu modifies la couleur d'un vertex alors getFillColor renverra un résultat incohérent.
Si tu modifies une coordonnée de texture alors getTextureRect renverra un résultat incohérent.

Effectivement , je n'ai pas penser à ce point précis, getFillColor & cie pourrais renvoyer un tableau de couleurs pour régler se problème, mais je ne suis pas fan & cela complexifie pour rien la lib.