2D isométrique, VertexArray

[Hypnéos]

Le nombre de textures est en effet un problème.
Est-ce que tu as déjà une idée du nombre de textures qu'il y aura à l'écran?

Tu pourrais rendre ton terrain par "bloc" de (par exemple) 8 cases de coté?
Et actualiser seulement les blocs qui ont changés (personnages qui se déplacent, etc)

Une solution plus ... complexe ... pourrait être d'utiliser un shader... avec un paramètre "distance depuis la 'camera' "
Malheureusement (*) sf::Vertex ne permet pas d'ajouter des paramètres supplémentaires, donc il faudrait en venir à des "hacks" tels que :

• utiliser une des valeurs non-utilisées ( canal alpha de la couleur ? ) pour paramètre.
  Problème : tu as peut-être envie de rendre invisible les objets qui bloquent la vue ?
• Dériver une classe de sf::VertexArray et modifier la fonction draw()
  Problème : tu devras réécrire tout le stockage de la classe pour prendre en compte la nouvelle valeur plus(+) utiliser openGL directement dans la nouvelle méthode draw()  ( plus écrire un shader )

<note d'après relecture :>

Les points que j'ai abordés sont très vagues et très risqués.
Je tiens aussi à dire que je n'ai quasiment aucune expérience dans ces domaines.

@Laurent :  Est-ce que les renderTextures peuvent être modifiés pour avoir un composant GL_DEPTH ?
( J'ai essayé de rechercher sur le forum, mais j'ai reçu une 'Database error'  >_< )

[math77]

Tu pourrais rendre ton terrain par "bloc" de (par exemple) 8 cases de coté?

Tu veux parler d'un système de "chunks", c'est-à-dire découper la map en zones de X blocks * X blocks ?

A vrai dire je ne sais pas combien de texture il y aura à l'écran, mais sachant qu'il y aura 3 couches, que la couche du sol sera entièrement remplie par des tiles, il doit y avoir un grand nombre.

Et actualiser seulement les blocs qui ont changés (personnages qui se déplacent, etc)

Actualiser les chunks visibles dans l'écran ? Mais en utilisant des VertexArrays ou une RenderTexture ?

Les VertexArrays ne peuvent prendre qu'une texture donc il faudrait que je crée le tileset dans une renderTexture puis que j'utilise cette dernière comme texture du VertexArray.

Sinon je dessine des RenderTextures par chunks et je les "colle" les unes contre les autres", et une fois dessinées, je n'ai plus qu'à les afficher comme une image de fond fixe, je devrai par contre la refaire si la map change (lorsqu'on se déplace par exemple).

Une solution plus ... complexe ... pourrait être d'utiliser un shader... avec un paramètre "distance depuis la 'camera' "

Je n'y connais absolument rien en shader, je préfère éviter

[Laurent]

@Laurent :  Est-ce que les renderTextures peuvent être modifiés pour avoir un composant GL_DEPTH ?

Oui.

J'ai essayé de rechercher sur le forum, mais j'ai reçu une 'Database error'

Cherche plutôt dans la doc
Et quand tu cherches sur le forum, pour éviter les erreurs, ne sélectionne pas tous les forums, cherche uniquement sur ceux qui sont pertinents.

[Hypnéos]

Tu veux parler d'un système de "chunks", c'est-à-dire découper la map en zones de X blocks * X blocks ?
[...]
Actualiser les chunks visibles dans l'écran ? Mais en utilisant des VertexArrays ou une RenderTexture ?

Je pensait à quelque chose comme : VertexArray -> RenderTexture -> RenderWindow.
Pas la meilleure solution pour atteindre 60 FPS si on doit le répéter à chaque frame...

Je n'y connais absolument rien en shader, je préfère éviter

Sage décision, c'est une force puissante, mais difficile à maîtriser.
<insert Star-War quote>


Merci Laurent, j'avais oublié la doc  .
Au fait, je n'ai pas vu de shaders dans les source; est-ce que je suis passé au-dessus, ou SFML n'en utilise pas ?

[math77]

Je pensait à quelque chose comme : VertexArray -> RenderTexture -> RenderWindow.
Pas la meilleure solution pour atteindre 60 FPS si on doit le répéter à chaque frame...

Mais en utilisant le systeme de chunk ?
Du genre : créer une renderTexture par chunk, la remplir au chargement de la map et aux déplacements du personnage, puis lorsque on ne bouge pas, on se contente d'afficher les renderwtectures déjà dans la mémoire ... donc très peu d'appels a draw()

Qu'en pensee vous ?

[Hypnéos]

C'est ce que je voulais dire; mais tu as l'air d'avoir mieux compris que moi 

Ce qui me soucie, c'est que si tu veut faire la moindre animation, il faudra soit reconstruire le chunk, soit en faire une copie par frame d'animation.

C'est un prix cher pour avoir de l'eau animée. 


Je vais voir si je peux faire quelque chose avec openGL...

[math77]

Parce que sinon ya aussi la méthode du je crée le tileset dans une rendertexture et je fais un vertexArray pour afficher la map

Seulement rapport difficulté gain en performance je ne sais pas laquelle vaut mieux :/

Tkt si je faisais mes rendertextures ça serait pour le sol (et mon sol n'est pqs animé^^)

[Lolilolight]

Ca dépend de ce que tu veux faire.

Si ton sol est statique et que l'ordre d'affichage est le même pour tout les vertexarray de ton tileset alors, une rendertexture ou une tilemap (si t'a pas besoin de faire du blending) feront l'affaire.

Sinon, si ton sol est dynamique par exemple si l'eau peut passer par dessus le bloc alors là, il va falloir que tu trie les VertexArray dans l'ordre avec lequel tu veux les afficher.

Et là y'a pas vraiment le choix je n'ai pas trouvé d'autre solution plus rapide que de dessiner tout vertexarray par vertexarray, j'avais trouvé une solution en rajoutant une composante z aux vertexarray pour le sol et actvier l'alpha test et le depth test mais comme il failait reconstruire la tilemap à chaque rendu bah, ça n'était pas vraiment mieux finalement que de dessiner tout un par un.

Ou alors faire un système qui, récupère la tile animée dans ta tile map et change son z order à chaque rendu..., mais je sais pas si c'est vraiment plus rapide que de créer un thread externe qui insère les tiles animé au bonne endroit dans ton vecteur de tiles triées. (chose que je fais pour mon framework.)
Et ça me pose vraiment problème car mes tiles ne sont pas en bloc comme toi, j'utilise de la transparence plutôt, mais si tes tiles n'ont pas de transparence tu pourrais passer directement par opengl je pense pour le dessin et jouer avec le zorder plutôt que de t'embêter avec la SFML qui n'est qu'une surcouche pour simplifié les choses mais qui n'est pas très optimisées pour certains cas bien précis car elle ne permet pas de faire assez de choses.

PS : se serait bien d'ajouter la possibilité de rajouté une composante z aux vertexarray dans une version future de la SFML, rajouté quelques primitives de synchronisation pour le multi-threading, rajouté la gesion du protocole SSL avec des socket SSL, etc...
Bref moi je le fais déja en modifiant pas mal SFML mais bon....

[Laurent]

PS : se serait bien d'ajouter la possibilité de rajouté une composante z aux vertexarray dans une version future de la SFML, rajouté quelques primitives de synchronisation pour le multi-threading, rajouté la gesion du protocole SSL avec des socket SSL, etc...

C'est un peu hors-sujet ici, si tu veux en discuter tu peux ouvrir un (ou plusieurs) nouveau(x) sujet(s).

[Hypnéos]

J'ai fait quelques test avec openGL; à moins que la carte ne soit très ( trèèèèèès ) complexe, SFML est une meilleure solution.

Pourrais-tu nous donner une approximation de ce qu'il y aura à l'écran dans le jeu final ?

[math77]

Voici quelques images tirées de projets existant pour montrer à quoi pourra ressembler mes maps :













Ce ne sont que des exemples, mais il y aura 3 couches :

- sol
- décorations sur le sol (herbe, etc.)
- objets (maisons, arbres, etc.)

[Hypnéos]

Merci, c'est très utile.
Je pensais à quelque chose de plus compliqué que nécessaire. 

En me basant sur ces exemples, je crois que tu n'as pas à te faire de souci.

[math77]

Merci

Quelle solution te parait la meilleur du coup ?

[Hypnéos]

Si tu utilise un système de chunks, je ferais quelque chose comme :

Au chargement de la chunk :

Dessin de l'arrière plan dans un RenderTexture ( tiles + petit objects )

A l'affichage :

Dessiner l'arrière plan,
puis les objets en partant du plus éloigné.

Tu n'as pas besoin de trier les objets à chaque frame.
Les défauts ne sont aussi voyants qu'on pourrait le penser :
Regarde dans la 3^ème image, le premier rocher dans la rivière à gauche du personnage.

[Lolilolight]

Tu n'as pas forcément besoin de faire de tri, il suffit juste d'utiliser 2 std::vector par exemple :

tiles[couche][tile]
 

Et ensuite t'a plus qu'à faire une boucle qui récupère tout et qui insère le tout dans un autre vecteur (ça s'appelle le tri par insertion et c'est plus rapide.)

for (int couche = 0; couche < tiles.size(); couche++) {
      for (int  tile  = 0; tile  < tiles[couche].size(); tile++) {
            tilesVisible.push_back(tiles[couche][tile]);
      }
}
 

Bref moi c'est comme ça que je fais mais en récupérant uniquement la partie du monde qui se trouve dans la vue.

Je n'ai pas trouvé de meilleur solution que de les dessiner une par une. (vu que j'utilise de la transparence le depth test ne marche pas.)

Mais pour toi, si tu n'utilises pas de transparence, alors oui il y a une meilleur solution et tu pourrais même dessiner tout d'un coup en donnant une composante z à tes vertexarray.

PS : je ne tiens pas vraiment à rouvrir un nouveau sujet pour discuter de ça pour l'instant je voulais juste dire que se serait bien mais c'est pas urgent vu que d'autres librairie le font déjà et puis je vais je pense ouvrir un sujet pour en discuter sur le forum Anglais.
Je disais juste ça si l'envie te venait un jour d'ajouté de nouvelles fonctionnalité à ta librairie.

Mais pour le sol animé le mieux est quand même je pense d'utiliser un shader ou peut être une texture 3D

PS 2 : tu m'as donné une idée je pense que je vais mixer les 2, tiles en bloc et tiles plates, ça pourrait être sympa!