Hello tout le monde
Alors voilà, je suis en train de faire un petit moteur 2d en SFML (non isométrique), et au fur et à mesure que les choses avancent je commence un petit peu à me demander si ma manière de coder est la bonne. Pour l'instant je "travaille" sur des environnements relativement peu gourmands en ressources : deux ou trois personnages animés, aucune gestion de collisions, pas de pathfinding, une map en 500x500, bref.. Je peux être content de mon framerate mais j'ai peur qu'à force d'ajouter des paramètres et des calculs à mon moteur, ça ne commence à ramer sévère ! J'ai donc deux questions, l'une relative à la manière d'afficher mes sprites, l'autre portera sur la gestion de la profondeur ( même si en fait, ces deux questions sont plutôt liées )
S'agissant de la manière dont j'affiche mes sprites ( animés ou non ), j'ai une classe "GameBoard" qui possède une méthode draw, et qui prend en argument une référence vers la fenêtre active, donc sf::RenderWindow &target, et une référence vers l'horloge du programme, sf::Clock &clock. Ce plateau de jeu (GameBoard) possède dans sa section private une vector de sprite. Ces sprites ne sont pas ceux de la SFML mais une version personnalisée, ils sont dessinés sur &target au moyen d'une boucle for qui "passe " tout le vector, et sont mis à jour grâce à &clock, pour ceux qui sont animés.
Je me demandais si la boucle for est un choix judicieux ? Il est évident que la méthode draw de ma classe GameBoard a tout intérêt à être rapide puisqu'elle est appelée à chaque fin de boucle dans mon main, alors déjà que chacun de mes sprites animés a besoin d'être mis à jour, je suis pas sûr qu'une boucle avec incrémentation soit la manière de faire la plus optimisée. En même temps, je ne vois que cette solution, mais peut être que je me trompe ?
Quant à la manière dont je compte gérer la profondeur, je n'ai encore rien testé, ce sont juste des idées, et je voudrais savoir ce que vous en pensez : je compte utiliser un vector de tous les sprites, animés ou non, que j'aurais à afficher (et là je vous renvoie à la question précédente, et hop… boucle infinie, héhé ), vector qui contiendra, dans l'ordre, les sprites à afficher. Pour tout ce qui s'agira du décor (par exemple, pour les arbres ou les maisons), on est d'accord que ça ne bougera jamais, donc chaque map aura un fichier de données associé, dans lequel il sera écrit quels décors doivent être affichés en premier, en fait ils y seront tous écrits, dans le bon ordre. Pas de problème de ce côté là.
Le vrai problème vient des personnages qui eux, sont mobiles, et qui par conséquent changeront de place dans les priorités d'affichage. Il suffira d'un std::swap pour les déplacer dans le vector, mais je me demande encore comment déterminer cette priorité d'affichage. J'ai donc pensé à associer une sorte de " ligne de masquer/afficher " à chaque sprite.
Cherchez donc dans les fichiers joints, et modérez vous dans vos compliments sur mes talents de graphiste, s'il vous plait. J'en ai marre qu'on me jette des fleurs. On voit, en haut, trois sprites : le bleu, pour celui du personnage vert, le rouge, pour la maison, le orange, pour le personnage violet. Dans la vrai vie, si l'on peut dire, le personnage vert est derrière la maison, qui est elle même derrière le personnage violet. Dans mon modèle, la ligne de masquer/afficher du sprite bleu se trouve au dessus de celle de la maison et il est donc affiché en premier. Idem ensuite pour déterminer les priorités d'affichage entre sprite orange et rouge. Cette méthode me permet, dans le dessin du bas, de déterminer des priorités d'affichage dans des cas où elles ne sont forcément évidentes, puisque les sprites sont dans des positions identiques. Pourtant, il va de soi que le personnage est affiché derrière l'arbre, à gauche, tandis qu'il est devant la maison, à droite.
Mais cette méthode est à mon avis bien trop gourmande en ressources, et c'est bien ce qui m'inquiète. Ma fonction draw ferait beaucoup de test, beaucoup de calculs, parfois des "swap", et c'est sans compter les mise à jour des sprites animés, bref..
Que pensez vous de tout ça ?
[attachment deleted by admin]