Actualmente estoy escribiendo un juego usando C ++ y SDL2 y hay una cosa que me pregunto: ¿tiene sentido limitar mis cuadros por segundo (FPS) y / o mis actualizaciones por segundo (UPS)?
Tengo la idea de que si limitas el UPS, esencialmente controlas la velocidad del juego: si el jugador mueve 1px por actualización y siempre lo actualizas 30 veces por segundo, se moverá a una velocidad de 30px / sy tú Probablemente también alivie la CPU ya que la cantidad de cálculos por segundo disminuye. Si limita el FPS, la cantidad de llamadas por segundo disminuye, por lo tanto, alivia su GPU. Espero haber entendido todo eso correctamente, si no, no dudes en corregirme.
Mi pregunta es: ¿qué se supone que limite en mi juego? FPS? ¿UPS? ¿Ambos? ¿Ninguno? ¿Hay otro enfoque mejor para esto? ¿Cómo se hace esto en la mayoría de los juegos y por qué?
¡Las respuestas son muy apreciadas!
Respuestas:
Sí, tiene sentido.
Como dijiste, hará menos carga en el sistema, lo que es bueno para las térmicas y otras aplicaciones.
Sin embargo ... La lógica de tus juegos NO debería depender de las actualizaciones por segundo. Por lo tanto, te recomiendo que eches un vistazo a deltatime, lo que hará que tu juego sea independiente de las actualizaciones por segundo.
Te recomiendo que eches un vistazo a esta pregunta. Explica muy bien cómo calcularlo y usarlo. Cómo obtener y usar el tiempo delta
Espero que haya ayudado!
fuente
La mejor respuesta es: depende .
No tienes que limitar a ninguno
Actualizaciones : si sus actualizaciones no están vinculadas a un límite superior, entonces la lógica del juego debe depender de una cantidad de tiempo delta , para evitar ejecutar el juego más rápido o más lento dependiendo de la máquina donde se ejecuta. Este es un enfoque muy común utilizado por muchos juegos, pero no es el único.
Renderizado : si el renderizado no está vinculado a un límite superior, el framebuffer podría presentarse en un estado incompleto o erróneo, causando artefactos desgarrantes . Es por eso que muchos juegos emplean Sincronización vertical (v-sync)
Puedes limitar ambos
Actualizaciones : algunos juegos utilizan tiempos fijos para algunos o todos sus sistemas de juego. Este enfoque funciona tal como lo has descrito. El número de actualizaciones por segundo se limita a un límite superior para garantizar que las cosas no se muevan demasiado rápido en una máquina de primer nivel. Esto elimina la necesidad de temporización delta. Algunas aplicaciones son mejores con tiempos fijos, algunas con temporización delta. Elegir qué enfoque dependerá por completo de lo que exactamente está tratando de lograr. El libro en línea GameProgrammingPatterns tiene un capítulo dedicado a los bucles de juegos que toca ambas arquitecturas.
Renderizado : los cuadros por segundo deben establecerse en un límite superior para evitar el problema de rotura mencionado anteriormente, sin embargo, su aplicación no debe intentar hacerlo manualmente con algún bloqueo de CPU. En su lugar, habilite v-sync y deje que el hardware subyacente se sincronice con la frecuencia de actualización del monitor. Al hacer eso, su juego será compatible con futuros monitores que podrían operar en una frecuencia mucho más alta que la actual de 60Hz. También vale la pena señalar que muchos jugadores, en particular aquellos en benchmarking, aún prefieren correr sin v-sync para permitir la velocidad de fotogramas más alta posible. Por lo tanto, es sensato permitir habilitar o deshabilitar la función durante el tiempo de ejecución.
Lo que no debes limitar
Si su juego utiliza un enfoque basado en encuestas para la entrada del usuario, por ejemplo: llama a una
getInput()especie de actualizar los estados del controlador durante el paso de actualización, entonces esto es mejor si no limitado. O, si está limitado, establezca un límite superior muy alto. Cuanto más a menudo consultes la entrada del usuario y actúes sobre ella, más ágil y sensible será el juego. Los llamados juegos de 60Hz que escuchamos hoy en día no están actualizando la inteligencia artificial y todos los estados del mundo a ese ritmo, algunos ni siquiera lo hacen tan rápido, pero consultan la entrada del controlador al menos 60 veces por segundo y actualizan el avatar del jugador en consecuencia. Concedido que esto solo es realmente relevante para los juegos de acción de ritmo rápido.fuente
Hay dos publicaciones que tal vez quieras echar un vistazo:
Arregla tu Timestep
Representación física interpolada
Encuentro que las discusiones en las publicaciones son realmente invaluables, pero en mi opinión tiene más sentido cuando hay una cantidad importante de simulación física en el juego. En resumen, la idea es que la simulación debe tener un paso de tiempo fijo (de lo contrario, la física podría explotar en algún punto donde el delta es demasiado grande), mientras que la representación debería tener libertad para ejecutarse a la velocidad máxima posible. Para sincronizar ambos (la simulación y la representación), el estado de representación se interpola por un factor que depende de qué tan lejos esté la simulación de la siguiente actualización (recuerde que la simulación es fija).
Espero eso ayude.
fuente