Este problema de retraso vs capacidad de respuesta es la situación con prácticamente todos los controladores de movimiento, ya sea algo como Hydra, Wii Remote, Kinect o PlayStation Move.
El problema es este:
Cuando ingresa una secuencia de entrada, está tomando una decisión cuadro por cuadro sobre si confiar o no en los datos de entrada; si las tendencias que estás viendo ahora continuarán en los datos que recibas en una docena de milisegundos a partir de ahora. Por ejemplo, si hay un cambio repentino a la derecha de este marco, no sabe si se trata de un bit de datos de entrada real (y, por lo tanto, debe actuar sobre él) o si es simplemente jitter (y por lo tanto debe ignorarlo). Independientemente de lo que elija, si luego descubre que estaba equivocado, ha permitido que la fluctuación de entrada entre en su juego (en el primer caso) o que haya introducido retraso en su juego (en el último caso).
No hay una buena solución para esto. Una solución "correcta" para determinar si la entrada es real o inestable requiere saber qué hará el flujo de entrada en el futuro, así como lo que hizo en el pasado. No podemos hacer eso en los juegos, por razones obvias. Entonces, no, no hay forma de filtrar los datos de rotación para eliminar la fluctuación sin perder precisión, en el contexto de un juego que está trabajando con datos de entrada en tiempo real.
He visto a un fabricante importante recomendar que los desarrolladores aborden este problema haciendo que los jugadores mantengan presionado un botón mientras giran el control, para que el juego pueda desactivar su código anti-jitter en ese punto, por lo que no es lento. (No recomiendo esto, pero es un enfoque).
He visto algunas bibliotecas de middleware de entrada de movimiento que tratan este problema mediante la introducción de un retraso artificial en la entrada: hay un búfer de cuarto de segundo en el que entran los datos de entrada, y tu juego solo escucha sobre la entrada un cuarto de segundo después, para que la biblioteca pueda suavizar el jitter por ti, sabiendo lo que sucede tanto antes como después del "presente" desde el punto de vista del juego. Eso funciona muy bien, aparte de introducir un cuarto de segundo de retraso en todo. Pero es una forma de resolver el problema, y puede hacer un trabajo increíble al representar con precisión un movimiento sin la fluctuación de fase, a expensas del retraso constante.
Pero sin llegar a ese extremo, todavía hay algunas cosas que podemos hacer para mejorar enormemente el comportamiento, aunque sabemos que siempre habrá "peores escenarios" que se comporten de manera no ideal.
La idea central es que solo nos preocupamos por el jitter cuando el controlador está mayormente estacionario, y solo nos importa el retraso cuando el controlador se está moviendo. Por lo tanto, nuestra estrategia debería ser tratar de lidiar con las cosas de modo que tengamos un retraso cuando el controlador esté estacionario, y tengamos nerviosismo cuando el controlador esté en movimiento.
Aquí hay dos formas posibles de hacerlo:
Un enfoque común es un sistema "bloqueado / desbloqueado", en el que realiza un seguimiento de la orientación del dispositivo, y si no cambia por un corto tiempo (medio segundo más o menos), 'bloquea' esa orientación, sin tomar acción basada en la orientación informada del dispositivo hasta que difiera lo suficiente como para 'desbloquear' nuevamente. Esto puede silenciar completamente el jitter basado en la orientación, sin introducir retraso cuando la orientación está cambiando activamente. Puede haber un indicio de retraso antes de que el código decida que necesita cambiar al modo "desbloqueado", pero será mucho mejor que tener un retraso en todas partes.
Otro enfoque es promediar juntos los datos de entrada de los marcos. El punto importante aquí es promediar solo los datos de entrada de los fotogramas donde los datos de entrada fueron vagamente similares: esto significa que las pequeñas fluctuaciones se desenfocarán y suavizarán, pero los cambios más grandes no se desenfocan, porque sus datos no son suficientemente similar a los datos de cuadros anteriores.
Hay otras formas de obtener un efecto similar también. La idea central es que no puedes tener tanto jitter como no lag en tu juego en tiempo real al mismo tiempo, porque hacerlo requeriría conocimiento del futuro. Por lo tanto, debe elegir cuándo sesgar el comportamiento de su control para aceptar el jitter y cuándo sesgarlo para aceptar el retraso, para que la experiencia general sea lo más mala posible.