Skip to main content
Partiellement déprécié. La technique de corrélation des frames décrite dans cet article s’appuie sur XGameStreamingGetAssociatedFrame et XGameStreamingGetLastFrameDisplayed, qui sont dépréciées depuis la version 2604 du GDK et seront supprimées dans une version ultérieure. L’API générale de mesure de la latence XGameStreamingGetStreamAddedLatency reste disponible. Consultez Mesure de la latence du streaming de jeux pour découvrir des techniques tenant compte de la latence qui ne dépendent pas de la corrélation des frames.
Utilisez cette rubrique pour déterminer la compensation de la latence de votre titre lorsqu’il est joué via XBOX Game Streaming. Les jeux vidéo peuvent comporter une gestion des entrées sensible au temps pour les actions rapides. Imaginez un jeu de plateforme dans lequel le personnage de l’utilisateur se trouve sur un tapis roulant qui mène à une falaise, comme illustré à la figure 1. L’utilisateur doit sauter au bon moment : trop tôt, il manque la plateforme suivante ; trop tard, il tombe avant de sauter. En raison de la latence réseau du streaming de jeux, au moment où l’utilisateur voit son personnage au bon endroit pour sauter, celui-ci est peut-être déjà tombé du bout du tapis du point de vue des XBOX services. Lorsque le jeu reçoit finalement l’appui sur le bouton via le réseau, il peut enregistrer une chute, même si l’utilisateur a appuyé sur le bouton sur la bonne frame vidéo de son point de vue. Figure 1. Exemple de jeu de plateforme avec un personnage sur un tapis roulant. Capture d'écran d'un jeu de plateforme avec un personnage sur un tapis roulant

​
Compensation de la latence

Pour compenser la latence dans des exemples tels que celui de la figure 1, les jeux conservent un historique de leurs états précédents. Lorsque l’utilisateur appuie sur le bouton de saut, le jeu recherche ce moment dans le jeu pour déterminer si l’utilisateur a appuyé sur le bouton au bon moment de son point de vue. La clé d’une compensation de la latence correcte consiste à savoir jusqu’où remonter dans le passé. Les API XBOX Game Streaming offrent plusieurs options à cet effet.

​
Latence moyenne

L’approche la plus simple, mais la moins précise dans certains scénarios, consiste à utiliser la latence moyenne. L’API XGameStreamingGetStreamAddedLatency renvoie une moyenne récente de la latence ajoutée par le streaming. Cette moyenne est divisée en latence d’entrée et latence de sortie. La latence d’entrée correspond au temps nécessaire pour qu’une entrée utilisateur soit reçue par le serveur, et la latence de sortie correspond au temps nécessaire pour qu’une frame vidéo rendue par le jeu soit reçue et traitée par l’appareil client. Pour les actions basées sur le temps, un jeu peut utiliser cette moyenne comme estimation du moment où une action s’est produite. Toutefois, la latence réseau peut varier, même d’une frame à l’autre, de sorte que cette approche est imprécise. En outre, les mesures de latence ajoutée par le streaming n’incluent pas les parties de la latence non liées au streaming, comme le temps nécessaire au jeu pour exécuter les simulations et effectuer le rendu.

​
Jetons de frame avec entrée

L’API XGameStreamingGetAssociatedFrame permet de résoudre ce problème en fournissant des informations précises sur l’état du jeu que l’utilisateur voyait lorsqu’il a appuyé sur un bouton (ou modifié toute autre entrée). Au début d’une frame, les jeux qui utilisent le Microsoft Game Development Kit (GDK) appellent ID3D12Device::WaitFrameEventX et reçoivent un D3D12XBOX_FRAME_PIPELINE_TOKEN. Vous pouvez utiliser D3D12XBOX_FRAME_PIPELINE_TOKEN comme clé pour enregistrer l’état actuel en vue d’une utilisation ultérieure dans la structure de données de votre choix, comme une table de hachage. Lorsque la frame est terminée, le jeu appelle PresentX avec le jeton. PresentX garantit que le jeton est automatiquement envoyé au client de streaming de jeux, avec la frame vidéo correspondante. Les entrées envoyées au serveur sont accompagnées du jeton de la frame actuellement affichée sur le client. Lorsque le jeu reçoit un IGameInputReading, vous pouvez le transmettre à l’API XGameStreamingGetAssociatedFrame pour récupérer le jeton. Vous pouvez l’utiliser pour rechercher l’état précédent et traiter l’entrée en fonction de cet état enregistré.
Si une entrée n’a pas changé (parce que l’utilisateur ne touche pas la manette ou parce qu’il maintient simplement un bouton enfoncé), il n’y aura pas de nouveau jeton.

​
Jetons de frame sans entrée

Dans certains cas, vous devez savoir ce que l’utilisateur a vu le plus récemment, même si son entrée n’a pas changé. Pour revenir à l’exemple de la figure 1, lorsque le personnage atteint le bout du tapis roulant, il tombe. Une partie du défi et de l’équité d’un jeu consiste à réagir dans ces fenêtres de temps. Idéalement, un utilisateur en streaming disposera exactement du même temps pour réagir qu’un utilisateur qui ne joue pas en streaming. En raison de la latence, l’heure de fin de la fenêtre doit être décalée afin que les entrées reçues à la fin de la fenêtre soient acceptées. Pour ce faire, le jeu peut utiliser des jetons de latence lorsqu’aucun bouton n’a été enfoncé. Si une lecture d’entrée sans action correspond à l’état de la fin de la fenêtre, l’utilisateur n’a pas réagi et le jeu peut le pénaliser équitablement. L’API XGameStreamingGetLastFrameDisplayed renvoie le D3D12XBOX_FRAME_PIPELINE_TOKEN de la frame que le client de streaming a affichée le plus récemment. Comme il est constamment mis à jour, vous pouvez l’appeler à tout moment et vérifier si l’utilisateur a vu la fin d’une animation.
Il est possible d’utiliser XGameStreamingGetLastFrameDisplayed de la même manière que XGameStreamingGetAssociatedFrame. Nous vous recommandons d’utiliser XGameStreamingGetAssociatedFrame lors du traitement des entrées, car elle renvoie le jeton qui était à l’écran au moment où cette entrée s’est produite. Si davantage de temps s’est écoulé, XGameStreamingGetLastFrameDisplayed peut renvoyer un jeton provenant d’une frame plus récente.

​
Autres scénarios

Il est possible de compenser la latence dans divers scénarios à l’aide des trois API de la section précédente. Les sections suivantes fournissent d’autres exemples basés sur des techniques courantes de compensation de la latence multi-utilisateur.

​
Mouvement

Le déplacement d’un personnage, de la caméra ou la visée peuvent se classer en deux catégories.

​
Mouvement avec conséquences discrètes

Lorsque les utilisateurs entrent en collision ou visent et tirent, le jeu doit prendre une décision observable par l’utilisateur sur le résultat du mouvement. Dans ces cas, la décision binaire est généralement retardée jusqu’à ce que le jeu ait reçu une entrée corrélée à la frame où la décision était nécessaire. Pour une collision ou une chute d’une falaise, le jeu peut avoir besoin d’animer quelque chose pendant l’attente. Par exemple, un utilisateur peut traverser partiellement un objet, ou flotter ou sauter au-dessus d’une falaise pendant le temps nécessaire au jeu pour recevoir les entrées réelles.

​
Mouvement général

Le mouvement général correspond à toute navigation ou visée, mais il peut être important dans des cas comme la conduite, où le mouvement cumulé importe davantage que ce qui se passe sur une frame donnée.
Projection des entrées
Le jeu peut utiliser l’historique des entrées pour les projeter vers l’avant en fonction du temps écoulé depuis que l’utilisateur a vu la frame sur laquelle il a fourni l’entrée. Par exemple, si les coordonnées d’un stick analogique sont à 0,5 et qu’elles ont progressé en moyenne de 0,1 par frame alors que le jeton de latence date de 3 frames, le jeu peut considérer qu’il se trouve à 0,8. Bien entendu, cela peut entraîner des erreurs de prédiction si l’utilisateur change de vitesse et de direction. Pour intégrer l’entrée réelle de l’utilisateur, le jeu peut conserver une mémoire tampon des états prédits précédemment. Lorsque l’entrée réelle correspondant à cet état arrive, le jeu peut réexécuter sa simulation à partir de cet état avec l’entrée réelle et corriger l’état visible. Comme indiqué ci-dessus, le jeu doit attendre de connaître les entrées réelles avant de déclencher des conséquences. Sur des connexions à latence plus élevée, cela peut entraîner des « sauts » visibles, et le jeu peut vouloir fournir un lissage ou un autre moyen de masquer l’erreur de prédiction. Avec cette stratégie, la frame rendue met plus de temps à parvenir au client. Le jeu peut vouloir projeter encore plus loin, de la valeur de la latence de sortie moyenne, afin de synchroniser la vue de l’utilisateur avec la simulation du serveur. Cela est plus susceptible d’avoir de l’importance dans les jeux multi-utilisateurs où la vitesse de la simulation du serveur peut être contrôlée par un serveur multi-utilisateur externe.
Prédiction propre au jeu
Plutôt que de projeter un historique d’entrées, un jeu peut avoir une meilleure idée de ce que ferait un utilisateur. Cela peut aller d’heuristiques simples, comme un personnage de jeu de plateforme 2D qui se déplace vers la droite, à de l’apprentissage automatique basé sur l’historique de l’utilisateur. Comme pour la projection des entrées, le jeu peut conserver une mémoire tampon de prédictions et réexécuter sa simulation à mesure que les entrées réelles arrivent.

​
Suivi tactile

Les jeux qui utilisent l’entrée tactile native peuvent placer un curseur ou un réticule sous le doigt de l’utilisateur. Avec une latence plus élevée, l’utilisateur remarque que le curseur suit avec retard un doigt en mouvement. Comme indiqué dans la section Mouvement général de cette rubrique, un jeu peut prédire la direction et la vitesse des entrées tactiles en mouvement pour maintenir un curseur globalement sous le doigt en mouvement.

​
Multi-utilisateur

L’un des avantages des jeux multi-utilisateurs exécutés sur XBOX Game Streaming est que les serveurs XBOX des utilisateurs se trouvent probablement dans le même centre de données Azure. Si le serveur multi-utilisateur du jeu se trouve également dans cette région Azure, la latence entre les consoles XBOX et le serveur multi-utilisateur est inférieure à une milliseconde. Toutefois, les appareils clients des utilisateurs sont plus éloignés. Les jeux multi-utilisateurs disposent généralement de stratégies pour gérer la latence entre le jeu et le serveur multi-utilisateur. Celles-ci impliquent souvent un horodatage ou un compteur de frames provenant du serveur multi-utilisateur. En associant ces horodatages et compteurs aux jetons de frame, un jeu multi-utilisateur peut inclure le stream dans ses calculs de latence. Cela permet aux jeux multi-utilisateurs d’offrir une sensation naturelle aux utilisateurs en streaming et de rééquilibrer les chances entre les utilisateurs en streaming et les autres.

​
Documentation de référence des API

​
Voir aussi

Vue d’ensemble de la compensation de la latence du streaming de jeux Mesure de la latence du streaming de jeux Simulation de la latence lors du test de votre jeu XGameStreaming (contenu des API)
Last modified on October 6, 2026