Quais são os benefícios de limitar quadros por segundo? (Caso existam)

Estou trabalhando em um jogo simples no OpenGL, usando SDL para inicialização e entrada de vídeo, e parece que em termos de tempo, tenho duas opções disponíveis para mim. O número um está apenas dormindo no idealTimePerFrame - theTimeTakenToRender, quando o idealTimePerFrame em segundos = 1 / theFramerateCap. (Não tenho certeza se isso é necessário, pois é equivalente ao uso do vsync, o que pode ser mais preciso. Se minha suposição estiver correta, diga-me se o SDL + OpenGL tem ou não o vsync por padrão e se não para habilitá-lo.) O outro é medir o tempo desde que o último quadro foi renderizado e apenas ajustar o movimento de acordo. (Quanto menor o tempo gasto para renderizar um quadro, menos entidades distantes se movem nesse quadro). Em termos de desempenho, diminuição da oscilação, etc., quais são as vantagens e desvantagens desses dois métodos?

Se o tempo de seu quadro for imprevisível (seja sua culpa ou não; o sistema operacional pode estar usando recursos ocasionalmente etc.), limitar a uma taxa de quadros previsível um pouco menor do que a taxa de quadros alcançável fará muito pela latência previsível , o que pode faça o jogo parecer muito melhor.

Alterar o tempo entre o processamento e a execução de alterações relacionadas a essa entrada pode parecer ruim - mesmo que, em média, você esteja obtendo menos latência entre as duas, o "tremor" pode ser percebido pelos seres humanos (consciente ou inconscientemente).

Veja a apresentação do Microsoft GameFest O que há em um quadro: lacrimejamento, latência e taxa de quadros para obter algumas dicas aqui. Carmack também tem uma série de postagens úteis no blog .

Lembre-se também de que algumas contas podem ser quebradas quando você executa quadros usando deltaTvalores baixos - ou mesmo quando você usa variáveis deltaT(as coisas podem se tornar mais difíceis ou até difíceis de serem executadas de maneira "estável" e previsível, o que é importante para as coisas como replays e algumas formas de sincronização de rede). Consulte Corrija seu Timestep para obter algumas dicas aqui.

Você acabará usando muito menos CPU (multitarefas agradecerão) e as pessoas em dispositivos móveis também apreciarão isso.

Você nunca, jamais, jamais, jamais, jamais usará o Sleep para controlar a taxa de quadros .

Isso já foi discutido antes discutido e remeterei para a outra pergunta para discussão dos motivos. Uma coisa que não foi mencionada é que, na taxa de atualização moderna típica de 60Hz e com a granularidade típica de 1 milissegundo das chamadas de suspensão, é realmente impossível dormir durante a quantidade correta de tempo entre os quadros.

Eu estou não dizendo que produzindo CPU, se você não tem nada a ver é uma coisa ruim; longe disso. Mas não é a mesma coisa que controlar o framerate e o Sleep é uma solução apropriada para o primeiro, mas não para o último.

Em vez disso, verifique o tempo decorrido e, se estiver na hora de executar um quadro, faça-o, caso contrário - e se você quiser produzir uma CPU - Durma pelo mínimo de tempo necessário - 1 milissegundo. Além disso, verifique se o temporizador está configurado adequadamente para sua plataforma, a fim de fornecer uma boa resolução; ou seja, ao emitir a chamada "Sleep (1)", você realmente tem a chance de realmente dormir por 1 milissegundo, em vez de algo como 15, 20 ou 30 (o que seria o caso). Acredito que o SDL fará isso automaticamente para você.

Você também pode criar alguma folga para que, se estiver chegando a hora de executar um quadro, pare de Dormir e comece a correr até a moldura funcionar, o que pode ajudá-lo a atingir o intervalo de quadros desejado com mais precisão.

O que isso acaba parecendo é um monte de chamadas Sleep (1) intercaladas com um quadro ocasional, e tudo bem. Você ainda está desistindo da CPU quando não precisa, mas seus quadros ainda poderão ser executados no prazo.

Provavelmente, o benefício mais importante da limitação da taxa de quadros é que ela pode ajudar a evitar danos físicos literais à máquina. Eles se esqueceram de fazer isso no Starcraft II, o que acabou sendo muito problemático (e caro) para alguns usuários até que eles o corrigissem.

Como mencionado anteriormente, reduz o uso da CPU. Por outro lado, e cada vez mais importante, isso também consome a vida da bateria. Como um bom exemplo, o FTL roda quase 100% da CPU no meu MBA. Como resultado, ele descarrega a bateria em> 2 horas e fica muito quente. (Como resultado mais direto, eu desinstalei e não o reproduzi mais ...). Um boné de armação teria evitado isso.

Outra vantagem não mencionada é que, se for um jogo multiplayer, você também nivelará o campo, dando a todos a mesma experiência.