Quando 30 fps são diferentes de 30 fps.

O aqui referido aplica-se a qualquer outra cadência de fotogramas.

Quando referimos que uma máquina está a correr um jogo a uns determinados fotogramas, isso quer dizer que outra máquina a correr o mesmo jogo na mesma cadência de fotogramas oferece uma experiência de jogo igual?

Na realidade não! E há muitos fatores que podem alterar a perceção da fluidez do jogo!

Factor 1: O framepacing

Este fator é o principal de todos, aplicando-se a todos os sistemas.

Basicamente o framepacing é o espaçamento entre fotogramas, e este convém ser o mais perfeito possível.

Imaginemos então que estamos a trabalhar a 30 ou a 60 fotogramas por segundo. Isso quer dizer que a cadência média de cada fotograma é de 33.3ms ou 16.6 ms . Mas no entanto nem todos os fotogramas são entregues na mesma medida.

Vamos ver cinco exemplos diferentes, mas num caso simplificado. Vamos supor apenas 3 fotogramas, sendo que para 30 só teriam de multiplicar a coisa por 10, e para 60 por 20. Mas para efeitos de explicação a coisa torna-se mais simples.

Assim, a 3 fotogramas por segundo teríamos cada uma média para cada um de 333,3 milisegundos

Exemplo 1:

Primeiro fotograma: 500 ms
Segundo forograma: 200 ms
Terceiro fotograma: 300 ms

Exemplo 2:

Primeiro fotograma: 333.3 ms
Segundo fotograma: 333.3 ms
Terceiro Fotograma: 333.3 ms

Exemplo 3:

Primeiro Fotograma: 250 ms
Segundo Fotograma: 200 ms
Terceiro Fotograma: 350 ms

Exemplo 4:

Primeiro fotograma: 500 ms
Segundo forograma: 300 ms
Terceiro fotograma: 300 ms

Exemplo 5:

Primeiro fotograma: 333.3 ms
Segundo fotograma: 333.3 ms
Terceiro Fotograma: 350 ms

Como podem perceber, estamos perante situações bem diferentes:

 

Nos primeiros 2 casos temos o GPU a apresentar fotogramas exatos dentro do tempo que precisamos. E ambos estariam a apresentar 3 fotogramas por segundo (ou 30 ou 60 num exemplo com mais fotogramas)

No terceiro caso o GPU apresenta os fotogramas muito mais cedo, e nos dois casos seguintes os fotogramas não são entregues todos dento do tempo previsto.

Basicamente o que temos aqui é que os 3 primeiros casos estão a ocorrer em GPUs que se mostraram devidamente capazes de apresentar uma cadencia de 3 fps, e nos dois últimos, dois GPUs que não o conseguiram fazer.

Qual o caso pior e melhor?

O caso pior aqui é o caso 4. Não só há uma enorme disparidade no tempo de entrega dos fotogramas, como o não ter sido cumprido o tempo requerido implica que os 3 fps por segundo não foram conseguidos, e no primeiro segundo apenas se mostraram 2. Esta situação de fotogramas a serem entregues em tempos bastante dispares cria o efeito de “stutter”, e uma clara perceção de falta de fluidez nos controlos que, no presente caso, houve uma quebra na cadencia de fotogramas.

O segundo caso pior é o caso 1. Mesmo cumprindo com os tempos requeridos, temos todos os fotogramas a serem entregues igualmente com enormes disparidades temporais. Tal vai criar os mesmos efeitos do caso anterior, mas desta vez cumprindo com os 3 fps solicitados.

O caso 5 é um caso em que os fotogramas estavam todos a cair com intervalos regulares, com um deles a, subitamente, a ultrapassar ligeiramente o orçamento. Apesar de nesta segundo os 3 fps não terem sido entregues, este caso é basicamente o mais comum e normal de acontecer, desde que esta situação não ocorra sempre, mas seja pontual. Não é a perfeição, mas essa é realmente complicada de ser atingida.

Caso perfeito é o 2, em que o GPU está a entregar todos os fps de forma perfeita e devidamente afastados em tempos iguais.

O caso 3 é um caso especial. Aqui o GPU tem claramente capacidade para criar mais de 30 fps. No entanto não o está a fazer de forma regular. Para apresentar apenas 3 fps, este GPU terá de sofrer uma limitação superior aos fps (Vsync).

Apesar de o caso 3 não ser o mais perfeito é o que por norma melhor nos garante um frame pacing regular. É por esse motivo que os jogos nas consolas, especialmente os de 30 fps, por norma são criados para correrem a mais fps, sendo depois limitados superiormente. E dessa forma, nestas situações o que temos é que o caso 3 e o caso 2 se confundem. Ou seja, quando analisamos o gráfico dos fotogramas obtidos, o que vemos é que o caso 3 se comporta como o 2. Ou seja, para garantirmos um caso relativamente perfeito como o 2, precisamos de margem de manobra para contemplar toda e qualquer situação.

Isso quer dizer que há diferença entre um sistema que seja capaz de fornecer apenas os fps requeridos, mesmo que de forma regular, e um sistema que esteja a fornecer algo mais, limitado superiormente. É que somente o único pode garantir os fps desejados em todos os casos, e assim, situações em que explosões ou outras encham o ecrã de efeitos adicionais que reduzam a performance gráfica, apenas o caso 3, com limitação superior de fps, consegue garantir que a cadencia é relativamente bem mantida.

O gráfico que se segue mostra uma sequencia de 50 fotogramas em que a ideia é possuir-se uma cadencia de 60 fps, ou seja, 16.6 ms. Mas em dois casos bem diferentes.

No jogo a azul (teórico) todos os fotogramas estão a ser entregues na cadencia de 16.6 ms. Ou seja, estamos perante o caso 2 de cima. Já o outro jogo, a laranja, que tambem tem uma cadencia média de 60 fps apresenta os tempos por frame extremamente variáveis, ora acima dos 16.6, ora abaixo dos 16.6., ou seja, longe do ideal.

E naturalmente que a experiência de jogo dos dois será claramente diferente!

Esta é uma situação que varia num mesmo jogo com a diversidade de hardware. Cada hardware tem um comportamento diferente e como tal torna-se impossível optimizar para todos. Eis um exemplo de diferenças de frametimes num mesmo jogo com diferentes GPUs.

O que implica é que o hardware único, tal como acontece nas consolas, seja o ideal para se poder optimizar o frame time.

Será igualmente de se referir que o API, e a forma como ele consegue aproveitar o hardware é tambem muito relevante. O gráfico que se segue mostra o frametime num mesmo jogo (Rocket League) usando o DX 11 (laranja) e o DX 12 (Verde).

Percebendo-se assim que quando mais o API for ao metal, e quanto mais optimizado for ao hardware em causa, melhores resultados apresenta. Dando neste aspecto tambem alguma vantagem às consolas.

Ora como se percebe do caso real acima colocado, o caso anterior, a azul, e ideal, que é caso 2, é extremamente teórico. E o mais comum e normal é termos o caso 5 anteriormente referido, onde temos regularmente alguns fotogramas fora do passo ideal. Mas se estes fotogramas oscilarem pouco em torno do patamar ideal então entramos num caso real onde as variações existem introduzindo pequenas quebras de fps e pequenos “stutterings”. Mas desde que com oscilações por norma pequenas em torno do valor pretendido, e com uma média de fps a ser obtida dentro do desejado, temos um jogo fluido. Ou seja, num caso prático o que temos é que um GPU não se prende efetivamente a nenhum dos casos, mas idealmente corre misturando o caso 5 com o caso 3, ou seja com os fotogramas a caírem, ora acima, ora abaixo dos tempos ideais, mas sempre relativamente perto dos valores ideais, e sem as descrepancias dos outros casos..

É para estes casos que o VRR é idealmente pensado e não para os casos de “frametimes” constantemente irregulares. Um VRR aplicado ao caso a laranja do gráfico de cima resolveria muito do problema, mas a inconsistência de fotogramas seria sempre percetível, especialmente nos controles. Já quando as variações são mais reduzidas, e não fogem tanto do valor padrão a ser atingido como no gráfico a azul da GTX 690 de cima, um VRR faz verdadeiramente milagres, eliminando todo o “stuttering” que sentimos.

E isto leva-nos ao ponto 2.

Fator 2: Os sistemas de input

Um dos grandes problemas dos ratos gaming e teclados gaming, com elevados “pooling rates” é que estes respondem de tal forma rápida que quando um fotograma se atrasa a ser representado, tal se torna imediatamente percetível.

Nesse aspecto os controladores usados nas consolas contribuem muito para que os jogos sejam sentidos como mais fluidos, uma vez que possuem latências mais altas que disfarçam eventuais atrasos nos fotogramas, e permitem, por este motivo, sentir-se uma aparente maior fluidez quando se joga com cadencias de fps mais baixas.

Esta é meramente uma questão de perceção, algo que apesar de tudo se revela muito relevante para o nosso cérebro. Da mesma forma que se alguém se deslocar a 5 Km/h a pé, tem a ideia que vai a andar depressa, mas se o fizer de carro, tem a perceção que está basicamente parado.