iwannabear (./1769) :
non mais justement c'est pas de temps de reaction que je parle, pas dans le sens "tu reagis a un stimuli", mais de timing. tu peux tres bien mettre 0.1 secondes a reagir a un stimuli, mais c'est pas pour autant que t'aura une granularite de 0.1 secondes pour declencher un evenement 0.85 secondes precisement apres le dit stimuli. tu vois ce que je veux dire? ou declencher deux evenements tres proches l'un de l'autre (genre cliquer sur le bouton droit et gauche quasi-simultanement, a un intervalle extremement proche, style 0.02 secondes) ce n'est pas une question de vitesse de reaction a un evenement externe.

Ah ok, la vitesse d'enchaînement des actions ? Compris chef

http://www.humanbenchmark.com/tests/reactiontime/stats.php

(Quelle surprise, j'ai un temps de réaction de merde )

bon pour le coup de wow, je vois pas trop comment un fixed timestep changerait quoi que ce soit (et surtout, il y a tres fortement moyen que le serveur tourne deja en fixed timestep, a un framerate extremement bas, genre 20 fps) du point de vue du serveur

En fait le serveur n'a même rien à voir là dedans (énormément de trucs sont gérés côté client… le serveur ne vérifie même pas grand chose à ce que le client lui envoie…).
Disons que normalement, après avoir "téléporté" magiquement le personnage super bas par un calcul d'intervalle de temps très long, la moindre des choses serait de le remonter.
Si j'interprète bien ce que je vois, leur algorithme est à peu près "si joueur_py < niveau de l'eau alors joueur_vy = 0 et joueur_ay = 0" mais testé après le test de si le joueur est en dessous du décor. En fixed timestep tu ne peux jamais déplacer le joueur de plus de N unités, donc même cette implémentation simpliste ne peut jamais beaucoup t'éloigner de la surface de l'eau, contrairement à ce qui se passe en réalité
(Bon tu pourrais malgré tout quand même mourir dans les flaques d'eau mais ça je crois que c'est un peu normal )