Une méthode get/setRect() pour tous les Drawable

[L01man]

J'ai trouvé l'usage géométriquement pur qu'on peut faire d'un getRect : l'inscription. En fait, un setRect n'a pas de sens, de même qu'un attribut Rect donné à tous les Transformable, tu as raison.
Mais par contre, savoir si un Transformable est inscrit dans un rectangle, dans un cercle, etc., me paraît plutôt géométrique.
Pour éviter de créer une fonction virtuelle pure qui empêcherait une instanciation d'un sf::Transformable, on peut créer une méthode statique surchargée dans sf::Transformable ou sf::Transform, qui donnerait la figure géométrique dans lequel un Transformable est inscrit.
Un pseudo-code illustrant le tout :

Code: [Sélectionner]

sf.Transform.getRectInscription drawable = case type drawable
    sf.Sprite -> Rect(drawable.getPosition(), drawable.getSize())
    sf.CircleShape -> Rect(drawable.radius * 2, drawable.radius * 2)
    sf.Shape -> #un calcul plus compliqué
    #etc.


[Laurent]

On a déjà cette fonction dans les classes concernées, et on veut éviter de le factoriser dans une classe de base. Donc ? Ca nous emmène où tout ça ?

[L01man]

Pas de factorisation, même en C++ ? Alors ça n'emmène effectivement à rien.
(Mais je reviendrai.)

[Laurent]

Mais je reviendrai

Je n'en doute pas

[L01man]

D'ailleurs, me revoilà.
Je viens juste partager une réflexion qui ne concerne en aucun cas une proposition pour la SFML . Une classe ressemblant à, tiens, Transformable, représentant quelque-chose de géométrique, devrait avoir en premier lieu un tableau de points, de sommets, ainsi qu'une relation qui relie les points entre eux, des courbes. En fait, la librairie parfaite implémente du dessin vectoriel au sommet. Quand aux textures, elles sont soit elles-mêmes en vectoriel, soit des images qui s'affichent dans un polygone vectoriel. Les calculs de collision sont applicables pour tout, avec une extrême puissance ; les classes comme Shape n'ont plus de raison d'être car elles se retrouvent dans Transformable ; tout peut posséder une texture, une couleur, etc. Quant à Text, c'est soit un groupe de polygones vectoriels, chacun formant une lettre, soit un rectangle sans fond et au bord transparent dans lequel est dessiné le texte avec la fonte donnée. Ça peut marcher : ça s'imagine très bien et ça existe déjà. Je suis par contre effrayé des performances au sein d'un jeu, peut-être à tord.

[Laurent]

Oui, le vectoriel est déjà exploité par certaines bibliothèques, ce que tu décris pourrait très bien être codé sans problème. Mais ce n'est pas la voie choisie par SFML.

Côté performances, il y a un standard (OpenVG) qui est censé booster l'intégration du vectoriel directement dans les puces graphiques, mais j'ai l'impression que ça ne prend pas cette direction, et que le support OpenVG hardware reste marginal (mais je peux me tromper, je n'en sais pas plus sur le sujet).

[L01man]

C'est super, ça. D'OpenVG je suis tombé sur cairo dont j'avais déjà entendu parlé, et je suis arrivé sur Papyrus, son port C++. Il y a quelques points communs avec la SFML !