Image/Texture, Sprite et Drawable : remonter des méthodes

[L01man]

Ce serait intéressant de pouvoir appliquer des transformations sur Image ou Texture (je n'ai pas compris la différence clairement) : scale, setColor, flipHor/Vert, etc. Ainsi, les méthodes seraient utilisables sur les Images/Textures, ce qui les modifierait en mémoire, et sur les Sprite, qui agiraient un peu comme des filtres inoffensifs sur leur texture. Dans pyglet, les groupes sont des collections d'objets affichables qui définissent, pour simplifier, des "filtres" à appliquer sur leur ensemble, même s'il s'agit simplement de l'ordre d'affichage. Et devinez quoi, les Sprites sont aussi des groupes à une image, et ils agissent donc aussi comme des "filtres".
Mais, quelle classe, entre Image/Texture et Sprite doit implémenter ces fonctions ? Je pense que, tel que le design est défini, ça doit être Sprite. Il peut toujours modifier sa texture source à partir de ses transformations, s'il le veut.

Une partie de ces méthodes est déjà implémentée dans les classes supérieures : scale et rotate dans Transformable, etc. donc Sprite en hérite. Mais je pense que toutes ces fonctions de transformation pourraient être implémentées dans les classes supérieures. Pour Drawable par exemple, des méthodes comme setColor et FlipHor/Vert, ou même setSmooth permettraient de faire des effets intéressants sur du texte ou des figures. En effet, Text implémente sa propre version de setColor, par exemple, et Sprite aussi, mais Shape n'en a pas de globale. C'est l'occasion de tout remonter vers Drawable ! (D'autre part, cet setColor pourrait s'appeler setTint ou setTintColor, non ?). On peut penser qu'il définit la couleur de fond d'un sprite, à moitié transparent par exemple, ou je ne sais pas quoi. En donnant tant de puissance à Drawable, on peut, si View hérite de Drawable comme je le suggère dans un autre sujet, faire une espèce de gallerie des glaces avec des flip et appliquer un filtre de couleur sur  tous les objets, pour par exemple assombrir quand c'est la nuit. Mais même si ma proposition d'héritage de Drawable par View est rejetée, on pourra quand-même retourner du Text, par exemple, pour crypter comme le faisait Léonard de Vinci.

[Laurent]

je n'ai pas compris la différence clairement

sf::Image == std::vector<sf::Color>, c'est en mémoire système et ça peut se bidouiller n'importe comment
sf::Texture == texture OpenGL, c'est en mémoire vidéo et c'est optimisé pour l'affichage, pas pour bidouiller dedans

Sinon... ce que tu proposes va à contre-sens de la façon dont les choses sont censées se faire.

D'une part, implémenter des transformations "off-line" nécessiterait de les implémenter moi-même et de les faire exécuter sur le CPU, plutôt que de laisser OpenGL faire tout le boulot automatiquement.

Ensuite ça conduirait à des comportements inefficaces : l'idée c'est justement d'avoir d'un côté des ressources fixes en mémoire (texture, police, ...) qu'on n'a pas à bidouiller, et d'autre part des objets légers (sprites, textes, ...) capables d'utiliser/afficher ces ressources en modulant certains paramètres à la volée (position, couleur, ...).
Si on commence à fournir des transformations off-line dans tous les sens, les gens vont faire n'importe quoi, pour au final pas grand chose.

Ensuite, tout remonter dans sf::Drawable : non, dans SFML 2 j'ai justement tout descendu. SFML était trop "framework", elle imposait des classes de bases et des fonctions virtuelles, alors que moi je veux que ce soit un outil bas niveau, qui ne fournisse que des classes utilitaires ; en ne forceant rien au niveau conception pour l'utilisateur. Et ça c'est l'expérience de SFML 1 qui me l'a appris.

[L01man]

OK, j'ai compris pour Image et Texture.

Par contre, je ne comprends pas pour la partie sur le "remontage". En fait, j'ai l'impression que mettre setColor uniquement dans Sprite et Text et les flip et setSmooth uniquement dans Sprite, c'est limiter leur utilisation. Pourquoi tous les Drawable ne pourraient pas être retournés, teintés, etc. ? Théoriquement, ça me semble juste et techniquement, j'imagine que c'est exécuté par OpenGL et qu'avec un peu de chance ça peut se faire pour tous les Drawable de la même manière. Je pars du principe que, lorsque je vois deux fois la même méthode dans deux classes qui héritent du même parent, et que cette méthode n'est pas définie chez le parent, alors elle devrait l'être. Ensuite, setSmooth, flip, etc. sont des transformations qui ne sont pas spécifiques à Sprite, de même que Draw n'est pas spécifique à Sprite. Disons que chaque enfant de Drawable permet de faire un dessin spécial, mais que tous doivent pouvoir être transformés de la même manière. Par exemple, ils peuvent tous utiliser setScale(), setRotation(), alors pourquoi pas flip() ?
Je ne comprends pas le problème d'ajouter des fonctions virtuelles pures. Drawable en possède déjà une, donc ça ne change rien pour elle. Normalement, l'utilisateur n'a pas besoin d'hériter Drawable, donc ça ne gène toujours pas. En plus, j'imagine, mais je me trompe peut-être lourdement, que la nouvelle classe Drawable pourrait ressembler à ça (je n'écris que les ajouts et les changements) :

Code: [Sélectionner]

class Drawable {
  public:
    Drawable(), my_isSmooth(false), /* etc. */ {
    }

    void setColor(sf::Color NewColor) {
      my_Color = NewColor
    }
    //etc. que des mutateurs et des accesseurs de base en fait

    //une nouvelle fonction Draw pour utiliser tous les paramètres

    void Draw() {
      if(my_isSmooth) {
        //fonction openGL pour activer le smooth
      }
      //fonction openGL pour passer un filtre de la couleur sur ce qui va etre dessine
      MainDraw();
    }

     //cest la fonction qui est redefinie dans les classes filles. comme ca pas besoin pour elles de toucher aux my_isColor, etc.
     void MainDraw() = 0;

  private:
    sf::Color my_Color;
    bool my_isSmooth;
    bool my_isFlipHorizontally, my_isFlipVertically;
}En quoi ajouter plus de fonctions, à usage facultatif forcerait l'utilisateur à changer de concept ? En effet, remonter ces classes ne demanderaient même aucun changement de code du côté utilisateur, mais il pourrait faire plus de choses.

[Laurent]

flip() n'existe plus dans sprite, et setSmooth est dans sf::Texture, pas dans sf::Sprite. Les transformations sont communes donc factorisées dans sf::Transformable, et pour le reste c'est spécifique à chaque classe, je ne veux rien imposer. Par exemple sf::Shape ne pourrait pas avoir setColor : il gère deux couleurs bien distinctes (fillColor et outlineColor).

Je ne comprends pas le problème d'ajouter des fonctions virtuelles pures. Drawable en possède déjà une, donc ça ne change rien pour elle. Normalement, l'utilisateur n'a pas besoin d'hériter Drawable, donc ça ne gène toujours pas.

Et bien détrompe toi : plus je mettais de choses dans sf::Drawable, plus les gens se sentaient obligé d'en dériver. Je veux éradiquer ces comportements. sf::Drawable ne devrait même pas exister, à vrai dire.

Ensuite, les choses qui ne sont pas communes sont implémentées différemment dans chaque classe : il n'y a pas de fonction OpenGL magique qui fonctionne indépendamment de ce que l'entité est. Par exemple, regarde l'implémentation de setColor.

J'aimerais ajouter un commentaire, commun à toutes tes requêtes : l'API de SFML 2 est gelée, rien ne sera modifié avant sa sortie, et après sa sortie il ne pourra y avoir que des ajouts. Tout ce dont on parle là ne serait faisable que dans SFML 3, donc... tu peux largement prendre le temps de te familiariser avec SFML 2 avant qu'on ait ces discussions (plusieurs mois, voire années). C'est même un peu contre-productif d'en discuter maintenant.

[L01man]

D'accord ^^.

plus les gens se sentaient obligé d'en dériver. Je veux éradiquer ces comportements. sf::Drawable ne devrait même pas exister, à vrai dire.

Au détriment des possibilités offertes ? Ca complexifie le problème global :s ! Quelles classes font généralement les utilisateurs qui dérivent Drawable ? Et à vrai dur, ajouter des méthodes virtuelles pures à Drawable empêcherait d'une certaine façon les utilisateurs à implémenter un enfant qui fonctionne .
Remonter ces méthodes fait un beau parallèle avec sf::Transformable : chacun possède des méthodes de transformation, de filtre.

sf::Drawable ne devrait même pas exister

Vraiment ? C'est l'une des classes qui rend SFML très pratique !

Par exemple sf::Shape ne pourrait pas avoir setColor : il gère deux couleurs bien distinctes (fillColor et outlineColor).

De la même façon, Texture possède plein de couleurs différentes : une par pixel, ce qui ne l'empêche pas d'avoir une méthode setColor() qui teint toutes ces couleurs.

il n'y a pas de fonction OpenGL magique qui fonctionne indépendamment de ce que l'entité est. Par exemple, regarde l'implémentation de setColor.

D'accord, il faut des fonctions virtuelles pures dans Drawable à ce moment-là. Mais peut-être pas... Comment les transformations de Transformable fonctionnent ? Les méthodes définies dans cette classe éditent simplement des attributs, je suppose. La vraie utilisation se fait dans le Draw. De la même façon, on peut avoir de bêtes accesseurs et mutateurs dans Drawable et leur utilisation se ferait dans les héritières.

C'est même un peu contre-productif d'en discuter maintenant.

Je vais arrêter, alors ^^.

[Laurent]

Justement je ne veux pas obliger les gens à implémenter des drawables corrects, je ne veux même pas qu'ils implémentent des drawables, je veux qu'ils choisissent eux-même leur design, leurs interfaces, etc. ! SFML n'est qu'un outil, pas un framework. Je veux vraiment me débarasser de ça.

Drawable, Sprite, Shape... ce ne sont que des classes utilitaires, pour que les gens aient des trucs tout prêts directement. C'est loin d'être le coeur de SFML, à vrai dire ça ne devrait même pas exister non plus. Alors ça devrait encore moins être le coeur/la base de tout le code utilisateur.

De la même façon, Texture possède plein de couleurs différentes : une par pixel, ce qui ne l'empêche pas d'avoir une méthode setColor() qui teint toutes ces couleurs.

sf::Texture n'a pas de setColor. Encore une fois, tu mélanges la ressource et la façon de l'afficher.

[L01man]

Oui, pardon, j'ai mélangé avec Sprite. Maintenant que flip n'est plus dans Sprite, il sera impossible d'avoir deux Sprites se partageant la même texture de deux côtés différents ?

Ah, je n'avais pas compris cet enjeu de la SFML. Maintenant, je ne sais plus trop quoi dire, mais en tant qu'utilisateur, je trouve le design de Sprite et du reste très bien pensé, et je regrette - juste un peu, la SFML est quand-même géniale - que ce design ne soit pas mené au bout du bout et soit bloqué à mi-chemin. Sprite et les autres pourraient rester des classes utilitaires, même si certaines de leurs opérations étaient remontées dans Drawable, afin de permettre à ceux qui préfèrent une SFML nickel de l'utiliser plus au centre, et pour ceux qui ne le veulent pas, il ne sont pas obligés de s'en servir comme d'un framework. Encore une fois, remonter des méthodes ne changera pas le design d'un projet écrit en SFML 2.0, il permettra par contre d'utiliser de nouveaux design, et d'être plus ouvert.
Pour être sûr que l'utilisateur créera son propre design, on peut, en tenant ou pas en compte de ce que j'ai déjà proposé, taper un plus grand coup, et séparer les Drawable des Transformable. Sprite, Text, etc. seront juste des Drawable, et l'utilisateur devra créer sa classe Player, Spaceship, etc. héritant de Transformable et ayant un attribut Sprite ou Drawable, etc. De cette façon, on sépare totalement les graphismes du reste, et c'est l'utilisateur qui les arrange comme bon lui semble.

[Laurent]

Maintenant que flip n'est plus dans Sprite, il sera impossible d'avoir deux Sprites se partageant la même texture de deux côtés différents ?

Il y a des équivalents : scale négatif, ou texture rect à width/height négatif.

certaines de leurs opérations étaient remontées dans Drawable

On parle de quelles opérations au juste ? Il n'y a rien de commun, pas même getLocal/GlobalBounds : ils supposent une transformation, or tous les drawables ne sont pas des transformables (cf. sf::VertexArray).

[L01man]

Tiens, j'aime bien cette idée du scale négatif !

Je parle des transformations du type setColor, comment les appeler ?
Pour changer, je vais faire des "diagrammes" :

Code: [Sélectionner]

Drawable {
  Draw = 0 //methode virtuelle pure : bien. on peut faire des Draw sur des collections hétérogènes, ce qui est sûrement très courrant
}
Sprite < Drawable, Transformable {
  Draw //ok
  setColor //tiens, un truc specifique de Sprite
  getGlobalBounds //une autre méthode spécifique de Sprite
}
Text < Drawable, Transformable {
  Draw //ok
  setColor //mais c'était pas déjà dans Sprite? code répété
  getGlobalBounds //eh mais, c'était aussi dans Sprite ! pourquoi c'est pas fait comme Draw
}
RectangleShape < Drawable, Transformable {
  Draw //ok
  getGlobalBounds //encore ? ça aurait été bien pratique dans des collections hétérogènes
}
VertexArray < Drawable {
  Draw //ok
}Et a la place on fait

Code: [Sélectionner]

Drawable {
  Draw = 0
  setColor //cool
  getGlobalBounds //cool
}
Sprite < Drawable, Transformable {
  Draw //ok
}
Text < Drawable, Transformable {
  Draw //ok
}
RectangleShape < Drawable, Transformable {
  Draw //ok
}
VertexArray < Drawable {
  Draw //ok
}Comme ça, tout le monde profite de ces fonctions. Ca évite la répétition de code. Puisqu'il y a une classe mère, autant utiliser tout ce que permet la POO, non ? Actuellement, c'est fait pour Draw, mais pas pour les autres.
Ca permet de faire des trucs cool comme ça :

Code: [Sélectionner]

std::vector<sf::Drawable*> All;
All.push_back(Sprite(Player))
All.push_back(Map.load("truc.map")) //Map retourne un Group
All.push_back(sf::Text('Level 5'))
All.push_back(sf::WidgetCounter()) //WidgetCounter hérite de RectangleBox

/***
plus tard, dans le jeu, un appel a updateAfterPreferencesChange()
***/
switch(Preferences.themes) {
  case 'ambiance night'
    foreach elem in All {
      elem.setColor(sf::Color::Grey); //ambiance nuit => il fait sombre => on teint tout en gris, meme les widgets, cest stylé
    }
C'est écrit en pseudo-code, mais j'espère que ça montre à quel point ce serait utile.

[Laurent]

Comme je l'ai dit, getGlobalBounds n'a pas de sens dans VertexArray, et setColor n'en a pas dans Shape (et ses dérivées) et VertexArray.

Et je ne veux pas que les gens utilisent des collections hétérogènes de Drawable. Je veux qu'ils utilisent des collections hétérogènes de leurs propres classes, avec des sprites, textes, etc. comme attributs de certaines.

[L01man]

et setColor n'en a pas dans Shape

Avec OpenGL, on ne peut pas le faire ? setColor a selon moi du sens sur tous les graphismes. S'il en a dans Sprite et même dans Text, pourquoi pas dans Shape ? D'ailleurs, Shape a déjà deux méthodes de couleur, et une plus globale paraît logique.

Je veux qu'ils utilisent des collections hétérogènes de leurs propres classes, avec des sprites, textes, etc. comme attributs de certaines.

Dans mon code, j'ai créé une classe AnimationSprite qui hérite de Sprite et une classe MovingSprite qui en hérite. J'ai cherché à séparer "Moving" de "Sprite", mais le problème, c'est que la position, la rotation et toutes les autres opérations intéressantes sont dans Sprite, Text, etc. ! Je pense que casser ces Drawable forcerait à coup sûr les utilisateurs à faire leur propre design, et c'est quand-même plus propre d'un point de vue théorique. En plus, ça évite l'héritage multiple, et ça facilite le portage vers d'autres langages (je ne sais pas comment c'est fait dans les autres, actuellement). Et là, ce sera comme tu dis, Sprite et les autres ne seront que des attributs, des classes sans incidence dans la partie principal du code.

Comme je l'ai dit, getGlobalBounds n'a pas de sens dans VertexArray

Si j'ai bien compris, VertexArray, c'est une Shape de plus bas niveau. C'est toujours pratique de connaître la place occupée par un objet. C'est vrai que cette classe est un peu problématique : elle possède en même temps des informations de Transformable (des coordonnées), et de Drawable (la couleur). C'est donc un peu des deux, mais elle n'hérite quand même pas de Transformable. D'ailleurs, Shape a le même problème : elle contient des points et des couleurs en même temps, mais elle fait mieux parce-qu'elle sépare quand-même les positions des couleurs au niveau des attributs. Donc, il se pourrait que ces classes géométriques, en particulier VertexArray, s'intègrent un peu mal dans le design et bloquent donc l'évolution. La solution serait là encore de séparer l'aspect Transformable et l'aspect Drawable.

[Laurent]

Avec OpenGL, on ne peut pas le faire ? setColor a selon moi du sens sur tous les graphismes. S'il en a dans Sprite et même dans Text, pourquoi pas dans Shape ? D'ailleurs, Shape a déjà deux méthodes de couleur, et une plus globale paraît logique.

Deux raisons :
- techniquement c'est chiant tant que SFML ne tourne pas en shader-only
- dans SFML 1 la plupart des gens n'y comprenaient rien dès lors que plusieurs couleurs se cumulaient

Dans mon code, j'ai créé une classe AnimationSprite qui hérite de Sprite et une classe MovingSprite qui en hérite. J'ai cherché à séparer "Moving" de "Sprite", mais le problème, c'est que la position, la rotation et toutes les autres opérations intéressantes sont dans Sprite, Text, etc. !

Pas que. Elles sont aussi (et surtout) dans sf::Transformable.

Je pense que casser ces Drawable forcerait à coup sûr les utilisateurs à faire leur propre design, et c'est quand-même plus propre d'un point de vue théorique.

Comment ça ?

ça facilite le portage vers d'autres langages (je ne sais pas comment c'est fait dans les autres, actuellement)

Non : tout ce qui est classe de base est une vraie plaie à gérer dans les bindings, d'autant plus quand il y a du polymorphisme. Quand tout est à plat, c'est au contaire très simple.

Si j'ai bien compris, VertexArray, c'est une Shape de plus bas niveau. C'est toujours pratique de connaître la place occupée par un objet.

Il y a une fonction pour ça, mais pas en terme de "local/global" puisque VertexArray n'a pas de transformation.

J'aimerais vraiment qu'on stoppe ces discussions, non pas parce qu'elles m'embêtent (bien au contraire), mais parce que (je résume) :
- ça me prend énormément de temps de te répondre, et en ce moment je pense que tout le monde préfèrerait que je finisse les tutoriels pour sortir SFML 2
- tu n'as pas assez de recul ni sur SFML 1, ni sur SFML 2 pour comprendre les choix qui ont été fait, et du coup je dois passer beaucoup de temps à t'expliquer le pourquoi du comment
- tout ça ne concerne que SFML 3, donc on en est très très très loin, tu peux largement prendre le temps de creuser toi-même ces concepts avant de les proposer

Mais je te remercie encore une fois, ce sont ces discussions qui font avancer SFML, on en a toujours besoin

[Ceylo]

Justement je ne veux pas obliger les gens à implémenter des drawables corrects, je ne veux même pas qu'ils implémentent des drawables, je veux qu'ils choisissent eux-même leur design, leurs interfaces, etc. ! SFML n'est qu'un outil, pas un framework. Je veux vraiment me débarasser de ça.

Je me permets une intrusion. Je n'ai pas compris pourquoi tu veux que les gens n'héritent pas de drawable. Même sachant qu'on peut choisir notre propre design, le fait d'hériter de Drawable permet de garder une cohérence avec les autres drawables tels que Sprite et Shape. Ça fait ça de moins à apprendre pour l'utilisateur qui va utiliser notre objet de la même façon qu'un shape, et donc moins se prendre la tête à comprendre un nouveau fonctionnement. Alors en quoi est-ce une mauvaise chose ?

[Laurent]

C'est une mauvaise chose car ça oriente très fortement les gens vers une direction qui n'est pas forcément la bonne. En mettant des classes très haut-niveau, "finales", dans SFML, j'incite les gens à faire pareil pour leurs propres classes, et donc utiliser les mêmes classes de base. Mais les classes des gens ne sont pas celles de SFML, et on voit très vite arriver plein de gens sur le forum qui se plaignent de limitations ou autres.

SFML doit être une toolbox, pas un framework. Je n'ai pas vraiment envie d'argumenter des heures sur ce point, c'est simplement la conclusion des 5 dernières années d'utilisation de SFML 1.

Les libs C telles Allegro ou SDL sont de vraies toolbox, pas moyen pour elles d'avoir des classes de base ou autre. Et qui s'en plaint ? Tout le monde fait son design par dessus, et tout le monde est content.

[Ceylo]

Moé. Je suis pas spécialement convaincu, surtout parce que je ne vois pas en quoi sf::Drawable et sf::Transformable sont limitants. Je verrai probablement au fur et à mesure du temps, mais pour l'instant ça me convient très bien.

Et que Allegro ou SDL soient des toolbox et même si personne ne s'en plaint, je vois au moins une contrainte majeure : pas de cohérence et pas de "voie simple correcte par défaut". Ça facilite pas les développements et utilisations, et c'est peut-être justement ce qui fait que beaucoup de gens se tournent vers SFML.

C'est bien de vouloir tout permettre, mais c'est aussi bien de guider et garder les choses simples. Concevoir un design c'est pas instantané.