Salut tout le monde,

Je me demande comment vient gérer SFML et Box2D ensemble.

J'ai déjà codé avec ces 2 librairies mais toujours de façon un peu barbare : mes entités avaient un body et un sprite (qui était dessiné en fonction du body).

Cependant, j'aimerai faire les choses plus proprement cette fois.
J'avais pensé à donné à chaque objet un objet "Collision" et un "Renderable" (les noms sont pourris, je sais, c'est juste pour l'exemple).
Faire comme ça me permettrait d'abstraire un peu mes classes et de pouvoir switcher de libraire pour les collision ou le rendu graphique si j'en ai besoin.
Le truc, c'est que je n'arrive pas à avoir une structure claire de ce que va donner l'architecture du jeu.

Une classe Renderer avec un tableau de Renderable (et pareil pour les collisions) ?
Des Renderable qui ont un pointeur vers le Renderer ?
Un Renderer qui a un tableau de Vertex et des Renderer avec un pointeur vers ce Vertex et qui s'occupent de synchroniser le tout ?

Si quelqu'un a déjà eu affaire avec ce genre de problème ou connait des design pattern spécifique (que ça soit la dessus ou même en général sur les 2 libraires), je suis très intéressé de les connaitre.

Merci d'avance.

Salutations !

Un architecture classique pour ce genre de framework est un "ECS", pour Entity-Component-System.

Une Entity est un bidule abstrait qui contient des Components.
Un Component est un machin qui contient un ensemble de donnees coherent pour representer qqch d'utile, et eventuellement de la logique propre
Un System est un truc qui traite les Entity et effectue des operations dessus en utilisant les donnees des Components

Il te suffit d'implementer autant de components que necessaire pour representer tes morceaux d'objets et/ou elements de comportement ; et avoir un system par unite de traitement

Par ex. un objet avec une hitbox et capable de s'afficher a l'ecran est une entity avec un composant de physique et un composant d'affichage (plus d'autres composants eventuels : positionnement, logique de deplacement, audio, etc.). Et tu as deux systems ; l'un en charge de gerer les collisions (= deleguer a box2d), l'autre en charge d'afficher les entites qui en sont capables

C'est ce à quoi je pensais. Plus j'y pense et plus l'architecture générale se dessine.

Pour l'affichage, je me suis dit que je ferai:
- une classe CoordinateUnit pour unifier les coordonnées du body pour les collisions
- une RenderingUnit, qui prendrait en charge l'affichage (soit avec une methode render(Renderer* renderer) ou alors render() (avec un pointeur vers le Renderer))

et pour les collisions :
- une CollisionUnit pour le corps physique de l'objet et ses comportements
- un CollisionSystem qui contient des pointeurs vers les CollisionUnit des entités et gère les collisions.

Je suis dans le bon ou pas ?

On tombe vite dans les details d'implementation - mais evite des pointeurs entre entites et systems, car cela va nuire au couplage. Une entite doit avoir toutes les infos utiles a sa bonne gestion, mais ne devrait jamais avoir a manipuler directement les renderer ou les algos de collisions.

Certains adeptes d'ECS preconisent meme de n'avoir aucune logique dans les composants, juste des donnees, et mettre tout les traitements dans des systemes. Perso je trouve cela un peu extreme, mais ca donne l'idee.

salut, j'ai implemente un ECS en c++ avec la sfml donc si tu veux je peux t'aider sur ce point.
deja quelque chose que j'ai fais et que je te conseille, c'est de deriver ta classe entity de la classe sf::Transformable parce que toutes les entity ont besoin d'une position (a part cas extreme)

apres il y a pleins de possibilites concernant l'integration du ECS, chacun le fait un peu a sa sauce