Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA VI: Frecuencia en fps de la aplicación en susdistintos estados.(a) BatGhost(b) HulkGhostMilestone GeekPhone Galaxy SEstado Cám Ogl Cám Ogl Cám OglImagen +síntesis 3,25 15 2,75 8 4,1 35Imagen +morphing 2,75 8 2,5 3 3,6 23Síntesis 30 21 44Morphing 28 17 41(c) EmGhostFig. 5: Modelos tridimensionales.(d) SuperGhostFig. 6: Detección de eventos en el juego.información obtenida de la cámara y ubican los objetosvirtuales usando principalmente esa fuente deinformación. En vista de los resultados obtenidos ennuestro análisis, este tipo de aplicaciones se hacen actualmenteinviables en los dispositivos Android probados.Por último, en cuanto a la síntesis de gráficos, seha observado que existen limitaciones de tamaño yen la complejidad del modelo que se puede visualizar.Por los resultados obtenidos en las pruebas realizadas,se ha comprobado que el hardware gráficoresulta lo suficientemente potente como para representarmodelos no muy complejos usando texturase iluminación. Por ello, para la aplicación se usarántodas las capacidades estudiadas para intentar crearunos modelos gráficos atractivos pero limitando lacomplejidad del modelo para obtener tiempo real.III. Juego de RA en un sistema AndroidLa aplicación que se pretende crear es un juegoque, analizando la imagen tomada por la cámara entiempo real, determine la presencia de enemigos queel jugador deberá cazar. Para buscar un enemigo sedebe encontrar un objeto real de un color determinado.Cada tipo de enemigo aparece ante un tipo deevento distinto. Con ese objetivo del juego, un primerrequisito será mostrar elementos virtuales sobrela imagen obtenida de la cámara. Dichos elementosdeberán simular encontrarse en el mundo real, por loque ante un movimiento de la cámara ellos deberánmoverse también. Se pretende cazar los enemigos,que reaccionan de manera distinta ante cada disparo.Cuando se da caza a un enemigo, se obtiene unarecompensa en forma de puntos y de un número aleatoriode disparos extra. Por otra parte, si un enemigonos golpea perderemos una vida. Cuando nuestronúmero de vidas sea cero se perderá la partida.Existirán varios tipos de enemigos, con distintosmovimientos y características de rendering cada unode ellos: BatGhost (figura 5a), fue diseñado comoejemplo de animación por partes. Sus alas se muevenindependientemente dando sensación de aleteo,HulkGhost (figura 5b) fue diseñado como ejemplode animación mediante técnicas de morphing consistenteen un parpadeo, abriendo y cerrando su ojo,EmGhost (figura 5c) se diseñó pensando en crear unenemigo que rebotase, saltando por encima del jugadory SuperGhost (figura 5d) se diseñó con el objetivode crear un enemigo que se moviese en torno al jugador,mientras se acerca cada vez más a él.A la hora de ejecutar la síntesis de gráficos medianteOpenGL ES, el sistema operativo se encargaautomáticamente de hacerlo en un hilo distinto alprincipal, permitiendo de este modo desacoplar suejecución. Siguiendo las recomendaciones dadas porlos desarrolladores de Android [16], se ha evitado lallamada a métodos a través de una interfaz, eliminandolas interfaces incluidas por motivos de facilitarla reusabilidad del código, por necesitar más tiempopara realizarse. Además se ha intentado en la mayormedida posible las reservas de memoria, evitandocrear objetos nuevos y utilizando en la medida de loposible tipos de datos primitivos.IV. Resultados experimentalesEn esta sección se presenta el rendimiento obtenidocon la aplicación en términos de fotogramas porsegundo. En la tabla VI se muestran los resultadosobtenidos calculando el rendimiento de los aspectoscríticos de la aplicación durante una serie de ejecucionestípicas.En el Motorola Milestone la frecuencia de procesadode imágenes de la cámara varía de los 3,25 fpscuando no se encuentran enemigos visibles a los 2,75fps cuando hay un enemigo animado con morphing.Por otra parte, la síntesis de gráficos presenta unaJP2011-623