Skip to main content
Parcialmente preterido. A técnica de correlação de quadros descrita neste artigo depende de XGameStreamingGetAssociatedFrame e XGameStreamingGetLastFrameDisplayed, que estão preteridas a partir da versão 2604 do GDK e serão removidas em uma versão futura. A API geral de medição de latência XGameStreamingGetStreamAddedLatency continua disponível. Consulte Medição de latência no streaming de jogos para conhecer técnicas que levam a latência em conta e não dependem da correlação de quadros.
Use este tópico para determinar a compensação de latência do seu título quando ele é jogado usando o XBOX Game Streaming. Os videogames podem ter um tratamento de entrada sensível ao tempo para ações rápidas. Imagine um jogo de plataforma em que o personagem do usuário está em uma esteira rolante que leva a um penhasco, como mostrado na figura 1. O usuário precisa pular no momento certo: cedo demais e ele erra a próxima plataforma, tarde demais e ele cai antes de pular. A latência de rede no streaming de jogos significa que, quando o usuário vê o personagem no lugar certo para pular, ele pode já ter caído da ponta do ponto de vista dos XBOX services. Quando o jogo finalmente recebe o pressionamento do botão pela rede, ele pode registrar uma queda, mesmo que o usuário tenha pressionado o botão no quadro de vídeo correto do ponto de vista dele. Figura 1. Mostra um exemplo de jogo de plataforma com um personagem em uma esteira rolante. Captura de tela de um jogo de plataforma com um personagem em uma esteira rolante

Compensação de latência

Para compensar a latência em exemplos como o mostrado na figura 1, os jogos mantêm registros de seus estados anteriores. Quando o usuário pressiona o botão de pulo, o jogo procura esse ponto no jogo para determinar se o usuário pressionou o botão no momento certo do ponto de vista dele. A chave para a compensação de latência correta é saber até que ponto do passado procurar. As APIs do XBOX Game Streaming oferecem várias opções para isso.

Latência média

A abordagem mais simples, mas menos precisa, para alguns cenários é usar a latência média. A API XGameStreamingGetStreamAddedLatency retorna uma média recente da latência adicionada pelo streaming. Essa média é dividida em latência de entrada e latência de saída. A latência de entrada é o tempo que uma entrada do usuário leva para ser recebida pelo servidor, e a latência de saída é o tempo que um quadro de vídeo renderizado pelo jogo leva para ser recebido e processado pelo dispositivo cliente. Para ações baseadas em tempo, um jogo pode usar essa média como uma estimativa de quando uma ação ocorreu. No entanto, a latência de rede pode variar, até mesmo de um quadro para outro, portanto essa abordagem é imprecisa. Além disso, as medições de latência adicionada pelo stream não incluem as partes da latência que não são de streaming, como o tempo que o jogo leva para executar simulações e renderizar.

Tokens de quadro com entrada

A API XGameStreamingGetAssociatedFrame ajuda a resolver esse problema fornecendo informações precisas sobre o estado do jogo que o usuário viu quando pressionou um botão (ou alterou qualquer outra entrada). Quando um quadro começa, os jogos que usam o Microsoft Game Development Kit (GDK) chamam ID3D12Device::WaitFrameEventX e recebem um D3D12XBOX_FRAME_PIPELINE_TOKEN. Você pode usar D3D12XBOX_FRAME_PIPELINE_TOKEN como chave para salvar o estado atual para uso posterior em uma estrutura de dados de sua escolha, como um mapa de hash. Quando o quadro é concluído, o jogo chama PresentX com o token. PresentX garante que o token seja enviado automaticamente ao cliente de streaming de jogos, junto com o quadro de vídeo correspondente. A entrada enviada ao servidor é acompanhada do token do quadro exibido no momento no cliente. Quando o jogo recebe um IGameInputReading, você pode passá-lo para a API XGameStreamingGetAssociatedFrame para obter o token de volta. Você pode usá-lo para consultar o estado anterior e tratar a entrada com base nesse estado armazenado.
Se uma entrada não tiver mudado (porque o usuário não está tocando no controle ou porque está apenas mantendo um botão pressionado), não haverá um novo token.

Tokens de quadro sem entrada

Em alguns casos, você precisa saber o que o usuário viu mais recentemente, mesmo que a entrada dele não tenha mudado. Voltando ao exemplo mostrado na figura 1, quando o personagem chega ao fim da esteira rolante, ele cai. Parte do desafio e da justiça de um jogo é reagir dentro dessas janelas de tempo. Idealmente, um usuário de streaming terá exatamente o mesmo tempo para reagir que um usuário que não usa streaming. Por causa da latência, o horário final da janela deve ser deslocado para que as entradas recebidas no fim da janela sejam aceitas. Para isso, o jogo pode usar tokens de latência em que um botão não foi pressionado. Se uma leitura de entrada sem ação corresponder ao estado do fim da janela, o usuário não reagiu, e o jogo pode penalizá-lo de forma justa. A API XGameStreamingGetLastFrameDisplayed retorna o D3D12XBOX_FRAME_PIPELINE_TOKEN do quadro exibido mais recentemente pelo cliente de streaming. Como ele é atualizado constantemente, você pode chamá-la a qualquer momento e verificar se o usuário viu o fim de uma animação.
É possível usar XGameStreamingGetLastFrameDisplayed da mesma forma que XGameStreamingGetAssociatedFrame. Recomendamos usar XGameStreamingGetAssociatedFrame ao processar a entrada, porque ela retorna o token que estava na tela quando essa entrada ocorreu. Se mais tempo tiver passado, XGameStreamingGetLastFrameDisplayed poderá retornar um token de um quadro mais recente.

Mais cenários

É possível compensar a latência em diversos cenários usando as três APIs da seção anterior. As seções a seguir fornecem mais exemplos baseados em técnicas comuns de compensação de latência multiusuário.

Movimento

Mover um personagem, a câmera ou mirar pode se enquadrar em duas categorias.

Movimento com consequências discretas

Quando os usuários se movem em direção a uma colisão ou miram e atiram, o jogo precisa tomar uma decisão observável pelo usuário sobre o resultado do movimento. Nesses casos, a decisão binária normalmente é adiada até que o jogo receba uma entrada correlacionada ao quadro em que a decisão era necessária. Para algo como colidir ou cair de um penhasco, o jogo pode precisar animar algo enquanto espera. Por exemplo, um usuário pode atravessar parcialmente um objeto ou flutuar ou pular sobre um penhasco durante o tempo que o jogo leva para receber as entradas reais.

Movimento geral

Movimento geral é qualquer navegação ou mira, mas pode ser importante em casos como dirigir, em que o movimento acumulado é mais importante do que o que acontece em um determinado quadro.
Projeção de entrada
O jogo pode usar o histórico de entradas para projetá-lo adiante com base em quanto tempo passou desde que o usuário viu o quadro em que forneceu a entrada. Por exemplo, se as coordenadas de um direcional analógico estiverem em 0,5 e tiverem avançado em média 0,1 por quadro enquanto o token de latência tem 3 quadros de idade, o jogo poderá tratá-lo como se estivesse em 0,8. Claro, isso pode levar a previsões incorretas se o usuário mudar a velocidade e a direção. Para incorporar a entrada real do usuário, o jogo pode manter um buffer de estados previstos anteriormente. Quando a entrada real para esse estado aparecer, o jogo pode executar novamente sua simulação a partir desse estado com a entrada real e corrigir o estado visível. Como mencionado acima, o jogo deve esperar para disparar quaisquer consequências até que as entradas reais sejam conhecidas. Em conexões de latência mais alta, isso pode levar a “saltos” visíveis, e o jogo talvez queira fornecer suavização ou outra forma de disfarçar a previsão incorreta. Com essa estratégia, o quadro renderizado leva mais tempo para chegar ao cliente. O jogo talvez queira projetar ainda mais adiante pela latência média de saída para sincronizar a visão do usuário com a simulação do servidor. Isso tende a ser mais importante em jogos multiusuário em que a velocidade da simulação do servidor pode ser controlada por um servidor multiusuário externo.
Previsão específica do jogo
Em vez de projetar um histórico de entradas, um jogo pode ter um palpite melhor do que um usuário faria. Isso pode variar de heurísticas simples, como um personagem de jogo de plataforma 2D se movendo para a direita, até aprendizado de máquina baseado no histórico do usuário. Assim como na projeção de entrada, o jogo pode manter um buffer de previsões e executar novamente sua simulação à medida que as entradas reais chegam.

Rastreamento de toque

Jogos que usam toque nativo podem posicionar um cursor ou retículo sob o dedo do usuário. Com latência mais alta, o usuário percebe que o cursor segue atrás de um dedo em movimento. Como mencionado na seção Movimento geral deste tópico, um jogo pode prever a direção e a velocidade das entradas de toque em movimento para manter o cursor, de modo geral, sob o dedo em movimento.

Multiusuário

Uma vantagem dos jogos multiusuário executados no XBOX Game Streaming é que os servidores XBOX dos usuários provavelmente estão no mesmo datacenter do Azure. Se o servidor multiusuário do jogo também estiver nessa região do Azure, a latência entre os consoles XBOX e o servidor multiusuário será inferior a um milissegundo. No entanto, os dispositivos cliente dos usuários estão mais distantes. Jogos multiusuário normalmente têm estratégias para lidar com a latência entre o jogo e o servidor multiusuário. Muitas vezes, elas envolvem um carimbo de data/hora ou um contador de quadros do servidor multiusuário. Ao associar esses carimbos de data/hora e contadores aos tokens de quadro, um jogo multiusuário pode incluir o stream em seus cálculos de latência. Isso ajuda os jogos multiusuário a parecerem corretos para os usuários de streaming, além de nivelar as condições entre usuários de streaming e que não usam streaming.

Documentação de referência da API

Confira também

Visão geral da compensação de latência no streaming de jogos Medição de latência no streaming de jogos Simulação de latência ao testar seu jogo XGameStreaming (conteúdo da API)
Last modified on October 6, 2026