Programación Avanzada

Universidad del Aconcagua

Programación Avanzada
El Juego (parte 1)
Renderizado y Actualización

Esp. Ing. César Aranda

unidatos@gmail.com

Licenciatura en Informática y Desarrollo de Software

v.2014

Renderizado
 El renderizado es el proceso de generar una imagen a
partir de un modelo, usando una aplicación de
computadora.
 El modelo es una descripción en 2D o 3D, de objetos, en
un lenguaje o estructura de datos estrictamente
definidos.
 El modelo debería contener geometría, punto de vista,
textura e información de iluminación.
 La imagen resultado de la renderización es una imagen
digital o raster.

Ing. César Omar Aranda 2

Ing. César Omar Aranda 1

Programación Avanzada
Universidad del Aconcagua

El Bucle de Juego
 El bucle de juego representa la estructura de control principal de
cualquier juego y gobierna su funcionamiento y la transición entre
los distintos estados del mismo y para los diferentes subsistemas.
 Permite que cada subsistema o componente se actualice
periódicamente según su propia necesidad (temporización),
mientras el juego se encuentra en ejecución:
 el motor de renderizado,
 el sistema de detección y gestión de colisiones,
 el subsistema de juego,
 el subsistema de soporte a la Inteligencia Artificial.
 Debe proveer cierto sincronismo
 Garantizar una sensación de realismo adecuada.

Ing. César Omar Aranda 3

Renderizado vs. Actualización

 Lo ideal: invocar la actualización y el dibujado en
pantalla el mismo número de veces por segundo
 Teléfono móvil: 20-25 veces por segundo (mínimo)
 Consolas: 25-30 veces por segundo (mínimo)
 Ejemplo:
 Ajustando el tiempo de bucle a 25 FPS
 Tiempo de Renderizado: 1000/25 = 40 ms
 Obliga a que la Actualización se realice en 40 ms o menos
 En caso contrario, el juego “irá más lento”

Ing. César Omar Aranda 4

Ing. César Omar Aranda 2

Programación Avanzada
Universidad del Aconcagua

El bucle y el tiempo
bool game_is_running = true;
while( game_is_running ) {  El bucle de la izquierda …
update_game(); • es el bucle de juego más simple,
display_game(); • ignora el tiempo
}

 FPS (Frames Per Second)

 Es el número de cuadros dibujados por segundo, o el número de
veces por segundo en que se llama a la función display_game().
 UPS (Updates Per Second) o Game Speed
 Es el numero de veces que el estado del juego se actualiza por
segundo, o el número por segundo en que se llama a la función
update_game().

Ing. César Omar Aranda 5

FPS=f(Vjuego constante)

 El juego funciona a velocidad fija

 Considerando el caso del ejemplo anterior a 25 FPS
 Es una solución sencilla
 Implementar una función de repetición (replay) en este tipo de bucle
principal es fácil.
 Si el Hardware es Lento y no puede soportar los FPS definidos, el
juego se ralentiza y a veces resulta “injugable”.
 Si Hardware es Rápido, se desperdician muchos ciclos de reloj, se
pierde gran parte de la calidad visual de los objetos, especialmente
con los objetos que se mueven rápidamente, y se desperdicia la
capacidad de una mejor calidad gráfica.

Ing. César Omar Aranda 6

Ing. César Omar Aranda 3

Programación Avanzada
Universidad del Aconcagua

Vjuego =f(FPS variable)

 El juego funciona a velocidad variable

 Los FPS dictan la velocidad del juego varían en función de las condiciones
gráficas del juego
 El juego se actualiza con la diferencia de tiempo del último frame.
 El juego funciona lo más rápido que el hardware se lo permite
 El juego se vuelve un poco más complicado, porque ahora hay que
considerar la diferencia de tiempo en la función update_game().
 Si el Hardware es Lento puede llegar a causar retrasos en ciertos
momentos, cuando el juego se vuelve "pesado". Esta bajada de
frames afecta al tiempo de captación del input, y por tanto, al tiempo
de reacción del jugador. La actualización del juego también sufrirá
retrasos y el estado del juego será actualizado a trozos.
 Si Hardware es Rápido, la propagación de errores de cálculo en las
operaciones de punto flotante podrían volverse muy significativas
(visibles).
Ing. César Omar Aranda 7

Vjuego constante y máximo FPS posible

 Alternativa al primer caso donde la velocidad del juego es constante.

 Aplicable cuando, tanto la velocidad del juego como su framerate
bajan al ejecutarse en hardware lento.
 La solución consiste en seguir actualizando el juego a la misma
velocidad, pero reduciendo el framerate de renderizado.
 El juego se actualizará a una velocidad constante definida de N
veces por segundo, y la renderización se hace tan rápido como sea
posible.
 Si la renderización se realiza más de N FPS, algunos frames serán
los mismos, por lo que, los frames visuales reales (distintas
actualizaciones) se mostrarán a un máximo de N FPS.
 Cuando los FPS del render se reducen por debajo de N, el juego se
vuelve lento, incluso los FPS del render pueden variar entre un
contexto y otro diferente.
Ing. César Omar Aranda 8

Ing. César Omar Aranda 4

Programación Avanzada
Universidad del Aconcagua

Vjuego constante y FPS variable

 Es una solución que busca que el juego funcione más rápido en

hardware lento y sea visualmente más atractivo en hardware rápido.
 Las entradas del jugador, IA y la actualización del estado del juego
tienen suficiente con 25 frames por segundo.
 El renderizado, necesita ser tan rápido como el hardware pueda
soportar.
 Un framerate lento no debería interferir con la actualización del jueg
 La implementación de update_game() sigue siendo sencilla,
mientras que la función display_game() será más compleja.
 Debe implementarse una función de predicción e interpolación, que
ofrezca (cree) movimientos rápidos más constantes entre frames.
 En un Hardware Rápido, entonces se produce un suavizado de los
cambios entre frames.

Ing. César Omar Aranda 9

Esquema general del GameLoop

Añadir un retardo o pausa final

para ajustar la velocidad de la
acción de igual manera a todas
las plataformas.

Ing. César Omar Aranda 10

Ing. César Omar Aranda 5

Programación Avanzada
Universidad del Aconcagua

Ejemplo: Pong (C/C++)

Ing. César Omar Aranda 11

Ejemplo básico con Java

Generalmente realizan/manejan
la Lógica de Dominio del Juego
Ing. César Omar Aranda 12

Ing. César Omar Aranda 6

Programación Avanzada
Universidad del Aconcagua

Arquitecturas del GL (1)

 Tratamiento de Mensajes en Windows
 Message Pumps
 El planteamiento de este esquema consiste
en atender los mensajes del propio sistema
operativo cuando llegan, interactuando con el
motor de juegos cuando no existan mensajes
del sistema operativo por procesar. En ese
caso se ejecuta una iteración del bucle de
juego y se repite el mismo proceso.

Ing. César Omar Aranda 13

Arquitecturas del GL (2)

 Retrollamadas
 Callbacks
 El planteamiento de este
esquema consiste en asociar
una porción de código para
atender un determinado evento
o situación. Este concepto se
puede asociar a una función en
particular o a un objeto. En este
último caso, dicho objeto se
denominará callback object,
término muy usado en el
desarrollo de interfaces gráficas
de usuario y en el área de los
sistemas distribuidos..
Ing. César Omar Aranda 14

Ing. César Omar Aranda 7

Programación Avanzada
Universidad del Aconcagua

Arquitecturas del GL (3)

 Tratamiento de eventos
 En el ámbito de los juegos, un evento representa un cambio en
el estado del propio juego o en el entorno.
 Ejemplos: evento externo como el pulsado de un botón del
joystick, o internos, como la reaparición o respawn de un NPC
en el juego.
 Este planteamiento está muy estrechamente relacionado con el
patrón Observer.
 El tratamiento de eventos es un aspecto transversal a otras
arquitecturas diseñadas para tratar el bucle de juego, por lo que
es bastante común integrarlo dentro de otros esquemas más
generales.
 Muchos motores de juegos incluyen un subsistema específico
para el tratamiento de eventos.
Ing. César Omar Aranda 15

Arquitecturas del GL (4)

 Estados y ciclos de vida
 Se basan en el hecho de que los juegos se pueden dividir en
una serie de etapas o estados que se caracterizan no sólo por
su funcionamiento sino también por la interacción con el
usuario o jugador.
 Se pueden usar máquinas de estados finitos o autómatas, para
modelar los distintos comportamientos de un personaje o del
escenario.

Ing. César Omar Aranda 16

Ing. César Omar Aranda 8

Programación Avanzada
Universidad del Aconcagua

Gestión de Estados en Java

Ing. César Omar Aranda 17

Eventos, Actualizacion y Renderizado

Ing. César Omar Aranda 18

Ing. César Omar Aranda 9

Programación Avanzada
Universidad del Aconcagua

Bibliografía
 Principal
 DEITEL, F. y DEITEL, H. (2008). Cómo programar en Java. 7ma edición.
Capítulo 12. México: Prentice Hall. Pearson Education.
 KNUDSEN, J. (1999). Java 2D Graphics. EEUU: O’Reilly y asociados.
 FROUFE QUINTAS, A. (2008). Java 2: Manual de usuario y tutorial. 5ª edición.
México: Alfaomega.
 KLAWONN, F. (2008). Introduction to Computer Graphics, using Java 2D and 3D.
Inglaterra: Ed. Springler-Verlag.
 Referencias Complementarias

 https://vgafib.com/wiki/Bucle_principal
 http://dewitters.koonsolo.com/gameloop.html
 http://javapragmatico.blogspot.com.ar/2009/04/sobre-java-pragmatico.html
 http://www.aprendeaprogramar.com/mod/resource/view.php?id=177
 http://www.chuidiang.com/java/graficos/seno/seno.php

Ing. César Omar Aranda 19

Ing. César Omar Aranda 10