¿Cuál es la forma habitual de controlar la velocidad de fotogramas?

Question

Soy nuevo en los gráficos, así que no sé cómo las personas suelen controlar la velocidad de fotogramas para renderizar las cosas. Quiero decir, ¿cómo puedes configurar tu aplicación para que se muestre a, por ejemplo, 30 fps? Probablemente hay muchas API que ofrecen tal cosa, pero necesito codificarla desde cero.

Answer 1

Existen dos formas "habituales" de "controlar" la velocidad de fotogramas, y ninguna de las dos es tan simple.

El primero y más controlador de los dos, y algo que suele ser opcional, es VSync. Esto fuerza a la tarjeta de video a solo sacar un nuevo cuadro cuando el monitor se haya actualizado. Muchos monitores se actualizan a 60 Hz, por lo que tiende a obtener 60 FPS.

Esto funciona bastante bien para cap framerate para controlar la frecuencia de actualización, pero cuando la tasa de fotogramas cae por debajo de la actualización, se fuerza al siguiente múltiplo. Por lo tanto, como la tasa de fotogramas comienza a bajar un poco, se pierde un poco de potencial de tiempo de presentación, ya que está obligado a 60, luego 30, luego 20, etc.

(un poco de información sobre VSYNC en DirectX y OpenGL)

El segundo método, comúnmente utilizado (con vsync opcionalmente agregado) no es limitar la velocidad de cuadros. En su lugar, ajuste su código para manejar las diferencias. Esto es mucho más flexible a largo plazo y, en general, mejor codificación, IMO, y mucho más simple que tratar de forzar un recuento de FPS en particular.

Asumiendo que tiene un simple bucle de render, comienza a buscar algo como:

while (gameloop) 
{ 
    float framedelta = (timeNow - timeLast) 
    timeLast = timeNow; 

    for each (GameObject object in World) 
    { 
     object->Animate(framedelta); 
     object->Move(speed * framedelta) 
    } 

    render(); 
} 

Usted quiere mirar la diferencia de tiempo/tiempo pasó/delta, y trabajar desde allí. Permita que la velocidad de fotogramas escale en función del hardware y la configuración (hay demasiadas variaciones para que pueda predecir o manejar incluso la mitad), y haga que su juego funcione con eso en lugar de controlarlo. Mucho más fácil para ti y más flexible y estable en la práctica.

Answer 2

La forma típica de obtener predecibles (si no constantes) la velocidad de cuadros (con gráficos de video o 3D) se describe en el siguiente pseudo-código.

Algoritmo

1. Preparar la siguiente trama (render en back-buffer);
2. Dormir durante el resto de la porción de tiempo;
3. Pregunte al marco que se mostrará (intercambie los búferes anterior y posterior).

Tenga en cuenta la posición de la operación de reposo. Está intercalado entre la preparación y la visualización del mismo marco. ¡Esta es la clave principal para una velocidad de fotogramas constante! Desea que la preparación del marco cuente en el intervalo de tiempo total para mostrar el marco.

Hay varias variantes sobre cómo implementar cada uno de estos pasos (elección de la operación de suspensión en función de su resolución, fiabilidad, etc.), pero el núcleo está ahí.

Consejos para una fiabilidad adicional

• no invocan su función de reposo una vez durante todo el intervalo. Defina alguna constante con el error máximo que está listo para aceptar y duerma repetidamente durante períodos de este intervalo hasta que el tiempo restante sea menor o igual a esta cantidad.
• No tenga miedo de caer ocasionalmente un marco cuando sabe que no podrá preparar el siguiente marco a tiempo. Visualmente es más atractivo omitir un marco que producir una velocidad de cuadro variable.
• Si puede evitar los subprocesos de fondo en un sistema de un solo procesador, evítelos. Usar hilos de trabajo realmente arruinará la confiabilidad de su función de dormir. El mejor enfoque es dividir el trabajo en segundo plano en trozos pequeños y hacer que este trabajo se ejecute en lugar de dormir.

La primera es fácil de implementar y se puede ocultar en una función de ayuda. El segundo es un poco más sensible, ya que requiere que mantenga estadísticas de la velocidad promedio de reproducción, entre otras cosas. El tercero es difícil de implementar ya que a menudo es difícil predecir cuánto tiempo tomarán las diferentes tareas. Normalmente solo se implementa en sistemas en tiempo real con restricciones difíciles.