Skip to main content
Partiellement déconseillé. La technique de corrélation des images décrite dans cet article repose sur XGameStreamingGetAssociatedFrame et XGameStreamingGetLastFrameDisplayed, qui sont déconseillé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 demeure disponible. Consultez Mesure de la latence en diffusion de jeux en continu pour connaître les techniques tenant compte de la latence qui ne dépendent pas de la corrélation des images.
Utilisez cette rubrique pour déterminer la compensation de la latence de votre titre lorsqu’il est joué au moyen de XBOX Game Streaming. Les jeux vidéo peuvent avoir une gestion des entrées sensible au temps pour les actions rapides. Imaginez un jeu de plateforme où le personnage de l’utilisateur se trouve sur un tapis roulant qui mène à une falaise, comme l’illustre la figure 1. L’utilisateur doit sauter au bon moment : trop tôt, il rate la plateforme suivante; trop tard, il tombe avant de sauter. En raison de la latence réseau de la diffusion de jeux en continu, 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 services XBOX. Lorsque le jeu reçoit finalement l’appui sur le bouton par le réseau, il peut enregistrer une chute, même si l’utilisateur a appuyé sur le bouton sur la bonne image vidéo de son point de vue. Figure 1. Exemple d’un 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 comme 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 adéquate est de savoir jusqu’où remonter dans le passé. Les API de 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 retourne une moyenne récente de la latence ajoutée par la diffusion en continu. Cette moyenne est divisée en latence d’entrée et en latence de sortie. La latence d’entrée est le temps nécessaire pour qu’une entrée de l’utilisateur soit reçue par le serveur, et la latence de sortie est le temps nécessaire pour qu’une image 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 image à l’autre, de sorte que cette approche est imprécise. De plus, les mesures de latence ajoutée par la diffusion n’incluent pas les portions de latence non liées à la diffusion, comme le temps que prend le jeu pour exécuter les simulations et effectuer le rendu.

​
Jetons d’image avec entrée

L’API XGameStreamingGetAssociatedFrame aide à 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 image, 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 l’image est terminée, le jeu appelle PresentX avec le jeton. PresentX garantit que le jeton est automatiquement envoyé au client de diffusion de jeux en continu, avec l’image vidéo correspondante. Les entrées envoyées au serveur sont accompagnées du jeton de l’image actuellement affichée sur le client. Lorsque le jeu reçoit un IGameInputReading, vous pouvez le passer à l’API XGameStreamingGetAssociatedFrame pour récupérer le jeton. Vous pouvez l’utiliser pour retrouver 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 qu’il maintient simplement un bouton enfoncé), il n’y aura pas de nouveau jeton.

​
Jetons d’image 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 à l’intérieur de ces fenêtres de temps. Idéalement, un utilisateur en diffusion en continu aura exactement autant de temps pour réagir qu’un utilisateur qui ne diffuse pas en continu. 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 les 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 retourne le D3D12XBOX_FRAME_PIPELINE_TOKEN de l’image que le client de diffusion en continu a affichée le plus récemment. Comme elle est constamment mise à jour, vous pouvez l’appeler à tout moment pour vérifier si l’utilisateur a vu la fin d’une animation.
Il est possible d’utiliser XGameStreamingGetLastFrameDisplayed de la même façon que XGameStreamingGetAssociatedFrame. Nous vous recommandons d’utiliser XGameStreamingGetAssociatedFrame lors du traitement des entrées, car elle retourne le jeton qui était à l’écran au moment où cette entrée s’est produite. Si plus de temps s’est écoulé, XGameStreamingGetLastFrameDisplayed pourrait retourner un jeton provenant d’une image plus récente.

​
Autres scénarios

Il est possible de compenser la latence dans divers scénarios en utilisant les trois API de la section précédente. Les sections suivantes fournissent d’autres exemples fondés sur des techniques courantes de compensation de la latence multiutilisateur.

​
Mouvement

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

​
Mouvement avec conséquences discrètes

Lorsque des utilisateurs entrent en collision ou visent et tirent, le jeu doit prendre une décision observable par l’utilisateur quant au 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 à l’image où la décision était requise. Pour une situation comme une collision ou une chute d’une falaise, le jeu pourrait devoir animer quelque chose pendant l’attente. Par exemple, un utilisateur pourrait 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 accumulé importe davantage que ce qui se produit sur une image 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 l’image sur laquelle il a fourni l’entrée. Par exemple, si les coordonnées d’un bâton analogique sont à 0,5, qu’elles ont progressé en moyenne de 0,1 par image et que le jeton de latence date de 3 images, le jeu pourrait les traiter comme si elles étaient à 0,8. Bien sûr, 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 un tampon d’états prédits précédemment. Lorsque l’entrée réelle de 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 mentionné ci-dessus, le jeu doit attendre de connaître les entrées réelles avant de déclencher des conséquences. Avec des connexions à latence plus élevée, cela pourrait entraîner des « sauts » visibles, et le jeu pourrait vouloir fournir un lissage ou un autre moyen de masquer l’erreur de prédiction. Avec cette stratégie, l’image rendue prend plus de temps pour se rendre au client. Le jeu pourrait vouloir projeter encore plus loin, de la valeur de la latence de sortie moyenne, pour synchroniser la vue de l’utilisateur avec la simulation du serveur. Cela est plus susceptible d’avoir de l’importance dans les jeux multiutilisateurs où la vitesse de la simulation du serveur peut être contrôlée par un serveur multiutilisateur externe.
Prédiction propre au jeu
Plutôt que de projeter un historique d’entrées, un jeu pourrait mieux deviner ce qu’un utilisateur ferait. Cela peut aller de simples heuristiques, comme un personnage de jeu de plateforme 2D qui se déplace vers la droite, à l’apprentissage automatique fondé sur l’historique de l’utilisateur. Comme pour la projection des entrées, le jeu peut conserver un 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 pourraient 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 un doigt en mouvement avec un retard. Comme mentionné dans la section Mouvement général de cette rubrique, un jeu pourrait prédire la direction et la vitesse des entrées tactiles en mouvement pour garder un curseur généralement sous le doigt en mouvement.

​
Multiutilisateur

Un avantage des jeux multiutilisateurs 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 multiutilisateur du jeu se trouve aussi dans cette région Azure, la latence entre les consoles XBOX et le serveur multiutilisateur est inférieure à une milliseconde. Toutefois, les appareils clients des utilisateurs sont plus éloignés. Les jeux multiutilisateurs ont généralement des stratégies pour gérer la latence entre le jeu et le serveur multiutilisateur. Elles font souvent appel à un horodatage ou à un compteur d’images provenant du serveur multiutilisateur. En associant ces horodatages et compteurs aux jetons d’image, un jeu multiutilisateur peut inclure la diffusion en continu dans ses calculs de latence. Cela aide les jeux multiutilisateurs à offrir une sensation juste aux utilisateurs en diffusion en continu, tout en uniformisant les règles du jeu entre les utilisateurs qui diffusent en continu et ceux qui ne le font pas.

​
Documentation de référence de l’API

​
Voir aussi

Vue d’ensemble de la compensation de la latence en diffusion de jeux en continu Mesure de la latence en diffusion de jeux en continu Simulation de la latence lors des tests de votre jeu XGameStreaming (contenu de l’API)
Last modified on October 6, 2026