Y es que, por mucho que agreguemos actores, si nuestro actor no tiene ningún tipo de comportamiento ni tiene definida ninguna operación de cómo se dibuja,
no vamos a ver nada por pantalla. Es cierto que cuando ejecutamos el juego y tenemos los actores preparados y le pedimos al escenario que se dibuje,
lo que ocurre es que se dibuja el escenario, pero como no se dibuja nada por pantalla no vemos nada. Nos interesa que el actor se dibuje. Y el primer problema es:
yo tengo que mostrar una imagen por pantalla y debo cargarla en algún punto… ¿cómo la cargo? primera solución, que no tiene por qué ser la mejor.
ActorJugador es una clase que se instancia siempre en show(), es decir, cuando ya suponemos que libGDX está iniciado. Podríamos probar a
crear un campo de tipo Texture dentro de ActorJugador, y vamos a meter en el constructor que cargue esa textura. Por ejemplo, jugador = new Texture(“minijoe.png”).
Con esto ya tendría mi textura cargada, y podría decir “esto funciona”, por ejemplo batch.draw(jugador). ¿Dónde lo dibujo? Donde esté colocado.
¿Cómo saco las coordenadas? Con getX(), método hermano a setX(), y getY(), método hermano a setY(). Aparentemente si yo esto lo ejecuto, sí que se va a mostrar
mi textura del jugador. Pero tenemos un problema: alguien ha olvidado definir el método dispose, y ahora cuando yo cierro esto tenemos a un MiniJoe
encerrado en la tarjeta gráfica del ordenador sin poder salir… lo cual es un problema porque imaginad que lo hago con un montón de texturas o personajes.
Igual no es la mejor forma de descargar recursos porque vamos a dejar la memoria de vídeo del móvil un poco sucia. Por otro lado esto tiene otro inconveniente.
Imaginad que me da por cambiar el nombre de la textura o introduzco el segundo o el tercer Minijoe. ¿Cómo le digo al ActorJugador que debe dibujarse
con una u otra textura? O si hago lo mismo con pinchos y quiero mostrar varias veces el actor, unos pinchos, por cada instancia tengo que instanciar una textura.
Si yo cargo 10 pinchos, tendré que cargar la textura 10 veces, y eso sigue siendo un desperdicio. Entonces, igual que la propia clase Actor se ocupa de
cargar recursos no está bien. Un patrón interesante aquí es, en vez de usar eso, la textura la vas a pasar como parámetro. Aquí lo que haces simplemente es que,
this.setJugador = jugador. Y ya dejamos que la textura me la pases por fuera, en MainGameScreen, de modo que si en algún momento tengo que cambiar texturas u cosas,
lo tengo centralizado en el mismo código sin tener que ir actor por actor revisando cada uno, sobre todo porque puede que me deje código sin inicializar y falle.
Cargaría mi textura, y se la pasaría como parámetro. Debo cambiar de nombre, pero… Pero esto no arregla el problema del todo porque sigue siendo necesario
llamar al dispose. En este caso lo que voy a hacer es, crear un campo, como de costumbre, y finalmente en el hide llamar a texturaJugador.dispose().
En este caso al menos no estaremos contaminando la memoria de vídeo, aunque puede que no sea lo más óptimo, porque si bien tenemos una clase
llamada BaseScreen, una interfaz llamada Screen, pero Screen ya tiene un método llamado dispose(), y estamos constantemente llamando al método dispose().
Necesitamos una solución más eficiente, y pasa por usar el propio método dispose(), por ejemplo llamando a texturaJugador.dispose(),
aunque esto introducirá problemas porque como os dije antes cada vez que entre a la pantalla ahora se cargará una nueva textura. La vieja textura que se pierde
al asignar la variable se pierde sin poder disposear. En este caso debo darme cuenta que cuando construyo la clase MainGameScreen,
ya tengo la posibilidad de crear código aquí, en su constructor. Del mismo modo que puedo instanciar código en el constructor de jugador, porque libGDX
ya está encendido y la textura se carga en el momento que yo cargo la pantalla, se desvanece en el momento que elimino la pantalla. Esto tampoco es lo más óptimo,
pero por ahora voy a contar más sobre Scene2D y luego os hablaré de una clase llamada AssetManager para que no tengamos que tener igualmente nuestras pantallas
llenas de constructores de nuevas texturas sino que pueda haber una clase centralizada que se ocupe de ellas. Pero por el momento con esto podemos representarlo.
