Fijo vs.velocidades de fotogramas variables en juegos:¿Qué es mejor y cuándo?

Question

Después de trabajar durante un tiempo desarrollando juegos, he estado expuesto tanto a velocidades de fotogramas variables (donde calculas cuánto tiempo ha pasado desde el último tick y actualizas el movimiento del actor en consecuencia) como a velocidades de fotogramas fijas (donde calculas cuánto tiempo ha pasado y elige marcar una cantidad de tiempo fija o dormir hasta que llegue la siguiente ventana).

¿Qué método funciona mejor para situaciones específicas?Por favor considera:

• Atendiendo a diferentes especificaciones del sistema;
• Facilidad de desarrollo/mantenimiento;
• Facilidad de portabilidad;
• Actuación final.

Answer 1

Parece que la mayoría de los desarrolladores 3D prefieren FPS variables:Los motores Quake, Doom y Unreal aumentan y disminuyen según el rendimiento del sistema.

• Como mínimo tienes que compensar las velocidades de cuadro demasiado rápidas (a diferencia de los juegos de los 80 que se ejecutan en los 90, que son demasiado rápidos)
• Su bucle principal debe estar parametrizado por el paso de tiempo de todos modos, y siempre que no sea demasiado largo, un integrador decente como RK4 debería manejar la física sin problemas. Algunos tipos de animación (sprites con fotogramas clave) podrían ser difíciles de parametrizar.El código de red también deberá ser inteligente, para evitar que los jugadores con máquinas más rápidas disparen demasiadas balas, por ejemplo, pero este tipo de limitación deberá realizarse de todos modos para compensar la latencia (la parametrización de la animación también ayudaría a ocultar el retraso de la red).
• Será necesario modificar el código de sincronización para cada plataforma, pero es un pequeño cambio localizado (aunque algunos sistemas dificultan la sincronización extremadamente precisa, Windows, Mac, Linux parecen estar bien)
• Las velocidades de fotogramas variables permiten el máximo rendimiento.Las velocidades de fotogramas fijas permiten un rendimiento constante, pero nunca alcanzarán el máximo en todos los sistemas (eso parece ser un obstáculo para cualquier juego serio)

Si estás escribiendo un juego 3D en red donde el rendimiento importa, tendría que decir: muerde la bala e implementa velocidades de fotogramas variables.

Si se trata de un juego de rompecabezas en 2D, probablemente puedas salirte con la tuya con una velocidad de fotogramas fija, tal vez ligeramente parametrizada para computadoras súper lentas y modelos del próximo año.

Answer 2

Me inclino por un modelo de velocidad de fotogramas variable, pero internamente algunos sistemas funcionan en un intervalo de tiempo fijo.Esto es bastante fácil de hacer usando un acumulador de tiempo.La física es un sistema que se ejecuta mejor en un intervalo de tiempo fijo y se marca varias veces por cuadro si es necesario para evitar una pérdida de estabilidad y mantener la simulación fluida.

Un poco de código para demostrar el uso de un acumulador:

const float STEP = 60.f / 1000.f;
float accumulator = 0.f;

void Update(float delta)
{
    accumulator += delta;

    while(accumulator > STEP)
    {
        Simulate(STEP);
        accumulator -= STEP;
    }
}

Esto no es perfecto de ninguna manera, pero presenta la idea básica: hay muchas maneras de mejorar este modelo.Obviamente, hay problemas que resolver cuando la velocidad de fotogramas de entrada es obscenamente lenta.Sin embargo, la gran ventaja es que no importa qué tan rápido o lento sea el delta, la simulación se mueve a un ritmo suave en el "tiempo del jugador", que es donde el usuario percibirá cualquier problema.

Generalmente no me meto en el lado de los gráficos y el audio, pero no creo que se vean afectados tanto como la física, la entrada y el código de red.

Answer 3

Una opción que a mí, como usuario, me gustaría ver más a menudo es cambiar dinámicamente el nivel de detalle (en el sentido amplio, no sólo en el sentido técnico) cuando las velocidades de fotogramas varían fuera de un límite determinado.Si está renderizando a 5 FPS, desactive el mapeo de relieve.Si está renderizando a 90 FPS, aumente un poco los detalles y brinde al usuario algunas imágenes más bonitas para desperdiciar su CPU y GPU.

Si se hace correctamente, el usuario debería obtener la mejor experiencia del juego sin tener que ir a la pantalla de configuración y modificarse, y usted debería preocuparse menos, como diseñador de niveles, por mantener el mismo número de polígonos en las diferentes escenas. .

Por supuesto, digo esto como usuario de juegos, y no como usuario serio: nunca he intentado escribir un juego que no sea trivial.

Answer 4

El principal problema que he encontrado con los tiempos de fotogramas de longitud variable es la precisión del punto flotante, y los tiempos de fotogramas variables pueden sorprenderte por cómo te muerden.

Si, por ejemplo, estás sumando el tiempo de fotograma * velocidad a una posición, y el tiempo de fotograma se vuelve muy pequeño y la posición es más grande, tus objetos pueden ralentizarse o dejar de moverse porque todo tu delta se perdió debido a la precisión.Puede compensar esto utilizando un acumulador de errores independiente, pero es una molestia.

Tener tiempos de fotograma fijos (o al menos un límite inferior en la longitud del fotograma) le permite controlar cuánto error de FP debe tener en cuenta.

Answer 5

Mi experiencia se limita bastante a juegos algo simples (desarrollados con SDL y C++), pero he descubierto que es bastante fácil implementar una velocidad de fotogramas estática.¿Estás trabajando con juegos 2d o 3d?Supongo que los entornos 3D más complejos se beneficiarían más de una velocidad de fotogramas variable y que la dificultad sería mayor.