ButterFlyDevs / BrainStudio

Repositorio de la segunda aplicación móvil para Programación de Dispositivos Móviles
GNU General Public License v2.0
2 stars 0 forks source link

Creación algoritmo juego FASE2 #6

Closed juanAFernandez closed 9 years ago

juanAFernandez commented 9 years ago

En la fase2 del juego (que tiene tres niveles) se usan figuras para rellenar la matriz. El usuario tiene que recordar las figuras y después se le pregunta por una para que la marque en la matriz. Hay que crear un algoritmo que haga eso para los tres niveles (distintos tamaños de grid).

JA-Gonz commented 9 years ago

Juego 2 ya es prácticamente un copy-paste de juego1, salvo algunas correcciones que he hecho por necesidad del nivel. Espero tener para esta tarde el algoritmo de juego y la clase "Juego2"

juanAFernandez commented 9 years ago

Perfecto! El 16/06/2015 10:30, "José Antonio González Cervera" < notifications@github.com> escribió:

Juego 2 ya es prácticamente un copy-paste de juego1, salvo algunas correcciones que he hecho por necesidad del nivel. Espero tener para esta tarde el algoritmo de juego y la clase "Juego2"

— Reply to this email directly or view it on GitHub https://github.com/ButterFlyDevs/BrainStudio/issues/6#issuecomment-112334042 .

JA-Gonz commented 9 years ago

Algoritmos hechos (a falta de comprobarlos) tanto de rellenar la matriz solución con figuras (se rellena toda la matriz) como de comprobar que la matriz respuesta que da el usuario es correcta o incorrecta. También he metido unos iconos de figuras. Me falta comprender las animaciones para poder representar el juego correctamente. Me pondré mientras a programar la clase Juego2, le daré esta batalla por ganada, mañana volveremos con refuerzos ;)

JA-Gonz commented 9 years ago

Aunque llevo toda la mañana peleandome con la animación, voy a darle este asalto por ganado y seguiré esta tarde. No obstante despues de muchísimo probar en la app y romper la animación, el grid, o dejarlo igual de mal todo, al menos he llegado a la conclusión de que la solución al problema de lentitud de la animación va a tener que pasar por la creación de una hebra nueva (o varias) que hagan el procesamiento, mientras que en la principal se sigue ejecutando la animación. O también podemos probar la inversa, aunque este método es bastante más complicado.

Un mini tutorial a seguir: http://developer.android.com/guide/components/processes-and-threads.html

En stackoverflow, prácticamente casi todas las preguntas que he visto relacionadas con el problema que tengo, los usuarios responden diciendo que es necesario crear otra hebra (como mínimo)

http://stackoverflow.com/questions/28861700/skipped-69-frames-the-application-may-be-doing-too-much-work-on-its-main-thread

Esto puede suponer que nuestra app ya no sea capaz de llegar a los móviles más viejos (por el tema de un doble procesamiento simultáneo). Pero vamos, no creo que haya ya muchos móviles con un solo procesador.

También veré si nada de esto tiene solución o es demasiado complicada, ver como podemos cambiar las animaciones. Quizás es otro punto a atacar.

JA-Gonz commented 9 years ago

Después de 2 días peleandome con las hebras (y que he conseguido que funcione, no he hecho push del proyecto por que el resultado no mejoraba o no mejoraba lo suficiente como para dejarlo final, aunque ten por seguro que haré un tuto de hebras en Android), he decidido hacerme un café y pararme a pensar.

Tengo el problema de una animación extremadamente lenta, y que incluso el propio depurador me dice que está dejando de pintar frames por demasiado trabajo en la hebra principal. ¿Y si en lugar de figuritas, cargara colores? (olvidándome de hebras e historias).

El switch de carga del background de cada boton pasa a tener este aspecto (en uno de sus casos)

            case TRIANGULO: botones[i].setBackgroundColor(Color.YELLOW);break;
            //botones[i].setBackgroundResource(R.drawable.triangulo); break;

Es decir, que carga un color, no una imagen.

El resultado es una animación fluida, clara, bonita (después de bajar el contador a 0 en el XML de repetición), y sin ningún mensaje de escape de frames. ¡¿Pero que demonios?!

He llegado a la conclusión de que en cada frame a pintar, internamente Android llama a su memoria del teléfono (que imaginamos mas lenta) en busca de esa imagen a cargar en el background del botón. Y el resultado es una animación a trompicones, por que tiene que llamar 12 veces por cada frame. Algo muy costoso computacionalmente.

En definitiva, para éste y otros juegos donde no haya solo colores de fondo de botones (sino imágenes), creo que no nos sirve la función setBackgroundResource. Al menos, no de la forma que la he estado usando. Quizás hay una opción de tener la imagen cargada en memoria y que pinte esa imagen. Sigo trabajando en ello.

El único consuelo es que voy a hacer en dos ratos el tutorial de Hebras para Android, por que por el resto ha sido tiempo perdido :(