VertexArray vs Sprite

Bonjour !

La semaine dernière, j'ai commencé à m'intéresser à la conception d'un jeu vidéo 2D (sans avoir l'intention d'en faire un complet mais au moins quelque chose de jouable avec 2-3 maps, ça serait un excellent objectif pour ma part ) en utilisant d'abord SDL puis je me suis tourné vers SFML car il était plus adapté à la façon dont je concevais mon jeu (et je trouve qu'il encapsule déjà pas mal de chose, enfin bref étant un gros débutant en la matière je ne vais pas m'avancer sur le sujet plus que ça mais j'ai eu plus facile de prendre en main SFML que SDL d'où le changement).

Bref, là j'en suis à concevoir ma première tile map. J'avais déjà une idée d'algo en tête : une simple boucle créant un sprite, puis le dessine mais de ce que j'ai pu voir c'est à éviter : si j'ai bien compris le problème, SFML utilise par défaut l'accélération matérielle, ce qui a des avantages mais aussi des inconvénients : le fait de demander au GPU de dessiner une tuile est coûteux (SFML utilisant OpenGL, y a toute une initialisation à faire), surtout si l'on demande cela à chaque tuile (il y a autant d'appel à la méthode draw que de tuile). Par contre l'affichage de la tuile sera bien plus rapide. Sur le site, il est alors préconiser d'utiliser un tableau de vertex (un vertex est un « point » ou plutôt un sommet) : il faut donc « dessiner » la tuile coté par coté, mais l'avantage est qu'on stocke chaque tuile dans un tableau et par conséquent on fait, au final, un seul appel à la fonction draw.

Un exemple de code est présenté dans ce tuto.

Le problème c'est que j'ai un peu plus de mal à le comprendre (bien qu'après l'avoir relu plusieurs fois ça s'est un peu éclairci mais je trouve cela plus compliqué comparé aux sprites).

L'autre question que je me suis posé, c'est que, si, encore une fois, j'ai bien compris, le seul avantage des vertex dans ce cas (ou du tableau de vertex plutôt) est de pouvoir passer un tableau et non un seul élément à la fois (donc un seul appel à draw) : ne pourrait t-on pas faire de même avec des sprites, c'est à dire faire un tableau de sprite, texturer les différents éléments du tableau et passer le tout à la méthode draw du renderer ?

Bref, j'avoue que sur ce point j'ai un peu de mal à comprendre pourquoi un tableau de vertex marche et pourquoi un tableau de sprite (je parle bien d'éléments de type sf::Sprite) ne fonctionnerait pas.

Si quelqu'un peut éclairer ma lanterne de débutant, ça serait vraiment sympa.

Salut,

Vu que les Sprites peuvent chacun avoir une texture différente, SFML doit effecter des changements de textures entre chaque dessins (des 4 sommets du sprite) même si tu as les même textures (SFML ne le sait pas à l'avance !). Ce n'est pas le cas avec les VertexArray car c'est juste une collection de sommets (coordonnées spatiales et coordonnées de la texture) qui peut être utilisée avec une seule texture (il faut passer la texture à draw quand tu dessines un VertexArray).

Salut,

Qu'est-ce que tu ne comprends pas ? La signification du code ou l'intérêt d'un tableau de vertices ?

Il faut comprendre qu'un sf::Sprite est en quelque sorte lui-même un tableau de vertices, ou plus précisément un tableau de 4 vertices formant toujours un rectangle. De plus un sf::Sprite est une entité parfaitement indépendante, il possède sa propre position, taille, rotation…

Du coup, utiliser un tableau de sf::Sprites, en plus du fait qu'il est nécessaire de les afficher un à un (on ne peut pas dessiner un tableau d'entités d'un seul coup, cf. message de victorlevasseur), représentera donc un tableau de tableaux de vertices, et donc pleins d'entités indépendantes. Ce n'est pas ce qu'on veut de la part d'une tilemap, toutes les tuiles devraient faire partie d'une seule et même entité. En utilisant un sf::VertexArray, on crée donc une entité unique qui a les même caractéristiques qu'un sf::Sprite, mais qui comporte un nombre de vertices beaucoup plus nombreux et la capacité d'avoir des coordonnées de texture différente sur chacun de ces vertices.

Salut !

Oui bah en fait en relisant le code, ce n'est pas « si difficile que ça », j'ai réussi à l'implémenter.

OK je comprends mieux la différence et justement j'allais demander si pour le joueur et les ennemis je devais utiliser un tableau de vertex ou un sprite mais si un tableau de vertex est une entité unique ça n'ira pas vraiment puisque le joueur et les ennemis doivent être des entités indépendantes. Par contre pour le décor « fixe », là, on peut effectivemment rassembler le tout en une seule entité.

Juste une question : si j'ai des éléments de décor « destructibles » ou qui peuvent changer de position (exemple, on pousse un bloc), cet élément ne doit pas faire partie du tableau de vertex concernant le décor (même principe que pour les ennemis) ? En gros, si j'ai bien compris, il faut d'abord faire une couche avec les éléments qui ne seront jamais modifiés et qui peuvent donc être dessinés et ne former qu'une seule entité, puis rajouter par dessus cette couche les éléments qui peuvent être modifiés (et dans ce cas là utiliser un sprite car on doit pouvoir gérer chaque élément séparément).

Pour qualifier ce qui fait partie de la tilemap et ce qui est un sprite, on peut généralement se poser la question suivante : mon élément gardera-t-il constamment une position fixe ?

Par exemple imaginons un élément « destructibles », par exemple une pièce ou un bloc de briques à la Super Mario : il pourra faire partie de la tilemap, car sa position reste fixe, et même s'il disparaît, ce sera juste un changement d'état et d'apparence (et éventuellement une petite animation temporaire par dessus, cette dernière étant un sprite).

En revanche avec un bloc que l'on peut pousser, on pourra s'attendre à ce qu'il change de position, voire qu'il prenne une position entre deux tuiles. Il y a donc de bonnes raisons que ce soit un sprite. Mais il faudrait que tu précises un peu plus les comportements de ton bloc.

Évidemment cela va aussi dépendre du type de jeu que tu es en train de développer, ainsi que de la puissance de ton ordinateur. Par exemple, Super Mario World sorti en 1991 devait utiliser un minimum de performances pour tourner fluidement. Le nombre de sprites était donc extrêmement limité. Aujourd'hui dans un New Super Mario Bros., on a plus ce genre de limite, et donc on mets autant de sprites que l'on veut (pièces qui bougent, terrain qui bascule…). Donc si un élément te paraît plus simple à implémenter en tant que sprite, alors fais en un sprite (à moins que ton jeu demande déjà énormément de performances).