FPS grande vs FPS consistente

Al optimizar la velocidad de fotogramas de un juego, ¿cuándo debería enfocarme en un FPS grande y cuándo debería enfocarme en una velocidad de fotogramas consistente?

Esto es a menudo un tema muy discutido, así que tenga en cuenta que no estoy preguntando cuál es mejor.

¿Cuáles son los pros y los contras de cada uno?
¿En qué situaciones se prefiere uno sobre el otro?

También tenga en cuenta: mis tasas de entrada de sondeo / procesamiento, física y actualización del juego son independientes de mi tasa de cuadros. Lo único que afecta el FPS es la frecuencia con la que se representa una pantalla.

Esto es subjetivo, por supuesto, pero creo que la consistencia es mucho más importante para el juego que la velocidad.

Básicamente, los jugadores soportarán una velocidad de fotogramas más lenta si el juego es consistente, divertido de jugar y no irritante. Sin embargo, incluso si el juego es genial, si le da a la gente dolores de cabeza a la vista porque explota y / o no pueden controlar las cosas, se molestarán y dejarán de jugar.

Entonces...

Concéntrese en FPS consistentes en todo el diseño y desarrollo.

Concéntrese en FPS más rápidos (pero aún consistentes) cuando el juego esté casi terminado, y tenga tiempo para mejorar el rendimiento sin preocuparse por las correcciones de errores, etc.

Una forma de obtener un mejor rendimiento es usar devoluciones de llamada / delegados / interrupciones (dependiendo de su idioma / plataforma) en lugar de encuestas.

Lo que debes hacer:

• Bloquee la lógica del juego a un framerate fijo
• Renderice gráficos lo más rápido posible

De esa manera, si la velocidad de fotogramas cae, no obtienes retraso de entrada (te estoy mirando, Just Cause 2), y si la velocidad de fotogramas se vuelve demasiado alta (piensa en juegos de los años 90), el juego no se puede jugar.

Así es como lo hago:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

Básicamente, reúne una "pila" de marcos para hacer lógica y puede interpolar entre ellos perfectamente.

Parece que tiene al menos dos hilos de ejecución, con su renderizado en su propio hilo. Si ese es el caso, entonces tienes dos velocidades de cuadro de las que preocuparte. Querrás que ambos sean lo más rápido posible. Sin embargo, también depende del tipo de juego que estés construyendo.

¿Estás construyendo un juego de disparos en primera persona, donde pequeñas caídas en la velocidad de fotogramas podrían darle una ventaja a un oponente? Si es así, querrás asegurarte de que tus fps promedio sean lo suficientemente altos, pero también preocuparte por los peores tiempos de cuadro. ¿Estás construyendo un juego de mesa? Si es así, el aumento ocasional del tiempo de fotogramas no va a matar la experiencia del usuario.

En mis propios juegos, mi proceso suele ser algo como esto:

• Ejecuta un perfilador en el código
• Mira la tasa de cuadros promedio. Si es demasiado bajo en promedio, aumente el promedio de fps optimizando las cosas lentas.
• Una vez que el fps promedio es lo suficientemente alto, busque los tiempos de cuadro del peor de los casos (cuadros en los que ve grandes picos en el tiempo de procesamiento o de procesamiento). Intente optimizar esos escenarios en el peor de los casos para mejorar el tiempo de trama en el peor de los casos.

Si está a 30 fps la mayor parte del tiempo, pero sube a 200 ms cada 10 segundos, eso causará problemas. Pero si tiene un promedio de 15 fps, primero suba su promedio de fps.

Por lo tanto, la respuesta corta probablemente sería: optimizar lo que sea que haga la mayor mejora a la experiencia del usuario primero.

Bloquear su FPS a un número constante le permite:

• Mantener una apariencia visual suave
• Mantenga las animaciones ejecutándose en tiempo lineal, los objetos físicos que caen a una velocidad constante entre fotogramas, etc.
• Sin embargo, la parte más útil de bloquear su FPS es que en los marcos donde tiene un poco de tiempo de inactividad puede hacer otro trabajo: recolectar basura, trabajar en la transmisión en la siguiente área del mapa, etc. y tendrá algo de margen de maniobra al renderizar algo grande y brillante o al tirar una pila de cajas.

Ambos. Yo diría que idealmente, consistentemente más de 60 cuadros por segundo. Siendo realistas, consistentemente más de 30 cuadros por segundo. Menos de 30 fotogramas por segundo y comienza a afectar qué tan bien puede desempeñarse el jugador (por cierto, estoy pensando en los juegos basados ​​en FPS / contracción, los juegos de estrategia probablemente pueden funcionar en niveles más bajos).

Si realmente tuvieras que decir uno u otro, iría con consistencia. Si puede garantizar una velocidad de fotogramas, puede concentrarse en mover esa velocidad de fotogramas garantizada más alto.

Más grande siempre es mejor, pero:

La velocidad de fotogramas inconsistente puede provocar mareo por movimiento.

(Tuvimos un probador interno que vomitó cuando su velocidad de fotogramas aumentó entre 20 y 60 durante 10 segundos).

Creo que querrías un FPS consistente y más grande. Cuanto más suaves sean los gráficos (debido a la frecuencia de actualización), mejor. Si comienza a caer por debajo de 30FPS, sus usuarios comenzarán a notar la inquietud y se sentirán frustrados por la falta de tiempo de respuesta a las acciones.

Si desea evitar el desgarro , debe usar V-sync que bloqueará el FPS a la frecuencia de actualización del monitor, o más bajo (si va más alto, no será visible, por lo que sería un desperdicio).

Solo hay una respuesta, y esa es ... siempre sube a lo alto durante el desarrollo y cuando bajes hasta el pico más bajo, esto hará que el juego fluya constantemente. Estoy sentado en el código, y permanecerá allí porque es mi forma secreta de codificar el dragón. / Eyhe