Limitação de taxa de quadros

Os motores de jogos competitivos de sucesso maioria gosta id Tech, GoldSrc, Sourcee tal permitir limitações de framerate.

Você pode jogar com 30, com 60, com 99, com 72, com 68 etc. Em suma, você pode limitar e controlar a tampa.

Fiquei me perguntando, como limite a taxa de quadros?

Não estou interessado em código, mas em teoria.

frame-rate

— joltmode
fonte

Por curiosidade, qual é o sentido disso além de liberar ciclos para outros processos?

— 3Dave

@ DavidLively, pense em laptops, esses superaquecem muito facilmente em uma taxa de quadros muito alta, enquanto com um limite de 60 qps (mais é inútil de qualquer maneira, até 60 é um pouco demais, 40 devem fazer), eles podem controlar a temperatura muito melhor.

Para jogos competitivos, é melhor ter uma taxa de quadros uniforme em vez de picos entre 60 e 100 fps, pois algumas ações dependem da taxa de quadros e não do tempo, uma taxa de quadros igual permite que você entenda essas ações. Observe que, se você ativar o VSync, seu jogo sempre terá um fps máximo igual à sua taxa de atualização porque (o driver cuida disso).

— Roy T.

gafferongames.com/game-physics/fix-your-timestep

— Prof. Falken violado

Respostas:

A teoria é: verifique quando você renderizou um quadro pela última vez e se ainda não é hora de desenhar outro quadro, não o faça e aguarde até que ele seja.

— Kylotan
fonte

Digamos que você queira limitar a taxa de quadros a 60 qps, isso significa que todo quadro tem um tempo de renderização de 1 / 60s = 16,67ms (arredondado)

Para limitar sua taxa de quadros, basta verificar o horário no início do loop do jogo, e então compará-lo com o horário no final do loop do jogo: se a diferença for menor que 16,67ms, você deve parar por esse tempo.

Uma maneira de fazer isso é usar:

sleep(waittime)

No entanto, como sleep(x)produz o encadeamento por um mínimo de xmilissegundos, você não sabe ao certo se conseguirá o controle novamente no tempo.

Uma maneira melhor seria usar:

while(timediff < 16.67ms){ sleep(0); }

Isso gera o encadeamento e solicita o controle de volta o mais rápido possível.

Outra solução é ter apenas um loop de espera ocupado, isso oferece o melhor controle, mas usa a CPU desnecessariamente.

Lembre-se de que o agendador do sistema operacional sempre pode tirar o controle do seu encadeamento, portanto, esteja preparado para alguma flutuação.

— Roy T.
fonte

"1 / 60s" para ficar claro. :)

— Richard Marskell - Drackir

Esta solução é muito ruim. Se você tiver o vsync ativado ou o sistema operacional decidir fazer alguma coisa, a taxa de quadros flutuará bastante.

— Tara

@Dudeson Por que isso é ruim? (esta é a técnica usada no Quake3 btw). Se o seu FPS for menor que 60, o loop será ignorado. Por isso, mantém o seu FPS mais alto possível, mas nunca acima de 60.

— Roy T.

@RoyT. Interessante ... De onde você tirou essa informação? Do código fonte? Além disso, estou dizendo que esperar em um loop é ruim, porque foi exatamente assim que fiz no meu mecanismo e me causa muita dor. O problema é que, quando você ativa o vsync (no driver da GPU), você obtém muitas quedas de quadros se tentar limitar a taxa de quadros no seu código, porque seu timinig não será perfeito em todos os quadros. Eu só estou falando sobre problemas vsync. Sem vsync, isso não é um problema. E não tenho certeza se o vsync foi o mesmo tipo de acordo nos três dias de terremoto que é hoje.

— Tara

@Dudeson alguém apontou isso para mim há algum tempo, porque eu estava preocupada com a espera e o sono ocupados. Vejo agora que você pode flutuar entre 30fps e 60fps quando o v-sync está ativado, se você sentir alguma falta. Mas acho que isso acontece com qualquer técnica (não é isso que o FreeSync tenta aliviar). A framerate limitado pelo código, ou porque o computador não pode tornar a 60fps sempre terá este problema eu acho :)

— Roy T.