Tema 3 Otros patrones - Apuntes 3 PDF

Preview

Summary

Temario impartido por Alfredo Cuesta...

Description

URJC

Grado en Desarrollo y Diseño de Videojuegos

Ingeniería de Videojuegos

Curso 2016/17

Otros patrones Índice 1. Patrones de secuenciamiento: ‘Game Loop’ 2 1.1. Problema y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Pausar el bucle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2. Ajustar el ritmo de actualización del estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Patrones de desacoplo: ‘Component’ 2.1. Problema y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Ejemplo de utilización de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 7

3. Patrones de optimización: ‘Dirty Flag’ 3.1. Problema y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Problema y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8 8

4. Patrones de comportamiento: ‘ByteCode’ 9 4.1. Problema y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Primera aproximación al diseño de la VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Mejorando el diseño de la VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Ejercicios 5.1. Game Loop 5.2. Component . 5.3. Dirty Flag . . 5.4. ByteCode . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13 13 13 14 14

2

A.Cuesta, A.Herrán @ Semana 4 – 5, 2016

1. Patrones de secuenciamiento: ‘Game Loop’ Los patrones de secuenciamiento son las herramientas que tiene el desarrollador para crear el tiempo y su transcurso en el mundo virtual del vj. Entre los estos patrones el más importante es ‘Game Loop’, que nos va a proporcionar el soporte para ejecutar el vj. Otros patrones son ‘Update methods’ y ‘Double Buffering’. El primero hace que los objetos sientan el paso del tiempo. El segundo se emplea en el motor gráfico para acelerar la presentación de gráficos, y seguramente se utilizará en asignaturas de Informática Gráfica. Por eso nosotros ahora nos centraremos sólo en ‘Game Loop’.

1.1. Problema y contexto En este enlace H se puede leer un caso interesante que sucede cuando se ejecuta un vj. de los años 90 en el Hw. actual. Literalmente:

El problema, tal y como se cuenta en ese foro, es que la velocidad ejecución del vj. está ligada a la velocidad del procesador. Esto parece algo bastante lógico, y de hecho lo es para la mayor parte de las aplicaciones que se ejecutan. El motivo es que estas generalmente se diseñan para una interacción reactiva o responsiva con el usuario. Es decir que la aplicación está esperando a que el usuario haga clic en algún sitio para hacer algo como reacción o en respuesta. Pero un vj. tiene una estructura un poco diferente, que básicamente se puede resumir un bucle con tres acciones: (i) leer y procesar la entrada, (ii) actualizar el estado del vj. y (iii) dibujar la pantalla. En el pseudocódigo de abajo a la izquierda se puede ver un ejemplo de game loop. main ( ) { init (); ( ru n n in g ) { pr ocess In pu t ( ) ; upd ateGameStat e ( ) ; re n d e r ( ) ; } deInit ( ); }

Diferencia entre el tiempo real y el tiempo en el vj.

Evidentemente, cuanto más rápido sea el procesador, más rápido se ejecutará el bucle. Para resolver este problema hay que tener en cuenta que en un vj. generalmente el tiempo transcurrido para los personajes debe ser igual, o si no proporcional (por ejemplo en simulaciones como Civilization), al tiempo transcurrido para el jugador para que la jugabilidad sea aceptable. Es decir, el programador de vj. tiene que pensar en dos relojes: el que tiene en su mesa, que avanza por el simple transcurso del tiempo, denominado tiempo real; y el reloj que marca el paso del tiempo del vj. El programador, a través del código, hace avanzar el tiempo en el vj. a un cierto ritmo, casi siempre constante, por ejemplo de 10 ms. Sin embargo es muy improbable que cada iteración del código necesite exactamente 10 ms. para ejecutarse. Si tuvieramos un reloj en el vj. y un reloj sobre la mesa como en el dibujo de arriba a la derecha, veríamos que el reloj del vj., que avanza siguiendo las instrucciones del programa, va mostrando 10 ms. – 20 ms. – 30 ms. – etc. a un ritmo de, por ejemplo, 1 ms. O sea que cuando en el reloj de la pantalla aparezca 30 ms., en el de la mesa veremos 3 ms. Como nosotros estamos en el mismo mundo que la mesa, sentimos que han pasado sólo 3 ms. en vez de 30 ms. Igualmente, cuando en el reloj del vj. hayan pasado 1000 ms. = 1 s. para nosotros sólo habrán pasado 100 ms. = 1 décima de s.; y cuando en el vj. hayan pasado 60×1000 ms. = 1 min., para nosotros serán 6 s.

3

URJC / GDDV / IV / Otros patrones

Evidentemente esto no nos da sensación de tiempo real en el vj. Por ese motivo es necesario este patrón, con el que vamos a ver dos soluciones. La primera, más obvía, es simplemente esperar el tiempo que haga falta en cada vuelta. La segunda, más elaborada y mejor, es hacer avanzar el tiempo del vj. de un modo acorde con el paso del tiempo real.

1.2. Soluciones 1.2.1. Pausar el bucle Si por ejemplo queremos que el vj. se ejecute a 60 FPS, es decir se actualice 60 veces en un segundo, el tiempo 1 s. = 16 ms. entre dos actualizaciones será de 60 Obviamente necesitaríamos, en primer lugar, hacer todo el procesado y renderizado en menos de ese tiempo.

[ Fuente: “Game Programming Patterns” (R.Nystrom) ]

El resto es invocar un método donde debemos calcular el tiempo que queremos pausar el bucle. ( ru n n in g ) { s t a r t = ge t C u rre n t T im e ( ) ; pr ocess In pu t ( ) ; upd ateGameStat e ( ) ; re n d e r ( ) ; s le e p ( s t a r t +MS_PER_FRAME−g e t Cu rre n t T ime ( ) ) ; }

Esta solución no es escalable. Sólo funciona en entornos muy limitados donde podemos controlar el tiempo de . Por ejemplo no estamos teniendo en cuenta el procesado de sonido ni entornos multijugador.

1.2.2. Ajustar el ritmo de actualización del estado Supongamos que queremos una actualización del estado cada 16 ms. Cada actualización del estado supone un avance en el reloj del vj.. Tras la actualización viene el renderizado, que nos muestra en pantalla la nueva posición de las manecillas del reloj del vj. Si el reloj del vj. avanza 10 ms. cada 16 ms. de tiempo real, entonces tendremos la sensación de que el tiempo del vj. pasa más despacio que el tiempo real (cuando hayan pasado 160 ms de tiempo real sólo habrán pasado 100 ms. de tiempo en el vj.). Al contrario, si el reloj del vj. avanza por ejemplo 20 ms. cada 16 ms. de tiempo real, tendremos la sensación de que el tiempo del vj. pasa más deprisa que el tiempo real (cuando hayan pasado 160 ms. de tiempo real el reloj del vj. ya marcará 200 ms.) En el código dado suponemos que la actualización del estado se realiza cada = 10 ms. para que los resultados sean fáciles de entender y comprobar. Además se pretende que el reloj del vj. avance al mismo ritmo que el reloj de la mesa, de modo que el jugador tenga la sensación de tiempo real. Se han creado 3 métodos: el procesado de información, la actualización del estado del vj. y el renderizado. Cada uno de ellos tarda un cierto tiempo aleatorio que simula el tiempo que un código real necesitaría. Además se han incluido métodos para mostrar el paso del tiempo por pantalla. Todo ello hace el código un poco más complejo de lo que en realidad es. El esqueleto básico del mismo es el comentado en el libro “Game Programming Patterns” de Nystrom, en la sección Play Catch up. En él aparecen dos variables muy importantes:

• elapsed es el tiempo real consumido por la iteracion anterior.

• lag es el tiempo real transcurrido desde el momento en el que avanza el reloj del vj. hasta que pasa otra vez por la instruccion El funcionamiento de este main loop es el siguiente. Al comienzo de cada iteración del bucle se calcula cuanto tardó la iteración anterior. Esa medida se guarda en y se añade a . Entonces se pueden dar los 4 casos de la figura.

4

a)

A.Cuesta, A.Herrán @ Semana 4 – 5, 2016

< El reloj de la mesa ha avanzado menos del tiempo que avanza el reloj del vj. cada vez que se actualiza, por lo que no hace falta cambiarlo. Por eso no entra en el interno.

b) c)

Este es el caso límite entre el anterior y el siguiente.

=

≥ El reloj de la mesa ha avanzado más y por tanto debemos hacer que el reloj del vj. se incremente en ms. Una vez hecho esto se resta esa cantidad de . Todo esto se realiza en el interno, que como se puede ver está controlado por

d)

En caso de que se al menos dos veces mayor que interno se ejecutará varias veces. Por ejemplo si =10 ms. y se ejecutará 3 veces, quedando un =3 ms. para la siguiente iteración.

≫

el =33 ms. dicho

Por último, para medir tiempos se ha empleado la función . Esta función devuelve el número de ticks de reloj del ordenador desde que arranca el programa y para convertirlo en medidas de tiempo se utiliza la constante de sistema . Esta función depende del sistema operativo y del ordenador donde se ejecuta. El código del main loop ha sido desarrollado en Windows 10. Para comprender su funcionamiento se recomienda observar y ejecutar el código de abajo.

Referencias • • • • •

Capítulo 3 de “Game Programming Patterns” (R. Nystrom), disponible on-line aquí H Artículo clásico sobre Game Loop, “Fix Your Timestep!” por G. Fiedler, disponible on-line aquí H Otro artículo clásico sobre Game Loop, este por deWitters, disponible on-line aquí H Una explicación breve y concisa sobre Game Loop, disponible on-line aquí H Otra explicación, bastante detallada y completa, disponible on-line aquí H

Código para comprender el funcionamiento de ‘clock’ # i n cl u d e < s t d i o . h> # i n c l u d e < io s t re a m > # i n c l u d e < t im e . h> st d ; main ( ) { c lo ck _ t t _ i n i , t _ f i n ; se cs ; t _ i n i = c lo c k ( ) ; t _ f i n = c lo ck ( ) ; co u t...