Déshériter Sprite et ses soeurs de Transformable

[L01man]

Sprite, Text et Shape deviennent de simples Drawable. Mais on leur crée une méthode attachToTransformable(sf::Transformable&) pour que Draw fonctionne quand même. Pour cette méthode, il faut peut-être créer une classe intermédiaire.

En théorie, c'est un bon choix. Le visuel et le reste ne doivent pas être mélangés, et c'est très bien qu'il y ait des classes Drawable et Transformable séparées. Le problème, c'est qu'à partir de la génération de Sprite, les deux sont à nouveaux mélangés !
Finalement, on peut se retrouver avec des hacks comme un attribut Sprite auquel on passe les coordonnées de sa propre classe, et ça fait doublon.
Ca permet plus de flexibilité pour l'utilisateur. Il peut faire hériter sa propre classe Player, Actor ou Spaceship de Transformable au lieu de Sprite et à la place il utilise un attribut de son choix pour s'attacher à un Drawable autre que VertexArrays. Ça permet entre autre de pouvoir changer de Drawable en gardant les mêmes transformations. Par exemple, ça permet de simplifier les groupes. On crée un seul Transformable auxquels plusieurs Drawable sont liés.

[Lo-X]

Ce post ne fait-il pas doublon avec http://fr.sfml-dev.org/forums/index.php?topic=7765.msg51740 ?

[L01man]

Héhé, non, je n'irais pas jusqu'à dupliquer mes posts pour les faire accepter ^^.
Dans ce topic, je parle simplement de mettre setColor et d'autres méthodes directement dans Drawable, mais elles resteraient utilisables dans Sprite et les autres. Ici, je propose carrément d'enlever les setPosition, setScale, setRotation, etc. de Sprite et des autres, pour séparer le visuel du côté plus "physique" ou "mathématique".

[Laurent]

On peut déjà séparer sans problème avec l'API actuelle (tu peux ignorer la transformation du sprite et lui en passer une perso lors du draw), mais j'ai quand même voulu garder la simplicité des classes actuelles (reprises de 1.6), car la plupart des gens les utilisent comme ça.

[L01man]

tu peux ignorer la transformation du sprite et lui en passer une perso lors du draw

Ca risque d'être lourd en mémoire, non ?

car la plupart des gens les utilisent comme ça

N'est-ce pas une erreur ? Et de toute façon, tout le monde est obligé de les utiliser comme ça, à moins de changer le code source de la SFML ^^. Les habitudes changeraient sûrement avec cette séparation.
Quant à la simplicité, elle ne vaut que pour les mini, mini jeux. Dès qu'on fait quelque-chose de plus élaboré, on butte dedans.

La séparation entre Texture et Sprite est quelque-chose de similaire, même de très similaire : Sprite représente la partie plus mathématique, et Texture la partie graphisme. On peut lier plusieurs Sprite à une même Texture, avec des pointeurs.

[Laurent]

Ca risque d'être lourd en mémoire, non ?

Bof, non. On n'est pas en train de parler de 1 000 000 d'entités à afficher sur un système embarqué avec 32 Mo de mémoire.

N'est-ce pas une erreur ?

Disons qu'il faut que le S de SFML garde son sens. C'est sûr que si je laissais uniquement sf::VertexArray et sf::Transform ce serait suffisant, mais dans ce cas autant taper dans OpenGL directement.

Et de toute façon, tout le monde est obligé de les utiliser comme ça, à moins de changer le code source de la SFML

Non, c'est justement tout l'intérêt de la nouvelle API graphique de SFML 2 : rien n'est forcé, on peut toujours utiliser le système comme on veut.

Quant à la simplicité, elle ne vaut que pour les mini, mini jeux. Dès qu'on fait quelque-chose de plus élaboré, on butte dedans.

Visiblement non ; et là je ne te parle pas de mon ressenti personnel, mais des années passées d'échange avec les utilisateurs.

La séparation entre Texture et Sprite est quelque-chose de similaire, même de très similaire : Sprite représente la partie plus mathématique, et Texture la partie graphisme.

... et j'ai remis les fonctions les plus utilisées directement dans sf::Texture (principalement les load) pour garder en simplicité, et que sf::Image puisse ne pas être utilisé dans 90% des cas.

[Zinlibs]

Salut Lolman,

Beaucoup de post en peu de temps où la SFML est malmenée mais tient bon, grés et vents !
Je me permet de poster dans ce topic car tu parles de la séparation d’entités entre visuel et géométrie.
Tu as de bons arguments, mais qui ne correspondent pas à la simplicité requise pour la SFML.
Je développe actuellement une librairie qui fait la distinction entre ces deux concepts. Elle se concentre sur tout le côté géométrique des objets, avec les opérations et interactions associés. Une autre lib lie ce côté géométrique à l'aspect affichable (via SFML), et une autre le lie avec la physique.
Tout ça pour dire que si la SFML ne te convient pas directement y'a plusieurs autres libs qui pourraient la compléter (en perdant un peu de simplicité) que tu pourrais utiliser (je pense à Thor aussi).

[L01man]

D'accord, le défaut est le manque de simplicité... Zinlibs, ton projet m'intéresse beaucoup, je vais aller le voir très sérieusement ^^. C'est vrai qu'avec du type erasure, des libs qui se posent en couche, etc., on peut arriver à faire des hacks pour implémenter son design. Mais si ces changements sont bons, il n'y a pas de raison pour que ce soit l'utilisateur qui les implémente.

[L01man]

En enlevant les attributs de Drawable de Shape, on pourrait utiliser cette classe pour les bounding boxes, et à tout moment, pour du debugging par exemple, les attacher à des Drawable afin qu'on puisse visualiser les collisions sans vraiment changer le code.

[Orwel]

Pourquoi le fait d'avoir plus d'attribut que nécessaire te rebut???

Qui peut le plus, peut le moins 

Puis si on fait ce que tu demande, mon système d'affichage de bounding boxes de Box2D s'appuyant sur DebugDraw ne fonctionne plus. Et là je vais devoir bricoler(rien de méchant, mais évitable).

Là on est vraiment dans la problématique :

Le malheur des uns, fait le bonheur des autres

De toute manière avec l'approche de la sortie de SFML2, ce genre de changement n'est pas envisageable(ce propos n'engage que moi).

[L01man]

Pourquoi le fait d'avoir plus d'attribut que nécessaire te rebut???

En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience .

Qui peut le plus, peut le moins

Mais si on peut facilement faire mieux (moins)... Pourquoi faire moins bien (plus et pas de séparation alors qu'un bon design l'impose). Je ne sais pas comment ça marche chez vous, mais chez moi, je ne fais en fait pas "le plus" : j'ai ma propre classe Shape et mes propres Rectangle, Circle, etc., ce qui me fait mal au coeur à chaque fois que j'y pense. J'évite ainsi du "plus" (attributs Drawable là ou j'en voudrais pas : bounding boxes) mais c'est au prix de "hacks" du design.

Puis si on fait ce que tu demande, mon système d'affichage de bounding boxes de Box2D s'appuyant sur DebugDraw ne fonctionne plus. Et là je vais devoir bricoler(rien de méchant, mais évitable).

Ma fois, je ne saurais te répondre ici, ne connaissant que Box2D de nom et pas DebugDraw. Peux-tu préciser vite-fait ?

Le malheur des uns, fait le bonheur des autres

Et au final, le bonheur de tout le monde. Le conservatisme est un frein à l'évolution. Le mieux aurait été de séparer dès le départ, pour éviter aux utilisateurs d'avoir à adapter leurs codes, car ils auraient bien démarré dès le début. Mais

Mieux vaut tard que jamais

.

Je suis sûr que ça éviterait à 99% le comportement que Laurent abhorre : la création d'un design basé sur les Sprite, les Shape, etc. puisque ce serait impossible . A la place, on dériverait Transformable, et on traiterait la partie graphique naturellement à part.

Code: [Sélectionner]

class Player : sf::Transformable {
  public:
    Player() {
        attachTo(new sf::Sprite(textureMachin));
    }
};Drawable.Draw() utilise les attributs du Transformable associé avec attachTo().
Personne ne sera tenté de faire :

Code: [Sélectionner]

class Player : sf::Sprite {
};mis dans une collection hétérogène de sf::Drawable.
Et un jour, quand on veut que le joueur soit fait avec plusieurs sprites

Code: [Sélectionner]

class Player : std::vector<sf::Sprite*> {
};Et si chaque classe est différente : l'une est sf::Sprite, l'autre est std::vector<sf::Sprite*>, l'autre est composé de Sprites et de RectangleShapes, eh ben chacune doit changer son parent et c'est pas propre. Le vrai parent recherché est sf::Transformable. C'est ses attributs qu'on ré-utilise dans toutes ces classes utilisateurs quel que soit le Drawable utilisé. Mais ça, tous ne le savent pas. En forçant la séparation, tout le monde le saura.

[Orwel]

En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience .

Citer

    Ca risque d'être lourd en mémoire, non ?

Bof, non. On n'est pas en train de parler de 1 000 000 d'entités à afficher sur un système embarqué avec 32 Mo de mémoire.

Ma fois, je ne saurais te répondre ici, ne connaissant que Box2D de nom et pas DebugDraw. Peux-tu préciser vite-fait ?

DebugDraw est une classe abstraite qui permet d'implémenter diverse fonction dessin comme un rectangle, une ligne, un cercle...

Le but étant de donner un objet de type Debug Draw à notre monde pour qui se dessine automatiquement dans une logique de debug. Généralement je rend mes objets graphiques transparents et je peux observer en dessous le monde physique.

j'ai ma propre classe Shape et mes propres Rectangle, Circle, etc.

(mes propos) Laurent souhaite que nous évoluons ainsi. Mais je suis incapable de faire de même 
Vivement les tutoriels qui vont bien 

Et au final, le bonheur de tout le monde. Le conservatisme est un frein à l'évolution. Le mieux aurait été de séparer dès le départ, pour éviter aux utilisateurs d'avoir à adapter leurs codes, car ils auraient bien démarré dès le début

Dés le départ??? Lors de la création de SFML1??? L'idée n'était pas encore envisagé. Actuellement tu peux coder à l'ancienne ou à la nouvelle méthode. Peut-être une fois la nouvelle méthode adapté dans plus de projet...

(Mon point de vue) Normalement tu ne fais pas hériter player de Drawable, mais GraphicPlayer qui sera un attribut de Player.

[L01man]

Je vais préciser le :

En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience .

Commençons par la "mauvaise conscience". Peut-être le codeur va commencer par créer un attribut Sprite à son propre objet, mais il se rendra compte qu'il doit dupliquer les attributs de coordonnées, de rotation, etc. puis les passer à son attribut Sprite à chaque fois. Il va se lasser de la recopie, ne pas apprécier qu'on puisse accéder à ces attributs autrement que par Sprite.get/setAttribut, va aussi penser à l'aspect "consommation inutile", et va finalement commettre une grosse erreur (c'est exactement mon parcours que je vous donne) : il va faire hériter sa classe Player de Sprite, et va ensuite continuer dans cette lancée en créant des listes hétérogènes de Drawable* (malheur !).
Ensuite, une consommation mémoire inutile, qui doit être faite pour éviter un mauvais design, est tout simplement, comme le nom l'indique, inutile. Elle n'a pas lieu d'être. Elle est facilement contournable. Mieux encore, elle force à choisir le bon design, à faire ce que toi et Laurent pensez !
Je me souviens d'une version plutôt récente d'OpenGL qui "cassait" aussi ses fonctions et nous laissait ainsi plus de libertés, d'augmentations de performances, etc., car ces fonctions réunissaient sûrement plusieurs opérations ensemble alors que certaines n'étaient utiles que dans certains cas.
Sur ce coup, je suis sûr d'avoir raison. A la limite, au diable mes qui consistent à "remonter" des méthodes, si c'est pour considérer celle-ci. D'un point vu théorique reconnu par tous et au niveau de mon expérience personnelle, qui selon Laurent est plutôt répandue chez les débutants puisqu'il veut absolument éviter les comportements qu'induisent la réunion des attributs de Transformable et de Drawable dans Sprite, etc., j'en suis convaincu.
Certes, pour faire un "Hello World" + Sprite, il faudra créer un objet supplémentaire et appeler une fonction en plus. Mais sur tous les autres projets, utilisant des classes Player, etc. contenant un attribut Drawable permettant de la flexibilité, évitant de transmettre tous les attributs à son Drawable puisqu'il utilisera directement celles de la classe le contenant, etc., des lignes de codes seront même gagnées.

En tout cas, merci, Orwel (Georges ?), de faire vivre le sujet .

[Laurent]

Honnêtement j'ai oublié le propos de cette discussion (ça fait longtemps, et puis t'avais posté toutes tes idées en même temps à l'époque), donc si tu pouvais faire un petit résumé de ce que tu proposes au final, j'avoue que ça ne me déplairait pas

[L01man]

Laurent pointe le bout de son nez ! Vite, entraînons-le dans une discussion de laquelle il ne pourra plus sortir et sera donc contraint d'accepter le changement.

En pratique le changement est assez simple et ne s'appuie sur aucune de mes autres idées. Il est principalement exprimé dans le premier post et consiste en ce qui suit :

• Enlever l'héritage de sf::Transformable dans toutes les filles de Drawable qui en héritent, comme Sprite, Shape et Text, mais pas VertexArray
• A la place, créer une méthode attachToTransformable(sf::Transformable&) afin que les attributs de ce sf::Transformable soient appelés dans le Draw()

Je pense que c'est tout. Après, tu auras sûrement d'autres idées plus astucieuses quant à l'interaction entre le Drawable et le Transformable mais ça devrait ressembler à ça.
Ce qui fait couler le plus d'encre, en revanche, c'est le débat sur l'application de ce changement . Je pense avoir le mieux répondu dans mon message précédent, et j'attends avec impatience de nouveaux arguments !