Sur quoi se base la classe clock pour mesurer le temps ?

[Lolilolight]

Salut,
je voudrai savoir sur quoi se base la classe clock pour mesurer le temps, est ce qu'elle se base sur l'heure locale de l'OS ou bien sur la vitesse d'exécution de l'application ?
Car moi j'ai besoin de quelque chose qui se base sur l'heure système plutôt histoire que la mesure du temps soit la même partout.

[Laurent]

La mesure du temps est la même partout.

Je trouve que tu as emprunté un raccourci bien rapide, pour passer de "je dois multiplier le temps par 0.7 pour que mes algos de compensation de lag réseau fonctionnent" à "sf::Clock ne mesure pas le temps pareil partout"

Avant de dire ça, personnellement j'aurais fait un test très simple :
- 1 application qui inscrit le temps écoulé en ne faisant rien (sf::sleep)
- 1 application qui inscrit le temps écoulé en tournant à fond (while (true) {...})

Si réellement la différence de 0.7 que tu constates est liée à ça, alors tu devrais rapidement voir le temps des deux applications diverger. Mais mon petit doigt me dit que ça n'arrivera pas

Sinon, si tu veux vraiment fouiller, et bien tu  peux regarder quelle fonction est utilisée par sf::Clock selon l'OS, et lire autant de doc qu'il le faut sur celle-ci pour comprendre exactement comment elle fonctionne.

[Lolilolight]

Avec 2 applications simple monothreadée je n'ai pas de différence mais avec de grosse appli y'a quand même une petite différence et je dois parfois faire des ajustement en dur dans le programme.

[Laurent]

Oui mais c'est quoi "une grosse appli" ? Quelle différence avec l'appli simple qui tourne à 100% de CPU ? Si la différence ce sont les threads, alors balances-en plusieurs. Mais en tout cas si le problème est réellement causé par sf::Clock en elle-même, alors normalement on n'a pas besoin de la logique de jeu, du réseau, du dessin, etc. pour reproduire le problème.

[Lolilolight]

Non ça vient plutôt quand j'utilise plusieurs threads, mais ça, ça été expliqué dans un article que j'ai vu sur windows qu'il y avait des sauts de temps et donc un temps un peu trop à l'avance dans certains processus.
La logique du jeux côté client n'est donc pas la même que celle du côté serveur, j'ai donc du faire le * 0.7 mais bon dans une grosse appli c'est dur d'avoir un truc précis surtout dans le cas de la synchronisation réseau, car, le temps de latence est variable, à mon avis, la cause, c'est plutôt ça.
De plus j'utilise plusieurs sf::Clock pour remettre à jour la logique du jeux histoire d'alléger un maximum les performances CPU.
Quand j'utilise plusieurs sf::clock (une pour le temps de latence et une autre pour update la logique du jeux.à ça saccade déjà moins.)

[Eroy]

Loli, à chaque foi que tu postes un truc c'est toujours la même chose, t'as de gros soucis avec ton code (c'est pas anormal on en a tous plus ou moins assez souvent ) mais direct tu viens dire "hey attends ça c'est un bug dans la sfml c'est pas possible".
Et bien non, franchement ya juste a peu près 0.005% de chance que t'en découvres vu ce que tu devs (pas de choses exotiques) alors ya un moment si ça ne passe pas il faut que tu fasses un gros ctrl+molette sur ton code, quitte à tout recoder (et savoir tout recommencer c'est ce qui différencie en partit un bon d'un mauvais dev).

[Laurent]

Il peut y avoir des bugs dans SFML, ce n'est pas le problème.

Le souci c'est que lorsque tu as un soupçon, tu ne prends pas le temps de tester ça rigoureusement et précisément, tu tires immédiatement des conclusions. Parfois il faut écrire des petits programmes pour confirmer ou infirmer des soupçons sur un comportement anormal. Tant que tu restes cloîtré dans ta grosse appli, tu pourras tirer toutes les conclusions que tu veux, ça ne nous aidera pas pour autant à avancer. Tant que tu posteras des messages de ce genre je ne m'impliquerai pas beaucoup dans la résolution de tes problèmes, il faut que tu viennes sur le forum avec des faits un peu plus précis.

[Lolilolight]

Ok, je vais essayer d'être plus précis une fois que j'en serai à la phase de résolution de bugs dans mo projet.
Pour le moment je ne peux peux pas être plus précis je sais seulement que :
Pour le serveur j'utilise un thread qui déplace les personnages à chaque tour de boucle.
Pour le client je prédis la position du personnages en fonction du temps de latence et du temps écoulé entre 2 mises à jours, et je mets à jour la position à chaque tour de boucle en fonction du temps écoulé depuis la dernière mise à jour.
Je n'utilise pas de thread pour faire cela côté client, juste un thread côté serveur.
Et la position du personnage côté serveur est toujours un peu derrière celle du client à chaque mise à jour pour cela que j'ai du multiplier le temps écoulé depuis la dernière mise à jour par 0.6 et là, c'est mieux.

Donc il est fort probable que c'est lorsque j'utilise un thread que ça pose problème car j'ai testé avec deux appli simple sans thread et là ça ne diverge pas.
Et puis je vais m'arrêter là car il est fort probable que ce bug ne vienne pas de la SFML.
Pour le moment j'ai trouvé une solution temporaire donc je vais continuer le développement, repartir à zéro ne me servira à rien vu que j'aurai toujours ce même bug.
Et j'ai lu que le bug vient plutôt de la méthode sur windows pour récupérer le temps écoulé entre plusieurs threads, pas de la SFML.
Chez ogre j'ai lu qu'ils ont du faire aussi un truc genre à moi.

PS : j'ai fait un cout sur les valeurs du temps écoulé entre chaque tour de boucle côté client et serveur, et j'ai remarqué que côté serveur, dans le thread donc, elles étaient anormalement plus petites.
PS 2 : Bon avec 2 appli et un thread tout simple qui ne fait que afficher le temps écoulé ça ne diverge pas, je ne vais pas dire qu'il n'est pas impossible que ça vienne de mon code non plus ou alors c'est quand mon thread exécute du code plus lourd, bref..., dur à débuguer ce genre de choses. :/

[Lolilolight]

Haaa ça y est c'est bon, j'ai fini par trouvé pourquoi.

[G.]

Pourquoi ?

[Laurent]

Haaa ça y est c'est bon, j'ai fini par trouvé pourquoi.

Super. Et après tout le cinoche que t'as fait sur le forum, tu ne te dis pas qu'on aimerait savoir ?

[Lolilolight]

Bah j'avais tout simplement oublié de faire un produit scalaire quelques part. X_X
Désolé pour tout ce cinéma.
Le problème ne venait que avec les déplacements à la souris donc je me suis dis je calcul surement mal sa futur position quand il fait un déplacement à la souris, il faut dire, c'est pas très évident de calculer ça de manière précise. :/

[Lolilolight]

Et aussi c'est parce que je récupérais pas le temps au bonne endroit dans mon programme avec la classe sf::clock.
Un restart aussi que je n'ai pas fait au bonne endroit, bref...
Maintenant c'est vraiment bien plus fluide même si je n'ai pas très bien compris pourquoi, bref..., tant mieux, je vais pouvoir passer à la suite. (Système de combat, afficher les barres de vie, etc...)
Je ferai surement un topic de présentation du projet dès que j'aurai un système de combat.
Merci pour cette librairie qui cartonne tout. (Même si ce n'est qu'une surcouche d'autres librairies.)

PS : Non en fait ça va j'ai compris, je devais prédire la position du perso en fonction du temps de latence et non en fonction du temps de transfert lors de la mise à jour, voilà la connerie que j'ai faîte.
Je me suis pas mal embrouillé avec les différentes variable Time que j'ai utilisé, il faut dire ce n'est pas si évident que ça.
Mais maintenant ça marche j'ai des personnages et monstres qui bougent bien en réseau sans trop surcharger la bande passante et je suis fier de moi.
Ca tourne même avec un serveur et quelques clients sur un même PC.

[Lolilolight]

Bon bah la solution était toute simple finalement, il fallait que je prédise la position suivante et que je calcule la position courante du personnage à partir du moment ou le client reçoit les données et non pas à partir du moment ou il les envoient, et depuis c'est fluide.