Limitación de framerate

Los motores de juego competitivas exitosas gusta más id Tech, GoldSrc, Sourcey como permiten las limitaciones de imágenes por segundo.

Puedes jugar con 30, con 60, con 99, con 72, con 68, etc. En resumen, puedes limitarlo y controlarlo.

Me preguntaba, ¿cómo limito la velocidad de fotogramas?

No le interesa el código, sino la teoría.

frame-rate

— sacudida
fuente

Solo por curiosidad, ¿qué sentido tiene esto aparte de liberar ciclos para otros procesos?

— 3Dave

@DavidLively, piense en las computadoras portátiles, que se sobrecalientan muy fácilmente a una velocidad de cuadro muy alta, mientras que con un límite de 60 fps (más de todos modos es inútil, incluso 60 es un poco, 40 deberían hacerlo) pueden controlar la temperatura mucho mejor.

Para juegos competitivos, es mejor tener una velocidad de fotogramas uniforme en lugar de picos entre 60 y 100 fps, ya que a veces algunas acciones dependen de la velocidad de fotogramas y no del tiempo, una velocidad de fotogramas igual le permite tener una idea de estas acciones. Por cierto, tenga en cuenta que si habilita VSync, su juego siempre tendrá un máximo de fps igual a su frecuencia de actualización porque (el controlador se encarga de esto).

— Roy T.

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

— contrato del Prof. Falken incumplió el

Respuestas:

La teoría es: comprueba cuándo has renderizado un cuadro por última vez, y si aún no es el momento de dibujar otro cuadro, no lo hagas, y espera hasta que lo sea.

— Kylotan
fuente

Supongamos que desea limitar su velocidad de cuadros a 60 fps, eso significa que cada cuadro tiene un tiempo de renderizado de 1 / 60s = 16,67ms (redondeado)

Para limitar su velocidad de cuadros, simplemente verifique el tiempo al comienzo de su ciclo de juego, luego puede compararlo con el tiempo al final del ciclo de juego: si la diferencia es inferior a 16.67 ms, debe detenerse durante ese tiempo.

Una forma de hacer esto es usar:

sleep(waittime)

Sin embargo, dado que sleep(x)produce el hilo durante un mínimo de xmilisegundos, no sabe con certeza si recuperará el control en el tiempo.

Una mejor manera sería usar:

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

Esto produce el subproceso y solicita el control lo antes posible.

Otra solución es tener un bucle de espera ocupado, esto le brinda el mejor control pero usa la CPU innecesariamente.

Recuerde que el programador del sistema operativo siempre puede quitarle el control a su hilo, así que prepárese para alguna fluctuación.

— Roy T.
fuente

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

— Richard Marskell - Drackir

Esta solución es realmente mala. Si tiene vsync habilitado o el sistema operativo decide hacer cosas, su velocidad de cuadros fluctuará mucho.

— Tara

@ Dudeson ¿Por qué es malo? (Esta es la técnica utilizada en Quake3 por cierto). Si su FPS es inferior a 60, se saltará el bucle. Por lo tanto, mantiene su FPS lo más alto posible pero nunca por encima de 60.

— Roy T.

@RoyT. Interesante ... ¿De dónde sacaste esa información? Del código fuente? Además, digo que esperar en un bucle es malo porque así es exactamente como lo hice en mi motor y me causa mucho dolor. El problema es que cuando enciende vsync (en el controlador de la GPU) obtiene muchas caídas de cuadros si además intenta limitar la velocidad de cuadros en su código, porque su tiempo no será perfecto en cada cuadro. Solo estoy hablando de problemas de vsync. Sin vsync esto no es un problema. Y no estoy seguro si vsync fue el mismo tipo de trato en los 3 días de Quake como lo es hoy.

— Tara

@Dudeson, alguien más me lo señaló hace algún tiempo porque estaba preocupado por la ocupada espera y el sueño. Ahora veo que puede fluctuar entre 30 fps y 60 fps cuando v-sync está activado si lo pierde un poco. Pero supongo que eso sucede con cualquier técnica (¿no es esto lo que FreeSync intenta aliviar?) Una velocidad de fotogramas limitada por código, o porque su computadora no puede procesar a 60 fps siempre tendrá este problema, creo :)

— Roy T.