¿Cuándo debo usar un paso de tiempo fijo o variable?

256

¿Debe un bucle de juego basarse en pasos de tiempo fijos o variables? ¿Uno siempre es superior o la elección correcta varía según el juego?

Paso de tiempo variable

Las actualizaciones de física pasan un argumento de "tiempo transcurrido desde la última actualización" y, por lo tanto, dependen de la velocidad de fotogramas. Esto puede significar hacer cálculos como position += distancePerSecond * timeElapsed.

Pros : suave, más fácil de codificar
Contras : no determinista, impredecible en pasos muy pequeños o grandes

deWiTTERS ejemplo:

while( game_is_running ) {
    prev_frame_tick = curr_frame_tick;
    curr_frame_tick = GetTickCount();
    update( curr_frame_tick - prev_frame_tick );
    render();
}

Paso de tiempo fijo

Es posible que las actualizaciones ni siquiera acepten un "tiempo transcurrido", ya que suponen que cada actualización es por un período de tiempo fijo. Los cálculos pueden hacerse como position += distancePerUpdate. El ejemplo incluye una interpolación durante el render.

Pros : predecible, determinista (¿más fácil de sincronizar en red?), Código de cálculo más claro
Contras : no sincronizado para monitorear la sincronización en v (causa gráficos nerviosos a menos que interpoles), velocidad de fotogramas máxima limitada (a menos que interpoles), difícil de trabajar dentro de marcos que asumir pasos de tiempo variable (como Pyglet o Flixel )

deWiTTERS ejemplo:

while( game_is_running ) {
    while( GetTickCount() > next_game_tick ) {
        update();
        next_game_tick += SKIP_TICKS;
    }
    interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick )
                    / float( SKIP_TICKS );
    render( interpolation );
}

Algunos recursos

Nick Sonneveld
fuente
66
Use pasos de tiempo variables para su juego y pasos fijos para la física
Daniel Little
77
No diría que el paso de tiempo variable es más fácil de codificar exactamente porque con el paso de tiempo fijo "no tiene que confundir todos los cálculos con la variable TimeElapsed en todas partes". No es que sea tan difícil, pero no agregaría "más fácil de codificar" como profesional.
Pek
Es cierto, creo que me refería a cómo no necesitarías interpolar pasos de tiempo variable.
Nick Sonneveld
@ Pek Estoy de acuerdo contigo. El paso de tiempo variable tiene un bucle de juego codificado más simple, pero tiene más para codificar en sus entidades que se ocupan de esa variabilidad para "acelerar". El paso de tiempo fijo tiene un ciclo de juego más complicado de codificar (porque tienes que compensar con precisión las variaciones de aproximación de tiempo y recalcular qué retraso adicional agregar o cuántas actualizaciones omitir para mantenerlo fijo) pero tiene una codificación más simple para las entidades que siempre tiene que lidiar con el mismo intervalo de tiempo. En general, ninguno de los enfoques es claramente más simple que el otro.
Shivan Dragon
Puede verificar estos elementos visuales desde esta herramienta: s3.amazonaws.com/picobots/assets/unity/jerky-motion/… aunque no le da una idea de cómo se verían cuando la velocidad de fotogramas varía
Buddy

Respuestas:

134

Hay dos cuestiones relacionadas con la pregunta.

  • ¿Debería la velocidad de paso física estar vinculada a la velocidad de fotogramas?
  • ¿Debería la física ir con deltas constantes?

En Glen fielder's Fix your time step, dice "Libera la física". Eso significa que su velocidad de actualización física no debe estar vinculada a su velocidad de fotogramas.

Por ejemplo, si la velocidad de fotogramas de la pantalla es de 50 fps y la simulación está diseñada para ejecutarse a 100 fps, entonces debemos realizar dos pasos físicos en cada actualización de la pantalla para mantener la física sincronizada.

En las recomendaciones de Erin Catto para Box2D también defiende esto.

Así que no ate el paso del tiempo a su velocidad de fotogramas (a menos que realmente tenga que hacerlo).

¿Debería la velocidad de paso de Física estar vinculada a su velocidad de cuadros? No.


Los pensamientos de Erin sobre el paso fijo versus el paso variable:

Box2D utiliza un algoritmo computacional llamado integrador. Los integradores simulan las ecuaciones físicas en puntos de tiempo discretos. ... Tampoco nos gusta que el paso del tiempo cambie mucho. Un paso de tiempo variable produce resultados variables, lo que dificulta la depuración.

Pensamientos de Glen sobre los pasos fijos frente a los variables:

Repara tu paso temporal o explota

... Si tiene una serie de restricciones de resorte realmente rígidas para los amortiguadores en una simulación de automóvil, los pequeños cambios en dt pueden hacer que la simulación explote. ...

¿Debería la física ir con deltas constantes? Si.


La forma de aumentar la física con deltas constantes y no vincular la velocidad de actualización de la física a la velocidad de fotogramas es utilizar un acumulador de tiempo. En mi juego lo llevo un paso más allá. Aplico una función de suavizado al tiempo entrante. De esa manera, los picos FPS grandes no hacen que la física salte demasiado lejos, sino que se simulan más rápidamente para un cuadro o dos.

Usted menciona que con una velocidad fija, la física no se sincronizaría con la pantalla. Esto es cierto si la velocidad física objetivo está cerca de la velocidad de fotogramas objetivo. Es peor que la velocidad de fotogramas sea mayor que la velocidad física. En general, es mejor alcanzar una tasa de actualización física del doble de su FPS objetivo, si puede permitírselo.

Si no puede permitirse una gran tasa de actualización de física, considere la posibilidad de interpolar las posiciones de los gráficos entre cuadros para que los gráficos dibujados parezcan moverse más suavemente de lo que realmente se mueve la física.

código_deft
fuente
1
Jugué The Floor is Jelly antes y después de actualizar mi máquina y fue una tontería: no era lo mismo porque la física fue invocada desde el bucle del juego (y por lo tanto vinculada a la velocidad de fotogramas) y no desde un temporizador Mi vieja máquina era muy mala, por lo que cambiaba constantemente entre cámara lenta y demasiado rápida y tenía un gran impacto en el juego. Ahora es solo un movimiento muy rápido. De todos modos, ese juego es un buen ejemplo de cuán problemático puede llegar a ser este problema (aunque sigue siendo un juego lindo).
MasterMastic
55

Creo que realmente hay 3 opciones, pero las estás enumerando como solo 2:

Opción 1

Hacer nada. Intente actualizar y renderizar a cierto intervalo, por ejemplo, 60 veces por segundo. Si se queda atrás, déjalo y no te preocupes. Los juegos se ralentizarán en cámara lenta y desigual si la CPU no puede seguir el ritmo de tu juego. Esta opción no funcionará en absoluto para juegos multiusuario en tiempo real, pero está bien para juegos de un solo jugador y se ha utilizado con éxito en muchos juegos.

opcion 2

Use el tiempo delta entre cada actualización para variar el movimiento de los objetos. Genial en teoría, especialmente si nada en tu juego se acelera o desacelera, pero solo se mueve a una velocidad constante. En la práctica, muchos desarrolladores implementan esto mal, y puede conducir a una detección inconsistente de colisión y física. Parece que algunos desarrolladores piensan que este método es más fácil de lo que es. Si desea usar esta opción, necesita mejorar considerablemente su juego y sacar algunas matemáticas y algoritmos de armas grandes, por ejemplo, usando un integrador de física Verlet (en lugar del Euler estándar que usa la mayoría de las personas) y usando rayos para la detección de colisiones en lugar de simples controles de distancia de Pitágoras. Hice una pregunta sobre esto en Stack Overflow hace un tiempo y obtuve algunas respuestas excelentes:

https://stackoverflow.com/questions/153507/calculate-the-position-of-an-accelerating-body-after-a-certain-time

Opción 3

Utilice el enfoque de Gaffer "arregle su paso de tiempo". Actualice el juego en pasos fijos como en la opción 1, pero hágalo varias veces por cuadro procesado, en función de cuánto tiempo haya transcurrido, de modo que la lógica del juego se mantenga al día en tiempo real, mientras se mantiene en pasos discretos. De esta manera, la lógica de juego fácil de implementar, como los integradores de Euler, y la detección de colisión simple aún funcionan. También tiene la opción de interpolar animaciones gráficas basadas en el tiempo delta, pero esto es solo para efectos visuales, y nada que afecte la lógica de su juego principal. Potencialmente, puede meterse en problemas si sus actualizaciones son muy intensas: si las actualizaciones se retrasan, necesitará más y más para mantenerse al día, lo que puede hacer que su juego sea aún menos receptivo.

Personalmente, me gusta la Opción 1 cuando me salgo con la suya y la Opción 3 cuando necesito sincronizar en tiempo real. Respeto que la Opción 2 puede ser una buena opción cuando sabes lo que estás haciendo, pero conozco mis limitaciones lo suficientemente bien como para alejarme de ella.

Iain
fuente
con respecto a la opción 2: no estoy seguro de que una emisión de rayos pueda ser más rápida que las comprobaciones de distancia de Pitágoras, excepto si su aplicación de Pitágoras es muy bruta, pero una emisión de rayos también será muy costosa si no agrega una fase ancha.
Kaj
44
Si usa Verlet con pasos de tiempo desiguales, está tirando al bebé con el agua del baño. La razón por la que Verlet es tan estable como es, es porque los errores se cancelan en pasos de tiempo posteriores. Si los pasos de tiempo no son iguales, esto no sucede y estás de vuelta en tierra física en explosión.
drxzcl
Opción 3: suena como la descripción de Joel Martínez del enfoque XNA.
arriba el
1
Esta es una muy buena respuesta. Las tres opciones tienen su lugar y es importante entender cuándo son apropiadas.
Adam Naylor
En todos los MMO en los que he trabajado (EQ, Landmark / EQNext [cry], PS2 [brevemente] y ESO), siempre hemos usado tiempo de cuadro variable. Nunca he sido parte de esa decisión en particular, simplemente me presenté después del hecho e hice uso de lo que otros han decidido.
Mark Storer
25

Me gusta mucho la forma en que XNA Framework implementa un paso de tiempo fijo. Si una llamada de extracción determinada demora un poco, llamará a la actualización repetidamente hasta que "se ponga al día". Shawn Hargreaves lo describe aquí:
http://blogs.msdn.com/b/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx

En 2.0, el comportamiento de Draw ha cambiado:

  • Actualice la llamada tantas veces como sea necesario para alcanzar la hora actual
  • Llamar a Draw una vez
  • Espere hasta que llegue la próxima actualización

El mayor profesional en mi opinión es el que mencionaste, que hace que todos tus cálculos de código de juego sean mucho más simples porque no tienes que incluir esa variable de tiempo por todas partes.

nota: xna también admite tiempos variables, es solo una configuración.

Joel Martinez
fuente
Esta es la forma más común de hacer un ciclo de juego. Sin embargo, no es excelente para la duración de la batería cuando se trabaja con dispositivos móviles.
knight666
1
@ knight666; ¿Estás sugiriendo que usando un paso de tiempo más largo, la cantidad reducida de iteraciones salvará la vida de la batería?
falstro
Sigue siendo una actualización variable: el delta de actualización cambia según el tiempo que tardó en procesarse el fotograma en lugar de algún valor fijo (es decir, 1/30 de segundo).
Dennis Munsie
1
@ Dennis: según tengo entendido, la función Actualizar se llama con un delta fijo ...
RCIX
3
@ knight666 Uh - ¿Cómo te imaginas eso? Si tiene vsync activado y no está tartamudeando, ¡estos métodos deberían ser idénticos! ¡Y si tiene vsync desactivado , está actualizando más de lo necesario y probablemente desperdiciando la CPU (y por lo tanto la batería) al no dejarla inactiva!
Andrew Russell el
12

Hay otra opción: desacoplar la actualización del juego y la actualización de la física. Intentar adaptar el motor de física al paso de tiempo del juego conduce a un problema si arreglas tu paso de tiempo (el problema de girar fuera de control porque la integración necesita más pasos de tiempo que requieren más tiempo que necesita más pasos de tiempo), o hacer que sea variable y obtener física torpe.

La solución que veo mucho es hacer que la física se ejecute en un paso de tiempo fijo, en un hilo diferente (en un núcleo diferente). El juego se interpola o extrapola dados los dos marcos válidos más recientes que puede obtener. La interpolación agrega algo de retraso, la extrapolación agrega algo de incertidumbre, pero su física será estable y no perderá el control de su tiempo.

No es trivial de implementar, pero podría probarse a sí mismo como una prueba futura.

Kaj
fuente
8

Personalmente, uso una variación de tiempo variable (que es una especie de híbrido de fijo y variable, creo). Hice hincapié en este sistema de temporización de varias maneras, y me encuentro usándolo para muchos proyectos. ¿Lo recomiendo para todo? Probablemente no.

Mis bucles de juego calculan la cantidad de fotogramas para actualizar (llamemos a esto F) y luego realizan actualizaciones lógicas discretas F. Cada actualización lógica supone una unidad de tiempo constante (que a menudo es 1/100 de segundo en mis juegos). Cada actualización se realiza en secuencia hasta que se realicen todas las actualizaciones lógicas discretas F.

¿Por qué actualizaciones discretas en pasos lógicos? Bueno, si intentas usar pasos continuos, y de repente tienes fallas físicas porque las velocidades y distancias calculadas para viajar se multiplican por un valor enorme de F.

Una implementación deficiente de esto solo haría F = hora actual - últimas actualizaciones de tiempo de cuadro. Pero si los cálculos se retrasan demasiado (a veces debido a circunstancias más allá de su control, como otro proceso que roba el tiempo de la CPU), verá rápidamente un salto horrible. Rápidamente, ese FPS estable que intentó mantener se convierte en SPF.

En mi juego, permito una desaceleración "suave" (más o menos) para restringir la cantidad de recuperación lógica que debería ser posible entre dos sorteos. Hago esto sujetando: F = min (F, MAX_FRAME_DELTA) que generalmente tiene MAX_FRAME_DELTA = 2/100 * so 3/100 * s. Entonces, en lugar de omitir fotogramas cuando está demasiado lejos de la lógica del juego, descarte cualquier pérdida de fotogramas masiva (lo que ralentiza las cosas), recupere algunos fotogramas, dibuje e intente nuevamente.

Al hacer esto, también me aseguro de que los controles del reproductor se mantengan sincronizados con lo que realmente se muestra en la pantalla.

El pseudocódigo del producto final es algo como esto (delta es F mencionado anteriormente):

// Assume timers have 1/100 s resolution
const MAX_FRAME_DELTA = 2
// Calculate frame gap.
var delta = current time - last frame time
// Clamp.
delta = min(delta, MAX_FRAME_RATE)
// Update in discrete steps
for(i = 0; i < delta; i++)
{
    update single step()
}
// Caught up again, draw.
render()

Este tipo de actualización no es adecuada para todo, pero para los juegos de estilo arcade, preferiría ver que el juego se ralentiza porque hay muchas cosas en lugar de fallar cuadros y perder el control del jugador. También prefiero esto a otros enfoques de pasos de tiempo variable que terminan teniendo fallas irreproducibles causadas por la pérdida de cuadros.

Overkill
fuente
Muy de acuerdo con ese último punto; En casi todos los juegos, la entrada debería "ralentizarse" cuando baja la velocidad de fotogramas. Aunque esto no es posible en algunos juegos (es decir, multijugador), aún sería mejor si fuera posible. : P Simplemente se siente mejor que tener un marco largo y luego hacer que el mundo del juego 'salte' al estado 'correcto'.
Ipsquiggle
Sin hardware fijo como una máquina arcade, hacer que los juegos arcade ralenticen la simulación cuando el hardware no puede mantener el ritmo hace que jugar en una máquina más lenta haga trampa.
Joe, eso solo importa si nos importa "hacer trampa". La mayoría de los juegos modernos no se trata realmente de competencia entre jugadores, sino de hacer una experiencia divertida.
Iain
1
Iain, estamos hablando específicamente de juegos de estilo arcade aquí, que tradicionalmente son impulsados ​​por la lista de puntajes / tablas de clasificación. Juego un montón de shmups, y sé que si descubriera que alguien publicaba puntajes con desaceleración artificial en las tablas de clasificación, me gustaría que borraran sus puntajes.
No trato de disminuir su respuesta, pero interpretaría esto como un paso fijo donde el renderizado no está directamente relacionado con la tasa de actualización física, excepto que ponerse al día con la física tiene prioridad sobre el renderizado. Definitivamente tiene buenas cualidades.
AaronLS
6

Esta solución no se aplica a todo, pero hay otro nivel de paso de tiempo variable: paso de tiempo variable para cada objeto en el mundo.

Esto parece complicado, y puede serlo, pero piense en ello como modelar su juego como una simulación de evento discreto. Cada movimiento del jugador se puede representar como un evento que comienza cuando comienza el movimiento y termina cuando termina el movimiento. Si hay alguna interacción que requiera que el evento se divida (una colisión, por ejemplo), el evento se cancela y otro evento se inserta en la cola del evento (que probablemente sea una cola prioritaria ordenada por hora de finalización del evento).

La representación está totalmente separada de la cola de eventos. El motor de visualización interpola puntos entre los tiempos de inicio / finalización del evento según sea necesario, y puede ser tan preciso o descuidado en esta estimación como sea necesario.

Para ver una implementación compleja de este modelo, vea el simulador espacial EXOFLIGHT . Utiliza un modelo de ejecución diferente de la mayoría de los simuladores de vuelo: un modelo basado en eventos, en lugar del modelo tradicional de intervalo de tiempo fijo. El bucle principal básico de este tipo de simulación se ve así, en pseudocódigo:

while (game_is_running)
{
   world.draw_to_screen(); 
   world.get_player_input(); 
   world.consume_events_until(current_time + time_step); 
   current_time += time_step; 
}

La razón principal para usar uno en un simulador espacial es la necesidad de proporcionar una aceleración de tiempo arbitraria sin pérdida de precisión. Algunas misiones en EXOFLIGHT pueden tardar años de juego en completarse, e incluso una opción de aceleración 32x sería insuficiente. Necesitarías más de 1,000,000x de aceleración para un sim utilizable, lo cual es difícil de hacer en un modelo de segmento de tiempo. Con el modelo basado en eventos, obtenemos tasas de tiempo arbitrarias, de 1 s = 7 ms a 1 s = 1 año.

Cambiar la tasa de tiempo no cambia el comportamiento del sim, que es una característica crítica. Si no hay suficiente potencia de CPU disponible para ejecutar el simulador a la velocidad deseada, los eventos se acumularán y podríamos limitar la actualización de la interfaz de usuario hasta que se borre la cola de eventos. Del mismo modo, podemos avanzar rápidamente el sim tanto como queramos y asegurarnos de que no desperdiciamos CPU ni sacrificamos la precisión.

En resumen: podemos modelar un vehículo en una órbita larga y pausada (utilizando la integración Runge-Kutta) y otro vehículo que rebota simultáneamente en el suelo; ambos vehículos se simularán con la precisión adecuada, ya que no tenemos un paso de tiempo global.

Contras: Complejidad y falta de motores físicos disponibles que admitan este modelo :)

sehugg
fuente
5

El paso de tiempo fijo es útil cuando se tiene en cuenta la precisión del punto flotante y para que las actualizaciones sean consistentes.

Es un código simple, por lo que sería útil probarlo y ver si funciona para tu juego.

now = currentTime
frameTime = now - lastTimeStamp // time since last render()
while (frameTime > updateTime)
    update(timestep)
    frameTime -= updateTime     // update enough times to catch up
                                // possibly leaving a small remainder
                                // of time for the next frame

lastTimeStamp = now - frameTime // set last timestamp to now but
                                // subtract the remaining frame time
                                // to make sure the game will still
                                // catch up on those remaining few millseconds
render()

El problema principal con el uso de un paso de tiempo fijo es que los jugadores con una computadora rápida no podrán usar la velocidad. Renderizar a 100 fps cuando el juego se actualiza solo a 30 fps es lo mismo que solo renderizar a 30 fps.

Dicho esto, puede ser posible usar más de un paso de tiempo fijo. Se pueden usar 60 fps para actualizar objetos triviales (como UI o sprites animados) y 30 fps para actualizar sistemas no triviales (como física y) e incluso temporizadores más lentos para administrar detrás de escena, como eliminar objetos no utilizados, recursos, etc.

Nick Bedford
fuente
2
Si el juego está hecho con cuidado, el método de renderizado puede hacer interpolación para hacer actualizaciones de 30 fps, en realidad no es lo mismo que renderizar a 30 fps.
Ricket,
3

Además de lo que ya has dicho, puede deberse a la sensación que deseas que tenga tu juego. A menos que pueda garantizar que siempre tendrá una velocidad de fotogramas constante, es probable que tenga una desaceleración en algún lugar y los pasos de tiempo fijos y variables se verán muy diferentes. Reparado tendrá el efecto de que tu juego vaya en cámara lenta por un tiempo, que a veces puede ser el efecto deseado (mira un juego de disparos de la vieja escuela como Ikaruga donde las explosiones masivas causan desaceleración después de vencer a un jefe). Los pasos de tiempo variables mantendrán las cosas en movimiento a la velocidad correcta en términos de tiempo, pero puede ver cambios repentinos en la posición, etc., lo que puede dificultar que el jugador realice acciones con precisión.

Realmente no puedo ver que un paso de tiempo fijo facilitará las cosas en una red, todos estarían un poco fuera de sincronización para empezar y se ralentizarían en una máquina, pero no otra haría que las cosas se desincronizaran más.

Siempre me he inclinado personalmente por el enfoque variable, pero esos artículos tienen algunas cosas interesantes en las que pensar. Sin embargo, todavía he encontrado pasos fijos bastante comunes, especialmente en consolas donde la gente piensa que la velocidad de fotogramas es de 60 fps constantes en comparación con las tasas muy altas que se pueden lograr en la PC.

Identitycrisisuk
fuente
55
Definitivamente deberías leer el enlace Gaffer en juegos en la publicación original. No creo que esta sea una mala respuesta per se, así que no la votaré, pero no estoy de acuerdo con ninguno de sus argumentos .
falstro
No creo que la desaceleración en un juego como resultado de un paso de tiempo fijo pueda ser intencional, porque es por falta de control. La falta de control es, por definición, rendirse al azar y, por lo tanto, no puede ser intencional. Puede ser lo que tenías en mente, pero eso es todo lo que quisiera hacer. En cuanto al paso de tiempo fijo en la red, hay una ventaja definitiva allí, ya que mantener los motores de física en dos máquinas diferentes sincronizadas sin el mismo paso de tiempo es bastante imposible. Dado que la única opción para sincronizar sería enviar todas las transformaciones de entidad, sería demasiado ancho de banda.
Kaj
0

Utilice el enfoque de Gaffer "arregle su paso de tiempo". Actualice el juego en pasos fijos como en la opción 1, pero hágalo varias veces por cuadro procesado, en función de cuánto tiempo haya transcurrido, de modo que la lógica del juego se mantenga al día en tiempo real, mientras se mantiene en pasos discretos. De esta manera, la lógica de juego fácil de implementar, como los integradores de Euler, y la detección de colisión simple aún funcionan. También tiene la opción de interpolar animaciones gráficas basadas en el tiempo delta, pero esto es solo para efectos visuales, y nada que afecte la lógica de su juego principal. Potencialmente, puede meterse en problemas si sus actualizaciones son muy intensas: si las actualizaciones se retrasan, necesitará más y más para mantenerse al día, lo que puede hacer que su juego sea aún menos receptivo.

Personalmente, me gusta la Opción 1 cuando me salgo con la suya y la Opción 3 cuando necesito sincronizar en tiempo real. Respeto que la opción 2 puede ser una buena opción cuando sabes lo que estás haciendo, pero conozco mis limitaciones lo suficientemente bien como para mantenerme alejado de ella.


fuente
¡Si vas a robar respuestas, al menos dale crédito a la persona!
PrimRock
0

Descubrí que los pasos de tiempo fijos sincronizados a 60 fps proporcionan una animación de espejo suave. Esto es especialmente importante para las aplicaciones de realidad virtual. Cualquier otra cosa es físicamente nauseabunda.

Los pasos de tiempo variables no son adecuados para la realidad virtual. Eche un vistazo a algunos ejemplos de Unity VR que utilizan pasos de tiempo variables. Es desagradable.

La regla es que si tu juego 3D es fluido en modo VR, será excelente en modo no VR.

Compare estos dos (aplicaciones Cardboard VR)

(Pasos de tiempo variables)

(Pasos de tiempo fijos)

Tu juego debe ser multiproceso para lograr un paso de tiempo / velocidad de fotogramas constante. La física, la interfaz de usuario y el renderizado se deben separar en hilos dedicados. Es horrible que PITA los sincronice, pero los resultados son ese reflejo suave que desea (especialmente para VR).

Los juegos móviles son especialmente desafiante porque las CPU y GPU integradas tienen un rendimiento limitado. Use GLSL (argot) con moderación para descargar la mayor cantidad de trabajo posible de la CPU. Tenga en cuenta que pasar parámetros a la GPU consume recursos del bus.

Mantenga siempre la velocidad de fotogramas mostrada durante el desarrollo. El verdadero juego es mantenerlo fijo a 60 fps. Esta es la tasa de sincronización nativa para la mayoría de las pantallas y también para la mayoría de los globos oculares.

El marco que está utilizando debería poder notificarle sobre una solicitud de sincronización o utilizar un temporizador. No inserte un retraso de sueño / espera para lograr esto, incluso se notan ligeras variaciones.

Dominic Cerisano
fuente
0

Los pasos de tiempo variable son para procedimientos que deben ejecutarse con la mayor frecuencia posible: ciclos de procesamiento, manejo de eventos, material de red, etc.

Los pasos de tiempo fijos son para cuando necesita que algo sea predecible y estable. Esto incluye, entre otros, la física y la detección de colisiones.

En términos prácticos, la detección física y de colisión debe estar desconectada de todo lo demás, en su propio paso de tiempo. La razón para realizar procedimientos como estos en un pequeño intervalo de tiempo fijo es mantenerlos precisos. Las magnitudes de impulso dependen en gran medida del tiempo, y si el intervalo se vuelve demasiado grande, la simulación se vuelve inestable y suceden cosas locas como una pelota que rebota en el suelo o rebota en el mundo del juego, ninguna de las cuales es deseable.

Todo lo demás puede ejecutarse en un paso de tiempo variable (aunque hablando profesionalmente, a menudo es una buena idea permitir bloquear la representación en un paso de tiempo fijo). Para que un motor de juego sea receptivo, cosas como los mensajes de red y la entrada del usuario deben manejarse lo antes posible, lo que significa que el intervalo entre sondeos debería ser lo más corto posible. Esto generalmente significa variable.

Todo lo demás se puede manejar de forma asincrónica, lo que convierte el momento en un punto discutible.

Ian Young
fuente