Bienvenue, Invité. Merci de vous connecter ou de vous inscrire.
Avez-vous perdu votre e-mail d'activation ?

Auteur Sujet: [SFML2.0] Déplacement de la vue lente, mouvement de la caméra saccadés.  (Lu 15550 fois)

0 Membres et 1 Invité sur ce sujet

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Finalement je reviens sur ce que j'ai dit, un profiler t'aurait permis de mettre le doigt immédiatement sur le morceau de code "lent", sans que tu aies à pratiquer toute sorte de tests plus ou moins fastidieux.
Laurent Gomila - SFML developer

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Bah en fait je l'ai vu en utilisant le profiler. :)
Pratique ce truc!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Ah ! Ok, impec alors :P
Laurent Gomila - SFML developer

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Oui mais seulement ce n'est pas tout, j'ai du aussi faire un thread qui remet à jour toute la scène toute les x millisecondes, et quand je partage le travail entre plusieurs thread c'est fluide!

J'ai dû faire aussi pareil pour le réseau pour ne pas surcharger le serveur de requêtes.
J'ai du également utiliser les mutex, sinon je me retrouvais avec un écran qui clignotais ça sa se remettais à jour pendant que a faisait les calculs.

Mais j'ai un autre problème maintenant que je vais citer dans un autre post.

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
J'ai passé mon éditeur en SFML2.0, et j'ai eu le même problème donc j'ai du optimiser et j'ai trouvé un algorithme beaucoup mieux encore, c'est le même que celui de Grégouar mais en plus compliqué car vu que il y a aussi des indices négatifs et que je ne peux pas faire de vecteurs avec des coordonnées négatives, et en plus je n'utilise qu'un vecteur à une dimension donc j'ai du décaler les éléments en tenant compte de la tile ayant la coordonnée la plus petite en x et en y, et faire à chaque fois un décalage si ça me donne un indice négatif. (Donc décalage d'indice + redimentionnement de vecteur.)
Mais bon j'ai réussi et c'est très optimal donc je suis content.
Je ne sais pas ou j'ai du avoir la tête quand j'ai codé mon 1ère algorithme mais pas sur les épaule en tout cas.  :-\

Je pourrai faire la même chose en supprimant des tiles pour pas me retrouver avec un vecteur trop grand si je supprime trop de tiles mais se sera pour après..., c'est déjà pas mal hardcore mais je suis fier car j'ai réussi à améliorer un algorithme qu'on m'avait montré. (pour une fois.) u_u

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Bon voila j'ai fais les choses suivantes :

-J'ai optimisé mon algorithme au mieux pour récupérer toutes les entités visibles à l'écran.
-J'ai effectué une approximation pour la position du personnage entre les temps de transferts réseau pour essayer d'avoir un mouvement plus fluide.
-J'appelle toutes les fonctions qui remettent à jour la scène dans un thread.

Malgré tout ça saccade encore un petit peu. (Je posterai une vidéo avec le framerate quand j'aurai plus de temps car en ce moment j'ai pas mal de boulot à l'extérieur.)

Il me semble que la SFML 2.0 est un peu plus lente. (Depuis que j'ai passé mon éditeur en SFML 2.0 j'ai du aussi optimiser l'algorithme hors que ça ne saccadais pas autant avec la SFML 1.6, cependant avec la SFML 1.6 ça ne tournais carrément plus sous windows.)
« Modifié: Mai 05, 2013, 06:46:32 pm par Lolilolight »

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Voila ce que ça donne en ayant testé tout les modules de la SFML. (Graphisme, Qt, les threads, le réseau, couplage avec Qt, etc...)
http://www.youtube.com/watch?v=Er5F6s8q_Qc&feature=youtu.be
Je pense que je vais repasser à du mono maintenant que j'ai optimisé mon algorithme pour la mise à jour de la scène car là j'ai l'impression que ça ne marche pas très bien parfois il ne change pas les tiles pour mes animation du coup les jambes du perso test que j'ai fait ne bougent pas quand il avance.
C'est sans doute dû aux appel à lock et unlock sur le mutex, bref...
Mais bon on voit que ça saccade toujours un peu et j'ai fait une petite map exprès pour qu'il y ai justement moins d'éléments à afficher.
Et je n'ai pas encore rajouter les monstres.
Mais j'ai l'impression que la SFML 2.0 est quand même un peu plus lente que la SFML 1.6 car ça saccadais moins en 1.6...
« Modifié: Mai 06, 2013, 11:58:13 am par Lolilolight »

Eroy

  • Jr. Member
  • **
  • Messages: 60
    • Voir le profil
    • E-mail
"les render textures ne..."
Tu utilises des RenderTextures ?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Citer
Mais j'ai l'impression que la SFML 2.0 est quand même un peu plus lente que la SFML 1.6 car ça saccadais moins en 1.6...
Sur un code complètement équivalent, peut-être un tout petit peu (mais ce n'est pas significatif). Mais comme SFML 2 propose des solutions bien plus optimisées (vertex array) pour les cas à problème, en fin de compte si tu as des performances moindres c'est que ton approche est mauvaise.
Laurent Gomila - SFML developer

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Bon je suis passé en monothread et le résultat est +/- le même mais j'ai quand même un FPS déja un peu + élevé, mais toujours en dessous de 60 qui est la valeur de la synchro verticale.
Et oui j'utilise des rendertextures pour les ombres...

La seule chose que je n'ai pas encore testé mais ça se sera pour quand le projet sera fini, c'est le son.
PS : heu, Laurent : je n'utilise pas les VertexArray, à part pour les lumières mais ici je n'en ai pas mise.
« Modifié: Mai 06, 2013, 12:14:50 pm par Lolilolight »

Eroy

  • Jr. Member
  • **
  • Messages: 60
    • Voir le profil
    • E-mail
Fais attention aux rendertexture, on peut pas vraiment les utiliser en dynamique car ça pompe autant qu'un display principal. Essaie de le virer voir si ça règle pas tes problèmes. ^^

Le mieux c'est que tu regardes les temps d'exécution morceau par morceau de ce qui est executé à chaque frame pour savoir ce qui est lent, c'est le seul moyen de trouver d'où viens le problème.

Et en multithread tu as obligatoirement des fps moins important cela ne rime pas avec les perfs.

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Ok, ok, il me semble aussi que les renderTexture bouffent pas mal, de toute façon il va falloir que j'utilise autre chose que les RenderTextures mais je ne sais pas trop quoi, en SFML 1.6 j'utilisais la fonction pour faire des captures d'écrans dans laquelle je dessinais les ombres et je dessinais par dessus la scène avec le blending.
Il va falloir que je repasse à ça je pense car, les renderTextures ne marchent pas avec les machines qui n'ont pas de carte graphique et je veux que ça marche sur le plus de PC possible.
« Modifié: Mai 06, 2013, 12:58:21 pm par Lolilolight »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Plusieurs choses à clarifier.

1. sf::RenderTexture n'est pas plus lent que sf::RenderWindow, en fait ils utilisent tous deux exactement le même code pour le dessin. Ce qui peut être lent, c'est de passer de l'un à l'autre, car il faut changer de contexte OpenGL. Mais ce n'est pas inhérent à sf::RenderTexture, ça ferait la même chose avec deux sf::RenderWindow utilisées en alternance par exemple. Bref, dire que "les sf::RenderTexture ça bouffe pas mal", c'est un peu trop approximatif.

2. sf::RenderTexture fonctionne en théorie sur toutes les configurations ; les GPUs qui ne supportent pas l'implémentation "moderne" ont une implémentation de secours, un peu plus lente, mais qui marche partout. Et normalement les plus gros bugs, notamment avec les cartes Intel intégrées, ont tous été résolus. Donc si tu as des problèmes à ce niveau il faut me le dire, pas juste se contenter de clamer que "sf::RenderTexture ne marche pas sur certains GPUs" ;)

3. La capture d'écran est toujours dispo avec SFML 2, et elle est bien plus lente que sf::RenderTexture, car elle nécessite des transferts du GPU vers le CPU, qui est un sens à éviter à tout prix car les cartes graphiques ne sont pas optimisées pour.

De manière générale, à moins que ce ne soit officiellement dit (dans les tutos, le bug tracker, ou par moi), faites des tests rigoureux avant de vous baser sur des affirmations approximatives.
Laurent Gomila - SFML developer

Eroy

  • Jr. Member
  • **
  • Messages: 60
    • Voir le profil
    • E-mail
Non mais là le soucis c'est que à tout les coups il fait un getTexture sur son renderTexture pour aller ensuite le passer à son render principal (c'est tentant, j'ai aussi essayé au début x3). Et c'est de ce problème que je parle en disant "utilisation dynamique".
Ptetre le préciser dans la doc : "ne fais pas ça noob !", enfin ça l'est peut-être déjà. :p

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Citer
Non mais là le soucis c'est que à tout les coups il fait un getTexture sur son renderTexture pour aller ensuite le passer à son render principal
Et ? Le but de dessiner sur une texture c'est justement d'utiliser cette texture par la suite, pour dessiner sur une autre cible de rendu, non ? Donc quel est le souci au juste ?
Laurent Gomila - SFML developer