Ce problème de décalage par rapport à la réactivité est la situation avec pratiquement tous les contrôleurs de mouvement, que ce soit l'Hydra, la télécommande Wii, le Kinect ou le PlayStation Move.
Le problème est le suivant:
Lorsqu'un flux d'entrée arrive, vous décidez trame par trame de faire confiance ou non aux données d'entrée; si les tendances que vous voyez maintenant se sont poursuivies dans les données, vous recevez une douzaine de millisecondes à partir de maintenant. Par exemple, s'il y a un décalage soudain vers la droite de ce cadre, vous ne savez pas s'il s'agit d'un vrai bit de données d'entrée (et vous devez donc agir dessus) ou s'il s'agit simplement d'une gigue (et vous devez donc l'ignorer). Quel que soit votre choix, si vous découvrez plus tard que vous vous êtes trompé, vous avez soit autorisé la gigue d'entrée à entrer dans votre jeu (dans le premier cas), soit introduit un retard dans votre jeu (dans le dernier cas).
Il n'y a pas de bonne solution à cela. Une solution "correcte" pour déterminer si l'entrée est réelle ou instable nécessite de savoir ce que le flux d'entrée va faire à l'avenir, ainsi que ce qu'il a fait dans le passé. Nous ne pouvons pas faire cela dans les jeux, pour des raisons évidentes. Donc non, il n'y a aucun moyen de filtrer les données de rotation pour supprimer la gigue sans perdre en précision, dans le contexte d'un jeu qui travaille avec des données d'entrée en temps réel.
J'ai vu un grand fabricant recommander aux développeurs de résoudre ce problème en demandant aux joueurs de maintenir un bouton enfoncé tout en faisant tourner le contrôle, afin que le jeu puisse désactiver son code anti-gigue à ce stade, il n'est donc pas décalé. (Je ne recommande pas cela, mais c'est une approche).
J'ai vu quelques bibliothèques de middleware d'entrée de mouvement qui traitent ce problème en introduisant un retard artificiel dans l'entrée - il y a un tampon d'un quart de seconde dans lequel les données d'entrée entrent, et votre jeu n'entend parler de l'entrée qu'un quart de seconde plus tard, afin que la bibliothèque puisse atténuer la gigue pour vous, en sachant ce qui se passe avant et après le "présent" du point de vue du jeu. Cela fonctionne très bien, à part introduire un quart de seconde de retard sur tout. Mais c'est une façon de résoudre le problème, et il peut faire un travail impressionnant de représenter avec précision un mouvement sans gigue, au détriment d'un décalage constant.
Mais sans aller à cet extrême, il y a encore des choses que nous pouvons faire pour améliorer considérablement le comportement, même si nous savons qu'il y aura toujours des «pires scénarios» qui se comporteront de manière non idéale.
L'idée principale est que nous ne nous soucions vraiment de la gigue que lorsque le contrôleur est principalement stationnaire, et nous ne nous soucions vraiment du décalage que lorsque le contrôleur est déplacé. Donc, notre stratégie devrait être d'essayer de gérer les choses de manière à ce que nous ayons du décalage lorsque le contrôleur est à l'arrêt et de la gigue lorsque le contrôleur est en mouvement.
Voici deux façons possibles de le faire:
Une approche courante est un système "verrouillé / déverrouillé", dans lequel vous gardez une trace de l'orientation de l'appareil, et s'il ne change pas pendant un court instant (une demi-seconde environ), vous "verrouillez" cette orientation, sans action basée sur l'orientation rapportée de l'appareil jusqu'à ce qu'elle diffère suffisamment pour se «déverrouiller» à nouveau. Cela peut complètement atténuer la gigue basée sur l'orientation, sans introduire de décalage lorsque l'orientation change activement. Il peut y avoir un soupçon de décalage avant que le code décide qu'il doit passer en mode "déverrouillé", mais ce sera beaucoup mieux que d'avoir du décalage partout.
Une autre approche consiste à faire la moyenne des données d'entrée des trames. Le point important ici est de ne faire la moyenne qu'ensemble des données d'entrée des images où les données d'entrée étaient vaguement similaires - Cela signifiait que les petits tremblements se brouillaient et s'adoucissaient, mais les changements plus importants ne se brouillaient pas, car leurs données n'étaient pas assez similaire aux données des trames précédentes.
Il existe également d'autres façons d'obtenir un effet similaire. L'idée de base est que vous ne pouvez pas avoir à la fois sans gigue et sans décalage dans votre jeu en temps réel, car cela nécessiterait une connaissance de l'avenir. Vous devez donc choisir quand biaiser le comportement de votre contrôle vers l'acceptation de la gigue et quand le biaiser vers l'acceptation du décalage, afin de rendre l'expérience globale la plus mauvaise possible.