[SFML2.0] Déplacement de la vue lente, mouvement de la caméra saccadés.

[Eroy]

il doit le faire à chaque frame.

[Laurent]

Il doit faire quoi à chaque frame ?

[Eroy]

Ben s'il gère les ombres il a pu être tenté de déplacer les ombres des persos sur son render ce qui l'oblige à récupérer la texture au moins à chaque foi que quelque chose se déplace.

[Laurent]

const Texture& RenderTexture::getTexture() const
{
    return m_texture;
}

Ce code extrêmement simple a deux implications :
- tu peux appeler cette fonction autant que tu veux sans impacter les performances
- ce n'est même pas la peine de rappeler cette fonction après que le contenu de la texture a changé, l'instance de sf::Texture qui est renvoyée est toujours la même, seuls les pixels ont changé

Ce qui prend du temps c'est le dessin en lui-même, en dehors de ça sf::RenderTexture ne fait rien de coûteux de plus que sf::RenderWindow. Une fois que tu as dessiné quelque chose, ça y est c'est sur la texture et prêt à être utilisé.

Histoire de remettre une petite couche : sf::RenderTexture et sf::RenderWindow sont strictement identiques, la seule chose qui change c'est que l'une va écrire des pixels sur une texture, et l'autre sur une fenêtre. Il n'y a donc rien de mystique dans sf::RenderTexture qui la rendrait plus lourde à utiliser.

[Eroy]

Oui je le sais bien je me suis mal exprimé.

Ce que je veux dire c'est que si on ne sais pas que dessiné est lourd ou juste qu'on débute avec la sfml (ce qui était mon cas quand j'ai rencontré le problème) on peut être tenté de faire :

- je crée x renderTextures (personnages, décores, eau, ombres, lumières...)
- je déplace mes éléments graphiques dessus
- à chaque frame je rafraichi mes renders pour qu'ils prennent en compte les nouvelles positions
- à chaque frame je récupère donc les nouvelle textures
- et à chaque frame je redessine le renderTarget principal avec mes nouvelles textures.

[Laurent]

Pourquoi passer par X textures de rendu intermédiaires ? Je veux dire, qu'est-ce qui t'avait fait pensé que c'était ça qu'il fallait faire ?

[Eroy]

Et bien, comme tu l'as constaté les vues ne sont pas forcément évidentes à comprendre dans un premier temps (bien qu'elles deviennent indispensable par la suite x)) alors quand on tombe au début sur le renderTexture on se dit "hey mais attends, voilà ce que je cherchais ! et en plus ça marche nickel !".

Je pense que c'est la principale explication. Le fait que la renderTexture est une notion de conteneur simplifie la compréhension fasse à la vue qui est simplement liée aux objets. S'il y avait une classe toute simple "objets graphiques + vue" personne aurait de soucis avec les vues. Enfin c'est une supposition.

[Laurent]

Ok je vois. J'espère que maintenant, avec les tutoriels à jour, ce genre de mauvaise interprétation pourra mieux être évitée.

S'il y avait une classe toute simple "objets graphiques + vue" personne aurait de soucis avec les vues.

C'est sans doute vrai. Mais là on toucherait à des trucs déjà un peu trop haut niveau pour SFML.

[Eroy]

Oui, ça impliquerait d'associé des drawable+transformable et ajouter un draw de cet objet à renderTarget, ce qui est plutôt le rôle d'une sur-couche (moteur ou framework) surtout à cause de la notion d'inclusions récursives qui peut nuire aux bonnes pratiques dans certains framework.

[Lolilolight]

Bah moi, ce que je fais c'est que à chaque tour de boucle :
-Je dessine mes ombres sur mes render texture.
Pour les autres couches, je stocke tout dans un vecteur et j'affiche d'abord les couches du sol puis les décors (bâtiments, murs, arbres, etc...), il n'y a que pour les personnages et les monstres ou je suis obligés d'insérer la tile dans le vecteur car eux, lui ils bougent donc,parfois je dois le dessiner devant parfois derrière les décors.)
Mais j'ai déja une classe entité et une grille virtuelle en isométrique qui gère tout ça. (Couches, collisions, récupérer toutes les entités qui sont dans la vue de manière rapide, etc...)
Donc il n'y a que les ombres et les lumière pour lesquelle j'utilise une render texture que je rends en en add et en multiply avec une render texture.
Je mettrai des screens des différences que j'ai avec les ombres sur mes 2 PC. (Celui avec carte graphique et mon autre plus ancien avec juste un bête chipset intel.)
Sur l'un ça m'affiche les ombres sur l'autre ça m'affiche une ligne noir horizontale au milieu de l'écran.

Bref..., et à chaque passage de la boucle je dois refaire des setView sur la RenderTarget de la fenêtre et sur la RenderTarget des render texture, sinon, les ombres ne se déplacent pas avec la caméra...
A mon avis c'est ça qui ralenti..., les appells successifs à setView.

[Eroy]

non justement le setView est super performant et tu peux même setter une vue différente pour chacun de tes sprites sans que ça baisse les perfs (c'est ça la force c'est que c'est juste un set d'un pointeur, ya aucun calcul qui est fait).

Par contre tu ne dois pas passer par un renderTexture pour gérer les ombres, il vaux mieux que se soit des sprites indépendants, se sera beaucoup plus performant (tu vas multiplier par 2000 les perfs à ce niveau).

En gros les render textures sont fait pour créer des textures mais au coup par coup. Par exemple une minimap non mobile, tu vas la créer une seule fois à partir de ta map lors de son chargement et la transformer en texture, ce qui te permettra de la gérer en temps que simple sprite et donc de bien augmenter les perfs. Ce qu'il ne faut surtout pas faire justement c'est dessiner des renderTexture au frame par frame car c'est juste pas fait pour ça et c'est super lent du coup et ce, même si tu n'en utilise qu'un... Ca double ton temps de dessin à chaque frame et ça tu ne veux pas. xD


ps: faut vraiment que tu te fasses des tests de temps pour voir toi même ce qui pompe sinon tu n'arriveras jamais à optimiser "à vue d'oeil".

[Laurent]

Non non non et non. sf::RenderTexture sert aussi à faire des rendus temps réels (qui changent à chaque frame). Les ombres sont un excellent cas d'utilisation de cette classe. Rien n'est plus performant, si on le fait bien. Je le répète une dernière fois : sf::RenderTexture n'implique aucune perte de performances par rapport à la même chose dessinée sur une fenêtre.

Et puis je vais m'arrêter là parce que j'ai l'impression de tourner en rond

Testez les choses correctement avant de lancer des conclusions à la va-vite.

[Lolilolight]

Mais ça n'aurait pas été mieux de faire une vue par renderframe parce que moi je ne vois pas du tout l'intérêt de faire une vue par rendertexture, et puis suffise que je dessine et que je change de vue si je veux dessiner la minimap qui reste fixe... et ça marche.
Je procède comme ça pour dessiner une grille fixe en iso au dessus de la map que je crée avec mon éditeur.
Moi je pencherais plutôt pour utiliser une rendertexture comme un layer plutôt que une seconde vue, bref...
Sinon au niveau des perfs ça donne dessin fois deux et même si ce n'est pas forcément plus lent avec les rendertexture comme tu le dis si bien Laurent je me rend compte qu'il y a quand même une petite différence au niveau des perfs vu que il y a plusieurs appels à display à faire.

Si ça avait été moi l'auteur de la SFML j'aurai créer les rendertexture plutôt pour faire de nouveaux layers plutôt que pour faire des autres vues.
Même si ça ne change pas tellement au niveau des perfs, ce qui me pose plutôt problème je pense c'est la synchronisation entre le client et le serveur des données pour avoir des mouvements le plus fluide possible.
Mais bon si tu cumules le tout, les rendertexture ne bouffe pas tellement les perfs mais c'est le fait de tout cumuler ou là ça se voit plus.

[Eroy]

Heureusement que c'est pas toi sinon les tutos seraient incompréhensibles  (relis toi, surtout sur les longues phrases parce que des fois ça part un peu en couille x])

Laurent on c'est pas compris encore (toute façon ya personne qui me comprend  ), ce que je veux dire c'est que oui ça ne pompe pas plus de dessiner sur un renderTexture et un renderWindow mais par contre cela implique de dessiner une texture en plus : celle du renderTexture. Et se sont, dans le cas des ombres par exemple, de grosses textures et donc très lentes à dessiner, plus que de passer par une vue + un trie pour gérer les ordres.

[Laurent]

de grosses textures et donc très lentes à dessiner

Là encore, tu bases ce genre de conclusion sur quoi ? Sur l'intuition, qui te dit que plus c'est gros plus ça prend du temps ?
C'est archi-faux : le fillrate (taux de remplissage des pixels) des cartes graphiques permet de remplir tout l'écran en un temps plus que négligeable par rapport à tout ce qui est fait à côté (changement de contexte, d'états, de texture, ...). Donc petite ou grosse texture, aucune différence.

plus que de passer par une vue + un trie pour gérer les ordres

Oui mais là on ne parle pas d'ordre. Les render-textures sont typiquement utilisées pour la gestion des ombres car elles permettent de mettre en oeuvre des techniques de rendu impossibles à réaliser sans surface de rendu intermédiaire. Par exemple, afficher toutes les lumières en blending additif sur la render-texture, puis la render-texture en blending multiplicatif sur la fenêtre. Ou encore, les ombres en mode opaque sur la render-texture, puis la render-texture en multiplicatif sur la fenêtre.

Laurent on c'est pas compris encore

Je crois que c'est moi qui ne me fait pas comprendre, quand je dit d'arrêter avec les conclusions à la va-vite...
Sérieux, cette discussion en est remplie, et je passe mon temps à vous contredire. Je pense qu'on (enfin surtout vous) perd notre temps plus qu'autre chose.