1) Ben disons que si tu veux utiliser le mutex pour empêcher que le calcul physique ne se fasse pendant autre chose, oui il faut l'utiliser là bas aussi. Sinon, il ne fait que protéger ton code ici entre lock et unlock contre une autre tâche ayant le même code. Ca pourrait être une autre tâche physique lancée en // mais c'est pas ton truc ici.
Je crois que dans le projet en .NET, y-a pas eu du tout de protection mutex d'après ce que j'ai lu. Il me semble pourtant que pour éviter tout parasitage entre les animations, les déplacements et les calculs physiques, il faut s'arranger pour qu'ils ne puissent pas bosser au même moment.

2) Ton attente SLEEP doit être en dehors de l'encadrement par le lock et unlock (après le unlock donc). Sinon, il bloque pour rien ! Mais le problème ne doit pas venir de là, car ton lock et unlock ne servent à rien utilisés ainsi.

3) je reste perplexe sur le fait d'utiliser un thread. Je me demande vraiment s'il n'y avait pas un problème dans le code même...

1) Ben disons que si tu veux utiliser le mutex pour empêcher que le calcul physique ne se fasse pendant autre chose, oui il faut l'utiliser là bas aussi. Sinon, il ne fait que protéger ton code ici entre lock et unlock contre une autre tâche ayant le même code. Ca pourrait être une autre tâche physique lancée en // mais c'est pas ton truc ici.
Je crois que dans le projet en .NET, y-a pas eu du tout de protection mutex d'après ce que j'ai lu. Il me semble pourtant que pour éviter tout parasitage entre les animations, les déplacements et les calculs physiques, il faut s'arranger pour qu'ils ne puissent pas bosser au même moment.

2) Ton attente SLEEP doit être en dehors de l'encadrement par le lock et unlock (après le unlock donc). Sinon, il bloque pour rien ! Mais le problème ne doit pas venir de là, car ton lock et unlock ne servent à rien utilisés ainsi.

3) je reste perplexe sur le fait d'utiliser un thread. Je me demande vraiment s'il n'y avait pas un problème dans le code même...