FPS y UPS. Aumento de la velocidad del juego. Java Game 7

Si un juego ofrece 50 FPS (es decir, 50 iteraciones run() de animación por segundo), al agregar un nuevo gameUpdate() dentro de run() estará haciendo 100 actualizaciones por segundo, es decir el doble. Este tipo de medición, aparte del FPS, es la denominada UPS.
Este estilo de codificación hace que el juego avance más rápidamente, ya que el estado del juego está
cambiando dos veces más rápido, pero a costa de saltarse la representación de esos estados adicionales. Sin embargo, esto puede no ser notable, especialmente si el valor FPS es 20 o superior.

public void run( ){ //... running = true; while(running) { gameUpdate( ); // game state is updated gameUpdate( ); // game state is updated again gameRender( ); // render to a buffer paintScreen( ); // paint with the buffer // sleep a bit } System.exit(0); } // end of run( )

Una limitación en las altas tasas de FPS es la cantidad de tiempo que la actualización y procesa
Pasos requeridos. Satisfacer un período de 5 ms (1000/5 == 200 FPS) es imposible ya que se necesitan mas pasos para lograr el objetivo en más de 5 ms. La mayor parte de este tiempo de ejecución suele consumirse. En esta situación, la forma de aumentar la velocidad del juego es aumentar el número de UPS. En términos de programación, esto se traduce en llamar a gameUpdate() más de una vez durante cada iteración. Sin embargo, demasiadas llamadas adicionales harán que el juego parpadee, como demasiados estados sucesivos que no se representan.
Para este caso el nuevo run() nos quedará:

private static final int NO_DELAYS_PER_YIELD = 16; /* Número de fotogramas con un retardo de 0 ms antes de que el hilo de la animación corra de nuevo. */ private static int MAX_FRAME_SKIPS = 5; // nº de frames que se pueden omitir en cualquier bucle de animación // es decir, el estado del juego se actualiza pero no se procesa public void run( ){ long beforeTime, afterTime, timeDiff, sleepTime; long overSleepTime = 0L; int noDelays = 0; long excess = 0L; beforeTime = System.nanoTime(); boolean running = true; while(running) { gameUpdate( ); gameRender( ); paintScreen( ); afterTime = System.nanoTime(); timeDiff = afterTime - beforeTime; sleepTime = (period - timeDiff) - overSleepTime; if (sleepTime > 0) { // some time left in this cycle try { Thread.sleep(sleepTime/1000000L); // nano -> ms } catch(InterruptedException ex){} overSleepTime = (System.nanoTime() - afterTime) - sleepTime; } else { // sleepTime <= 0; frame took longer than the period excess -= sleepTime; // store excess time value overSleepTime = 0L; if (++noDelays >= NO_DELAYS_PER_YIELD) { Thread.yield( ); // give another thread a chance to run noDelays = 0; } } beforeTime = System.nanoTime(); /* Si la animación de fotograma tarda demasiado tiempo, actualice el estado del juego              sin procesarla, para obtener las actualizaciones /seg más cerca del FPS requerido. */ int skips = 0; while((excess > period) && (skips < MAX_FRAME_SKIPS)) { excess -= period; gameUpdate( ); // update state but don't render skips++; } } System.exit(0); } // end of run( )

Si el update/render toma 12 ms y el período requerido son 10 ms, entonces sleepTime será -2 ms. Este excesivo tiempo de ejecución se añade a la variable excedente, que actúa como un total de todos los rebasamientos por las llamadas de actualización-render.
Cuando el exceso excede el período de iteración se introduce un bucle while, que actualiza el juego por cada período perdido, hasta un máximo de MAX_FRAME_SKIPS (cinco actualizaciones). El tiempo restante de saturación se almacena para su uso en una iteración posterior. El valor MAX_FRAME_SKIPS es arbitrario, pero cuanto mayor es, más repentino será el salto hacia adelante en el juego si el número máximo de los marcos se saltan.
El resultado es que cuando un juego no puede actualizarse y renderizar lo suficientemente rápido para el FPS deseado, entonces se realizarán llamadas adicionales a gameUpdate(). Esto cambia el estado sin procesarlo, lo que el usuario ve como el juego se mueve "más rápido", incluso aunque el número de marcos renderizados sigua siendo el mismo.