Análisis en profundidad de la compensación de latencia en game streaming
Análisis en profundidad de la compensación de latencia en game streaming
Parcialmente en desuso. La técnica de correlación de fotogramas descrita en este artículo se basa en XGameStreamingGetAssociatedFrame y XGameStreamingGetLastFrameDisplayed, que están en desuso a partir de la versión 2604 del GDK y se quitarán en una versión futura. La API general de medición de latencia XGameStreamingGetStreamAddedLatency sigue disponible. Consulta Medición de la latencia en game streaming para conocer técnicas conscientes de la latencia que no dependen de la correlación de fotogramas.
Usa este tema para determinar la compensación de latencia de tu título cuando se juega mediante XBOX Game Streaming.Los videojuegos pueden tener un control de entrada sensible al tiempo para acciones rápidas. Imagina un juego de plataformas en el que el personaje del usuario está en una cinta transportadora en movimiento que conduce a un precipicio, como se muestra en la figura 1.El usuario debe saltar en el momento adecuado: demasiado pronto y no alcanza la siguiente plataforma, demasiado tarde y cae antes de saltar. La latencia de red en la transmisión de juegos significa que, para cuando el usuario ve a su personaje en el lugar adecuado para saltar, es posible que ya haya caído por el extremo desde la perspectiva de los servicios XBOX.Cuando el juego finalmente recibe la pulsación del botón a través de la red, podría registrar una caída, aunque el usuario haya pulsado el botón en el fotograma de vídeo correcto desde su perspectiva.Figura 1. Muestra un ejemplo de un juego de plataformas con un personaje en una cinta transportadora.
Para compensar la latencia en ejemplos como el mostrado en la figura 1, los juegos tienen registros de sus estados anteriores.Cuando el usuario pulsa el botón de salto, el juego busca ese punto en el juego para determinar si el usuario pulsó el botón en el momento adecuado desde su perspectiva.La clave para una compensación de latencia correcta es saber cuánto hay que buscar en el pasado. Las API de XBOX Game Streaming ofrecen varias opciones para ello.
El enfoque más sencillo, pero menos preciso, para algunos escenarios es usar la latencia media.La API XGameStreamingGetStreamAddedLatency devuelve un promedio reciente de la latencia que agrega la transmisión. Ese promedio se divide en latencia de entrada y latencia de salida.La latencia de entrada es el tiempo que tarda el servidor en recibir una entrada del usuario, y la latencia de salida es el tiempo que tarda el dispositivo cliente en recibir y procesar un fotograma de vídeo renderizado por el juego.Para las acciones basadas en el tiempo, un juego puede usar este promedio como una estimación de cuándo se produjo una acción. Sin embargo, la latencia de red puede variar, incluso de fotograma a fotograma, por lo que este enfoque es impreciso. Además, las mediciones de la latencia agregada por la transmisión no incluyen las partes de la latencia ajenas a la transmisión, como el tiempo que tarda el juego en ejecutar las simulaciones y renderizar.
La API XGameStreamingGetAssociatedFrame ayuda a resolver este problema proporcionando información precisa sobre el estado del juego que el usuario vio cuando pulsó un botón (o cambió cualquier otra entrada).Cuando comienza un fotograma, los juegos que usan Microsoft Game Development Kit (GDK) llaman a ID3D12Device::WaitFrameEventX y reciben un D3D12XBOX_FRAME_PIPELINE_TOKEN. Puedes usar D3D12XBOX_FRAME_PIPELINE_TOKEN como clave para guardar el estado actual y usarlo más adelante en una estructura de datos de tu elección, como un mapa hash. Cuando el fotograma se completa, el juego llama a PresentX con el token.PresentX garantiza que el token se envíe automáticamente al cliente de transmisión de juegos, junto con el fotograma de vídeo correspondiente.La entrada que se envía al servidor va acompañada del token del fotograma que se muestra actualmente en el cliente. Cuando el juego recibe un IGameInputReading, puedes pasarlo a la API XGameStreamingGetAssociatedFrame para recuperar el token. Puedes usarlo para buscar el estado anterior y controlar la entrada basándote en ese estado almacenado.
Si una entrada no ha cambiado (porque el usuario no está tocando el mando o porque simplemente mantiene pulsado un botón), no habrá un token nuevo.
En algunos casos, debes saber qué es lo último que ha visto el usuario, aunque su entrada no haya cambiado. Volviendo al ejemplo de la figura 1, cuando el personaje llega al final de la cinta transportadora, cae. Parte del desafío y la equidad de un juego consiste en reaccionar dentro de esas ventanas de tiempo.Idealmente, un usuario que transmite tendrá exactamente el mismo tiempo para reaccionar que un usuario que no transmite. Debido a la latencia, el momento final de la ventana debería desplazarse de modo que se acepten las entradas recibidas al final de la ventana.Para ello, el juego puede usar tokens de latencia en los que no se pulsó un botón. Si una lectura de entrada sin acción coincide con el estado del final de la ventana, el usuario no reaccionó a tiempo y el juego puede penalizarlo de forma justa.La API XGameStreamingGetLastFrameDisplayed devuelve el D3D12XBOX_FRAME_PIPELINE_TOKEN del fotograma que el cliente de transmisión mostró más recientemente. Como se actualiza constantemente, puedes llamarla en cualquier momento y ver si el usuario ha visto el final de una animación.
Es posible usar XGameStreamingGetLastFrameDisplayed de la misma manera que XGameStreamingGetAssociatedFrame. Te recomendamos que uses XGameStreamingGetAssociatedFrame al procesar la entrada porque devuelve el token que estaba en pantalla cuando se produjo esa entrada. Si ha pasado más tiempo, XGameStreamingGetLastFrameDisplayed podría devolver un token de un fotograma más reciente.
Es posible compensar la latencia en una variedad de escenarios usando las tres API de la sección anterior. Las secciones siguientes proporcionan más ejemplos basados en técnicas comunes de compensación de latencia multiusuario.
Cuando los usuarios se mueven hacia una colisión o apuntan y disparan, el juego debe tomar una decisión observable por el usuario sobre el resultado del movimiento.Para estos casos, la decisión binaria normalmente se retrasa hasta que el juego haya recibido una entrada correlacionada con el fotograma en el que se necesitaba la decisión. Para algo como una colisión o una caída por un precipicio, es posible que el juego tenga que animar algo mientras espera.Por ejemplo, un usuario podría atravesar un objeto, o flotar o saltar sobre un precipicio durante el tiempo que tarda el juego en recibir las entradas reales.
El movimiento general es cualquier navegación o apuntado, pero puede ser importante en casos como la conducción, donde el movimiento acumulado es más importante que lo que ocurre en un fotograma concreto.
Proyección de la entrada
El juego puede usar el historial de entradas para proyectarlo hacia adelante en función del tiempo que ha pasado desde que el usuario vio el fotograma en el que proporcionó la entrada. Por ejemplo, si las coordenadas de un stick están en 0.5 y han progresado una media de 0.1 por fotograma mientras el token de latencia tiene 3 fotogramas de antigüedad, el juego podría tratarlo como si estuviera en 0.8.Por supuesto, esto puede llevar a predicciones erróneas si el usuario cambia de velocidad y dirección. Para incorporar la entrada real del usuario, el juego puede mantener un búfer de estados previamente predichos. Cuando aparece la entrada real de ese estado, el juego puede volver a ejecutar su simulación desde ese estado con la entrada real y corregir el estado visible.Como se mencionó anteriormente, el juego debe esperar a activar cualquier consecuencia hasta que se conozcan las entradas reales. En conexiones con mayor latencia, esto podría provocar «saltos» visibles y es posible que el juego quiera aplicar suavizado u otro tipo de cobertura para la predicción errónea.Con esta estrategia, el fotograma renderizado tarda más tiempo en llegar al cliente. Es posible que el juego quiera proyectar aún más, en función de la latencia de salida media, para sincronizar la vista del usuario con la simulación del servidor. Es más probable que esto importe en juegos multiusuario donde la velocidad de la simulación del servidor puede estar controlada por un servidor multiusuario externo.
Predicción específica del juego
En lugar de proyectar un historial de entradas, un juego podría tener una mejor estimación de lo que haría un usuario. Esto podría ir desde heurísticas simples, como que el personaje de un juego de plataformas 2D se mueva hacia la derecha, hasta aprendizaje automático basado en el historial del usuario. Al igual que con la proyección de la entrada, el juego puede mantener un búfer de predicciones y volver a ejecutar su simulación a medida que llegan las entradas reales.
Los juegos que usan entrada táctil nativa pueden colocar un cursor o una retícula bajo el dedo del usuario. Con una latencia mayor, el usuario nota que el cursor va por detrás de un dedo en movimiento. Como se menciona en la sección Movimiento general de este tema, un juego podría predecir la dirección y la velocidad de las entradas táctiles en movimiento para mantener el cursor, en general, bajo el dedo en movimiento.
Una ventaja de los juegos multiusuario que se ejecutan en XBOX Game Streaming es que los servidores XBOX de los usuarios probablemente estén en el mismo centro de datos de Azure. Si el servidor multiusuario del juego también está en esa región de Azure, la latencia entre las consolas XBOX y el servidor multiusuario es inferior a un milisegundo. Sin embargo, los dispositivos cliente de los usuarios están más lejos.Los juegos multiusuario normalmente tienen estrategias para gestionar la latencia entre el juego y el servidor multiusuario. A menudo, estas implican una marca de tiempo o un contador de fotogramas del servidor multiusuario.Al asociar esas marcas de tiempo y contadores con tokens de fotograma, un juego multiusuario puede incluir la transmisión en sus cálculos de latencia. Esto ayuda a que los juegos multiusuario se sientan correctos para los usuarios que transmiten, así como a igualar las condiciones entre los usuarios que transmiten y los que no.
