Une explication pourquoi le rendu physique peut-être plus important ? Hé bien cela arrive si les données à afficher sont peu nombreuses et si par contre il y a beaucoup de calculs à effectuer. Comme tu le sais, beaucoup d'opérations sont effectuées par le CPU, même encore aujourd'hui - Si tu dois déformer par exemple un objet no-rigide, la plus grosse partie des calculs sont laissés au moteur de rendu, mais via le CPU. De plus en plus, on permet de charger les GPU avec des programmes mais ça reste encore assez rare (principe des shaders). La gestion de la physique, c'est plus que la simple gravité et la gestion des collisions. Mais même dans le cas des collisions, ça peut prendre du temps, tu t'n es rendu compte déjà quand on calcul la collision de deux formes complexes plutôt que d'utiliser les formes de base (cubes, spheres, etc.)
Maintenant, si ta mutex est au point, je vois pas trop ce qui se passe et n'ayant pas le problème chez moi, j'ai du mal à imaginer...
Il faudrait que tu logges les différents appels et les chronométrer pour comprendre ce qui se passe et être aussi certain que le traitement n'est pas interrompu. Dans ton cas, le système physique doit vraiment pas beaucoup pomper. Normalement tu devrais pouvoir l'appeler plusieurs fois entre chaque affichage...

Si je limite le rendu physique plus bas genre 40 Fps c'est trop limite et les mouvements d'objets ne parraissent pas assez fluide donc 65 Fps me parrait une limite tout à fait raisonnable.Tu en pense quoi ?

A la rigueur, il est possible d'appeler 2 fois le système physique (d'affilée, mais en modifiant le timestep) pour 4 trames d'affichage et de calculer le mouvement intermédiaire par interpolation.

Je vois pas trop l'intérêt d'appeler le moteur d'affichage plus souvent que le moteur physique si tu n'utilises pas de système d'interpolation de mouvement... Tu n'as pas d'animation non plus qui demanderaient "à tourner"... tout dans ton système est géré oar la physique (à part les roues qui tournent sur elle même, mais là, c'est pas ça qui gêne).

A mon avis, l'effet de sacade doit être dû au fait que le timeStep est avancé de façon irrégulière. Si le jeu tourne à 100 FPS, il affiche une image toutes les 0,01s donc entre chaque image il suffit de faire avancer le temps d'une unité (un step). Si le jeu ralenti à 10 FPS et qu'il ne calcule plus qu'une image toutes les 0.1s, il faudra par contre faire avancer le temps de 10 steps entre deux images. Est-ce bien ainsi que tu gères l'avancée du temps ? D'après ton premier message, il est fixe, mais c'est pas possible car il faudrait alors avoir un nombre de FPS fixe aussi ! Je crois que leproblème vient de là et pas d'un problème lié au thread.

Quand je parle de synchroniser physique et affichage, je ne veux pas dire les appeler en même temps ou le même nombre de fois, je veux dire : gérer le timestep du monde physique de façon dynamique en fonction du nombre de FPS.

Une explication pourquoi le rendu physique peut-être plus important ? Hé bien cela arrive si les données à afficher sont peu nombreuses et si par contre il y a beaucoup de calculs à effectuer. Comme tu le sais, beaucoup d'opérations sont effectuées par le CPU, même encore aujourd'hui - Si tu dois déformer par exemple un objet no-rigide, la plus grosse partie des calculs sont laissés au moteur de rendu, mais via le CPU. De plus en plus, on permet de charger les GPU avec des programmes mais ça reste encore assez rare (principe des shaders). La gestion de la physique, c'est plus que la simple gravité et la gestion des collisions. Mais même dans le cas des collisions, ça peut prendre du temps, tu t'n es rendu compte déjà quand on calcul la collision de deux formes complexes plutôt que d'utiliser les formes de base (cubes, spheres, etc.)
Maintenant, si ta mutex est au point, je vois pas trop ce qui se passe et n'ayant pas le problème chez moi, j'ai du mal à imaginer...
Il faudrait que tu logges les différents appels et les chronométrer pour comprendre ce qui se passe et être aussi certain que le traitement n'est pas interrompu. Dans ton cas, le système physique doit vraiment pas beaucoup pomper. Normalement tu devrais pouvoir l'appeler plusieurs fois entre chaque affichage...

Si je limite le rendu physique plus bas genre 40 Fps c'est trop limite et les mouvements d'objets ne parraissent pas assez fluide donc 65 Fps me parrait une limite tout à fait raisonnable.Tu en pense quoi ?

A la rigueur, il est possible d'appeler 2 fois le système physique (d'affilée, mais en modifiant le timestep) pour 4 trames d'affichage et de calculer le mouvement intermédiaire par interpolation.

Je vois pas trop l'intérêt d'appeler le moteur d'affichage plus souvent que le moteur physique si tu n'utilises pas de système d'interpolation de mouvement... Tu n'as pas d'animation non plus qui demanderaient "à tourner"... tout dans ton système est géré oar la physique (à part les roues qui tournent sur elle même, mais là, c'est pas ça qui gêne).

A mon avis, l'effet de sacade doit être dû au fait que le timeStep est avancé de façon irrégulière. Si le jeu tourne à 100 FPS, il affiche une image toutes les 0,01s donc entre chaque image il suffit de faire avancer le temps d'une unité (un step). Si le jeu ralenti à 10 FPS et qu'il ne calcule plus qu'une image toutes les 0.1s, il faudra par contre faire avancer le temps de 10 steps entre deux images. Est-ce bien ainsi que tu gères l'avancée du temps ? D'après ton premier message, il est fixe, mais c'est pas possible car il faudrait alors avoir un nombre de FPS fixe aussi ! Je crois que leproblème vient de là et pas d'un problème lié au thread.

Quand je parle de synchroniser physique et affichage, je ne veux pas dire les appeler en même temps ou le même nombre de fois, je veux dire : gérer le timestep du monde physique de façon dynamique en fonction du nombre de FPS.