Quel est le raisonnement derrière sf :: Sprites qui possède sa position et sa rotation? Ça embrouille mon Composant/Entité/Système

Question

Je réalise une implémentation basique d'Asteroids en utilisant SFML en C++, pour m'exercer à utiliser une structure de système d'entité-composant. Conceptuellement, il est logique que des objets tels que le lecteur, les astéroïdes flottants, etc., partagent des «composants» communs, tels qu'un composant graphique, un composant de vélocité et un composant d'orientation/position. Cela permet de garder les préoccupations séparées et offre toute une gamme d'avantages. Cependant, en SFML, les Sprites sont rendus à une position fixe dont ils sont les seuls à connaître! Cela signifie immédiatement que mon composant graphique et mon composant position/orientation doivent être combinés ou doivent se connaître, ce qui va à l'encontre de l'idée de l'approche système-entité-système. En SDL, d'autre part, vous pouvez facilement rendre la texture à un rectangle séparé construit à partir de n'importe où.

Ma question est la suivante: il doit y avoir un raisonnement concret derrière la raison pour laquelle Sprites dans SFML s'accrochent à leurs propres informations de position - quel est ce raisonnement? Peut-être que si je comprenais mieux, je pourrais former une bonne solution.

Answer 1

La classe sf::Sprite est conçue pour être un moyen rapide de dessiner des sprites d'une manière facile à utiliser.

Ils ne sont pas forcément les meilleurs pour les cas d'utilisation plus avancés, principalement parce qu'ils sont plutôt lents (puisqu'ils sont non récupérés).

sf::Sprite est principalement destiné à quelqu'un qui veut obtenir un sprite à l'écran facilement sans trop se soucier des détails de l'implémentation (comme d'autres classes dérivées sf::Drawable). Ce que vous devez faire à la place consiste à implémenter votre propre composant visuel ou dessinable qui stocke la couleur, la texture et les coordonnées UV. Mabye quelque chose comme ceci:

struct DrawableComponent { 
    sf::Color color; 
    sf::Texture *texture; 
    sf::IntRect uv; 
} 

Bien sûr, il pourrait y avoir d'autres approches avec plus d'options ou divers composants (par exemple des graphiques vectoriels par rapport aux quadriceps texture). Ensuite, lors du dessin, parcourez toutes vos entités avec la même texture que celle qui peut être mise en lot et placez leurs sommets dans std::vector ou sf::VertexArray et utilisez-les pour un rendu rapide par lots.

Answer 2

SFML suit une conception orientée objet. Un sf::Sprite modélise une chose visible, qui a une texture et une transformation. Ainsi, comme d'habitude dans OOD, il détient ces deux attributs. Ceci est directement en contradiction avec la conception ECS, qui s'efforce de renverser la situation en empêchant les entités de s'accrocher à quoi que ce soit. Vous ne serez pas vraiment capable d'intégrer la classe sf::Sprite dans votre conception - elle est fondamentalement incompatible. Le mieux que vous pouvez faire est de créer un sf::Sprite temporaire lorsque vous avez rassemblé toutes les données dont vous avez besoin. Comme pour SDL ... Eh bien, contrairement à SFML, c'est juste une API graphique de bas niveau (entre autres). Il n'essaie pas de modéliser quoi que ce soit: prenez une texture, appliquez-la sur le framebuffer, c'est tout. Deux outils très différents pour des objectifs très différents.