Gérer le temps le mieux possible

Bonjour(re)

Mon programme (un jeu vidéo crée avec la SFML) commence a prendre forme, et fonctionne plutôt bien.
Cependant, quand je crée, par exemple, un élément de décor que je duplique de façon conséquente (au moins quelques centaines), le programme, une fois lancé, est souvent plus lent, au début, mais au bout de quelques secondes/minutes, il se remet a fonctionner normalement. Plus je met d'images, plus il est souvent lent au démarrage, mais il reprend quasiment le même bon fonctionnement après quelques secondes. En bref, le temps semble fluctuer. Parfois je laisse tourner le programme un certain temps, ce qui lui fait générer de nombreuses images et vertex (probablement des milliers), mais il ne ralenti pas pour autant, parfois, même, au contraire, il va plus vite...

j'utilise sf::Time et sf::Clock a chaque boucle pour mesurer le temps...

Dans les perfs de l'ordi, je ne note aucun changement particulier, ni de mémoire, ni de processeur durant le programme

Je suppose que cela vient de la gestion du temps qui n'est pas assez précise.(mais je me trompe peut être).
Ma description est très floue, mais si jamais mon cas vous inspire un type de problème en particulier, je suis preneur!

Sinon, avant de pousser mes recherches, je viens vers vous pour vous demander si vous connaissez une méthode/bibliothèque libre, efficace pour gérer le temps de la façon la plus précise possible.

Merci si vous pouvez m'aider

Salut

Essaye de tracker les IO disque/réseau au moment où tu observes des ralentissements, tu as peut-être des pics d'IO qui peuvent expliquer le phénomène sans que ça se répercute sur la RAM ou le processeur. Du reste, si cela a lieu au moment de charger des images, ça pourrait s'expliquer par la lecture massive sur le disque à ce moment. Puis, lorsque le programme rentre dans une routine, le cache du disque prend le relai et les IO sont plus rapides.

C'est une hypothèse, qui vaut le coup d'être étudiée, à mon avis. Pour y remédier, il y a diverses solutions, l'une d'elle est de précharger les tectures et images en RAM.

Bonjour,

Merci pour votre réponse. Je vais voir ce qui se passe avec IO disque/réseau. Sauf erreur, je charge bien toutes mes textures en RAM au lancement du niveau...Cela fait d'ailleurs un temps de chargement de quelques secondes. Ensuite, ce sont les mêmes textures qui sont utilisés par pointeur via la class "sf::drawable" de la sfml, a l'aide de vertex ou vertexArray, pour toutes les images...J'ai suivit le tutoriel ici :

http://www.sfml-dev.org/tutorials/2....x-array-fr.php

Je continue de faire des tests, et, chose étonnante, cela semble ne plus ralentir...du tout...jusqu'aux prochains tests, du moins.
Je reste assez convaincu que la méthode qui mesure le temps n'est pas assez précise, et j'aurais besoin du maximum de précision, pour que mon jeu soit cohérent...Connaissez vous des bibliothèques, méthodes efficace pour gérer le temps de façon très précise?

j'utilise cette methode la:

http://www.sfml-dev.org/tutorials/2....em-time-fr.php

Normalement, les timers standards (sfml ou autres) sont assez précis pour faire du jeu vidéo (framerate cible à 60Hz, soit 15ms par cycle environ). Si tu as besoin de descendre plus bas, c’est un peu surprenant, et cela posera sûrement des problèmes de déploiement (car il faudra probablement des configurations particulières). Je serais très surpris que la SFML soit moins précise que les timers standards.

Je penche, comme jblecanard, pour une opération i/o synchrone qui provoque une certaine latence (mais pas d’occupation CPU / mémoire visible).

Parmi les choses que tu peux tenter aussi :
* augmenter la priorité du thread qui lagge
* essayer avec l’api standard de C++11 std::chrono http://en.cppreference.com/w/cpp/chrono.
* lancer avec un profileur (mais attention, ça fausse parfois les résultats car l’instrumentation est coûteuse) pour avoir un diagnostic plus précis

Salut. Si je pige bien, le moteur a du mal a gérer les ressources efficacement quand elles deviennent trop nombreuses?
Loin de moi l'envie de "troller", mais pourquoi ne pas essayer un autre moteur? Ogre3d par exemple gère très bien les grosses quantités de ressources (il est par contre plus compliqué).
Je dis ça par ce que j'ai longtemps galéré sur des moteurs "faciles" mais peut optimisés avant que quelqu'un me conseille de passer à un truc plus costaud ;)

Merci pour vos réponses

Citation:

---

pourquoi ne pas essayer un autre moteur?

---

Parce que je fais un jeu en 2D assez simple, qui n'est pas censé demander beaucoup de ressources, et que je débute en programmation. J'ai pensé (j'espère pas à tord) que la SFML pouvait m'offrir la possibilité de faire cela. (Avant j'ai essayé la SDL, mais je reconnais que pour l'instant, la SFML est nettement meilleurs. )

Citation:

---

Normalement, les timers standards (sfml ou autres) sont assez précis pour faire du jeu vidéo (framerate cible à 60Hz, soit 15ms par cycle environ). Si tu as besoin de descendre plus bas, c’est un peu surprenant

---

En fait, je me suis fixé un ratio de 16 images/secondes pour les animations, et je prend la mesure du temps toutes les 31250 microsecondes, soit 32 fois/secondes. mais alors du coup, je suis au dessus de 60Hz?

Ok excuse-moi mais le fait que tu parles de "vertex" m'a fait penser à de la 3d. Ceci-dit, il est tout à fait possible de faire de la 2d en utilisant de la 3d mais c'est pas le sujet.
Du coup je te laisse investiguer sur ce qui a été dit. Si tu peux isoler le code qui rame la question sera sûrement résolue à 80%.
Courage ;)

Citation:

---

Envoyé par mazertys17

En fait, je me suis fixé un ratio de 16 images/secondes pour les animations, et je prend la mesure du temps toutes les 31250 microsecondes, soit 32 fois/secondes. mais alors du coup, je suis au dessus de 60Hz?

---

16 images / seconde, ça fait 16 Hz. 32 fois par seconde, c’est 32Hz, donc bien inférieur aux 60Hz dont je parle.

Par contre, qu’entends-tu par « je prends la mesure du temps toutes les 31250 microsecondes » ?

Généralement, quand on fait un traitement cyclique comme ça, on fixe un temps de cycle, on fait le traitement correspondant à un cycle, et une fois ce traitement fait, on regarde le temps qui s’est écoulé depuis le début du cycle. S’il est inférieur au temps de cycle, on « sleep » de la différence. S’il est supérieur, en fonction des cas, on va lancer le cycle suivant directement, ou alors accepter de rater complètement un cycle et attendre jusqu’à la fin du cycle suivant.

Là je ne comprends pas ce que tu mesures.

Merci pour vos réponses.

Citation:

---

Par contre, qu’entends-tu par « je prends la mesure du temps toutes les 31250 microsecondes » ?

---

En fait, pour l'instant, je me contente de faire tourner le programme normalement, sans "sleep". Il affiche donc toutes les images etc a chaque boucle, tel qu'elles sont, et, si 31250 microSecondes se sont écoulé, alors je le signale a tous les objets qui vont faire ce qu'ils ont a faire (calculer des déplacements, changer des images etc...).

Mais, maintenant que vous le dites, c'est sans doute cela qui déclenche des déséquilibres de temps, a supposé, tout simplement, que la boucle simple (images fixe etc..) prenne , ne serais-ce que 10000 microSecondes, ca risque de tout décaler.
J'espère, en tout cas, que c'est bien cela.

Question surement idiote, mais dans mon cas, un "sleep" ne risque pas de saccader les images?

Citation:

---

En fait, pour l'instant, je me contente de faire tourner le programme normalement, sans "sleep". Il affiche donc toutes les images etc a chaque boucle, tel qu'elles sont, et, si 31250 microSecondes se sont écoulé, alors je le signale a tous les objets qui vont faire ce qu'ils ont a faire (calculer des déplacements, changer des images etc...).

Mais, maintenant que vous le dites, c'est sans doute cela qui déclenche des déséquilibres de temps, a supposé, tout simplement, que la boucle simple (images fixe etc..) prenne , ne serais-ce que 10000 microSecondes, ca risque de tout décaler.
J'espère, en tout cas, que c'est bien cela.

---

Oulà ! oui c'est bien possible...:aie: Le concept est plus : tu calcules à chaque boucle le nombre de milisecondes écoulées, et tu utilises ce nombre comme un ratio que tu multiplies avec les translations que tu appliques à tes objets.

Code:

---

deplacement = milisecondes_ecoulees_depuis_la_derniere_boucle * constante_de_vitesse

---

Comme ça le déplacement est constant quelque-soit le framerate ;)

Citation:

---

Question surement idiote, mais dans mon cas, un "sleep" ne risque pas de saccader les images?

---

Un sleep est très rarement une bonne idée. Surtout dans le domaine du jeu vidéo :roll:

Citation:

---

Un sleep est très rarement une bonne idée. Surtout dans le domaine du jeu vidéo

---

C'est un peu ce que je me disais, d'instinct...

Citation:

---

Le concept est plus : tu calcules à chaque boucle le nombre de milisecondes écoulées, et tu utilises ce nombre comme un ratio que tu multiplies avec les translations que tu appliques à tes objets.

---

A vrai dire, ca me compliquerait un peu la tache vu que j'ai pensé les choses autrement pour l'instant...ma vitesse est justement fixé en fonction du ratio de temps, a savoir 31250 microsecondes...

Je me dit que peut être le bon partie a prendre est le suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10

while(tempsEcoule.asMicroseconds() < 31250) { tempsEcoule = clock.getElapsedTime(); }   if(tempsEcoule.asMicroseconds() >= 31250) { clock.restart(); }

---

Quand je lance le programme, tout semble fonctionner normalement, pas de ralentissement a signaler...Cette solution vous parait-t-elle saine? :?

Citation:

---

Envoyé par SkyZoThreaD

Un sleep est très rarement une bonne idée. Surtout dans le domaine du jeu vidéo :roll:

---

Tu peux développer ? Je n’y connais rien en jeux vidéo, mais en industriel, un sleep est nécessaire si tu veux avoir un temps de cycle régulier.

Ou alors, plutôt qu’un sleep, tu te bases sur une horloge / un signal (genre, le vsync ?) qui lui est régulier ?

Citation:

---

Tu peux développer ?

---

Citation:

---

en industriel, un sleep est nécessaire si tu veux avoir un temps de cycle régulier.

---

Dit comme ça on dirait que je donne des leçons sur les bonnes pratiques de prog mais ce serait prétentieux :roll:
Ce que je veux dire c'est que les cycles ne sont pas sensés être réguliers car le framerate du jeu varie selon ce que le GPU a à rendre.
Les callbacks dans lesquels on code "en mode cpu" sont appelés avant et/ou après le rendu et un sleep serait bloquant pour le rendu ce qui serait curieux à mes yeux.
Après, si ça se trouve, les connaisseurs ralentissent les callbacks pour des raisons que j'ignore mais j'en doute...:weird:

Citation:

---

tu te bases sur une horloge / un signal (genre, le vsync ?) qui lui est régulier ?

---

Tu ne te bases donc pas sur une horloge mais bien une "fonction" de rendu qui interagit avec le GPU via l'api de rendu (OpenGL, DX).
Concernant le vsync, il régularise effectivement le cycle global mais uniquement si le FPS atteind ou dépasse le rafraîchissement de l'écran.
Il faudrait demander à un gourou genre Little_White, Loulou ou un autre de confirmer ou d'infirmer ce que je dis quand-même :zoubi: