¿Cuáles son los beneficios de los marcos de límite por segundo? (Si alguna)

Estoy trabajando en un juego simple en OpenGL, usando SDL para la inicialización y entrada de la pantalla, y parece que en términos de tiempo tengo dos opciones disponibles. El número uno solo está durmiendo para el óptimoTimePerFrame - theTimeTakenToRender, cuando el óptimoTimePerFrame en segundos = 1 / theFramerateCap. (No estoy completamente seguro de si esto es necesario, ya que es equivalente a usar vsync, que puede ser más preciso. Si mi suposición es correcta, dígame si SDL + OpenGL tiene vsync por defecto, y si no es así para habilitarlo.) El otro es medir el tiempo transcurrido desde que se renderizó el último fotograma y simplemente ajustar el movimiento en consecuencia. (El tiempo más corto que se tarda en representar un cuadro, las entidades menos lejanas se mueven en ese cuadro). En términos de rendimiento y disminución del parpadeo, etc., ¿cuáles son las ventajas y desventajas de estos dos métodos?

Si su tiempo de fotogramas es impredecible (ya sea que sea su culpa o no; el sistema operativo puede estar utilizando recursos ocasionalmente, etc.), limitar a una velocidad de fotogramas predecible que sea algo menor que su velocidad de fotogramas alcanzable hará mucho para una latencia predecible , que puede haz que el juego se sienta mucho mejor.

Cambiar el tiempo que transcurre entre el momento en que procesa la entrada y procesa los cambios relacionados con esa entrada puede sentirse mal, incluso si, en promedio, está logrando una menor latencia entre los dos, el "jitter" puede ser notable para los humanos (consciente o inconscientemente).

Vea la presentación de Microsoft GameFest What's In a Frame: Tearing, Latency, and Frame Rate para obtener más información aquí. Carmack también tiene una serie de publicaciones de blog que son útiles en esto.

También tenga en cuenta que algunas matemáticas pueden descomponerse cuando ejecuta marcos utilizando deltaTvalores bajos , o incluso cuando utiliza variables deltaT(las cosas pueden volverse más difíciles o incluso imposibles de hacer de una manera "estable" y predecible, lo cual es importante para las cosas como repeticiones y algunas formas de sincronización de red). Vea Fix Your Timestep para obtener una idea aquí.

Terminará usando mucho menos CPU (las multitareas se lo agradecerán) y las personas en dispositivos móviles también lo apreciarán.

Nunca, nunca, nunca, nunca, nunca, use Sleep para controlar la velocidad de fotogramas .

Esto ya se ha solucionado anteriormente y lo remitiré a la otra pregunta para analizar los motivos. Una cosa que no se menciona allí es que a la frecuencia de actualización moderna típica de 60Hz, y con la granularidad típica de 1 milisegundo de las llamadas de suspensión, en realidad es imposible dormir durante el tiempo correcto entre cuadros.

Estoy no diciendo que ceder la CPU si no tienes nada que hacer es una cosa mala; lejos de ahi. Pero no es lo mismo que controlar el framerate y Sleep es una solución apropiada para el primero pero no para el segundo.

En su lugar, verifique el tiempo transcurrido, y si es el momento de ejecutar un marco, hágalo, de lo contrario, y si desea obtener algo de CPU, duerma por el mínimo de tiempo: 1 milisegundo. También asegúrese de que su temporizador de apagado esté configurado de manera adecuada para su plataforma a fin de brindarle una buena resolución; es decir, cuando emite esa llamada "Sleep (1)", realmente tiene la posibilidad de dormir realmente durante 1 milisegundo, en lugar de algo así como 15, 20 o 30 (que de lo contrario sería el caso). Creo que SDL hará esto automáticamente por usted.

También puede acumular un poco de holgura en él, de modo que si se está acercando el momento de ejecutar un marco, deje de dormir y comience a correr completamente hasta que el marco se ejecute, lo que puede ayudarlo a alcanzar el intervalo de marco deseado con mayor precisión.

Lo que esto termina pareciendo es un montón de llamadas Sleep (1) intercaladas con el marco ocasional, y eso está bien. Todavía está renunciando a la CPU cuando no la necesita, pero sus marcos aún podrán ejecutarse a tiempo.

Probablemente, el beneficio más importante de limitar la velocidad de fotogramas es que puede ayudar a prevenir daños físicos literales a la máquina. Se olvidaron de hacer esto en Starcraft II, que resultó ser muy problemático (y costoso) para algunos usuarios hasta que lo repararon.

Como se mencionó anteriormente, reduce el uso de la CPU. Por otro lado, y cada vez más importante, eso también agota la duración de la batería. Como buen ejemplo, FTL se ejecuta en casi el 100% de la CPU en mi MBA. Como resultado, agota la batería en> 2 horas y funciona muy caliente. (Como resultado más directo, lo desinstalé y ya no lo juego ...). Una tapa de marco habría evitado esto.

Otra ventaja no mencionada es que, si se trata de un juego multijugador, también nivelas el campo de juego al dar a todos la misma experiencia.