¿Cómo funciona el tiempo XNA?

Question

¿Cómo mantiene XNA una velocidad de cuadro de 60 FPS consistente y precisa? Además, ¿cómo mantiene un tiempo tan preciso sin vincular la CPU al 100%?

Answer 1

No sé específicamente cómo lo hace XNA, pero cuando jugaba con OpenGL hace unos años conseguí lo mismo usando un código muy simple.

en el meollo de ella, supongo que XNA tiene algún tipo de ciclo de renderizado, puede o no puede integrarse con un ciclo de procesamiento uniforme estándar pero, por el bien del ejemplo, supongamos que no lo es. en este caso podrías escribir algo como esto.

TimeSpan FrameInterval = TimeSpan.FromMillis(1000.0/60.0); 
DateTime PrevFrameTime = DateTime.MinValue; 
while(true) 
{ 
    DateTime CurrentFrameTime = DateTime.Now; 
    TimeSpan diff = DateTime.Now - PrevFrameTime; 
    if(diff < FrameInterval) 
    { 
     DrawScene(); 
     PrevFrameTime = CurrentFrameTime; 
    } 
    else 
    { 
     Thread.Sleep(FrameInterval - diff); 
    } 
} 

En realidad, es probable que usar algo como Environment.Ticks en lugar de DateTime (sería más exacto), pero creo que esto ilustra el punto. Esto solo debería llamar a drawScene aproximadamente 60 veces por segundo, y el resto del tiempo el hilo estará durmiendo para que no tenga ningún tiempo de CPU.

Answer 2

los juegos deben funcionar a 60 fps, pero eso no significa que lo harán. Eso es en realidad un límite superior para un juego lanzado.

Si ejecuta un juego en modo de depuración, puede obtener cuadros mucho más altos por segundo; por ejemplo, una plantilla de inicio en blanco en mi computadora portátil en modo de depuración funciona a más de 1,000 fps.

Dicho esto, el framework XNA en un juego lanzado hará todo lo posible para ejecutar a 60 fps, pero el código que incluyó en su proyecto tiene la posibilidad de reducir ese rendimiento. Por ejemplo, tener algo constantemente disparado en la recolección de basura normalmente vería un chapuzón en el fps del juego, o arrojando algunas matemáticas complejas en los métodos de actualización o dibujo, haciendo que disparen cada fotograma ... lo que normalmente sería un poco excesivo. Hay una serie de cosas a tener en cuenta para mantener su juego lo más eficiente posible.

Si está preguntando cómo el marco XNA hace que ese techo suceda, eso realmente no puedo explicarlo, pero puedo decir que dependiendo de cómo diseñe su código, y lo que puede hacer definitivamente puede afectar negativamente a este número, y no siempre tiene que estar relacionado con la CPU. En el caso de la recolección de basura, es solo la limpieza de una RAM que puede no mostrar un aumento en el uso de la CPU, pero podría afectar su FPS, dependiendo de la cantidad de basura y el intervalo que tiene que ejecutarse.

Answer 3

Mientras código de Lucas anterior es derecho teórico de los métodos y propiedades que se utilizan no son las mejores opciones:

• Como la precisión de DateTime.Now es de sólo 30 ms (ver C# DateTime.Now precision y más o menos 20 ms) su uso para alta el tiempo de ejecución no es aconsejable (60 FPS son 16 ms). System.Diagnostics.Stopwatch es the timer of choice for real time .NET
• Thread.Sleep sufre la misma precisión problema/resolución y no se garantiza que dormir durante el tiempo especificado solamente

El FX XNA actual parece enganchar en el bucle de mensajes de Windows y ejecutar su pre-actualización interna cada paso y llamando al Game.Update solo si el tiempo transcurrido desde la última actualización coincide con la velocidad de fotogramas especificada (por ejemplo, cada 16 ms para la configuración predeterminada). Si realmente quiere saber cómo funciona el XNA FX, el trabajo Reflector es su amigo :)

Tidbit aleatorio: De vuelta en el XNA GameStudio 1.0 Marco de tiempo Alpha/Beta hubo bastantes publicaciones en el blog sobre el "ciclo perfecto de WinForms", aunque no las encuentro ahora ...

Answer 4

Puedes leer todo sobre cómo se implementó el temporizador XNA aquí Game timing in XNA Game Studio pero básicamente Intentaría y esperaría 1/60 de segundo antes de continuar el ciclo de nuevo, también tenga en cuenta que la actualización se puede llamar varias veces antes de un render si XNA necesita "ponerse al día".