Vamos a empezar por mostrar imágenes en pantalla, como dije. Lo que he hecho es que en el proyecto de Android he ido a la carpeta assets,
esa carpeta de la que ya te hablé anteriormente cuando te presenté la forma en la que creamos los proyectos. Y he dejado esta imagen que te voy a enseñar.
He tomado esta imagen, que a lo mejor te suena porque es la que te enseñé cuando vimos el proyecto en el capítulo 1. Con el juego más o menos terminado.
Y la he dejado aquí. Tú haz lo mismo con la imagen que te apetezca. Si quieres usar una pon una, si quieres usar otra pon otra. Pero lo importante es ponerla
y recordar el nombre. Vamos a ver cómo se puede representar por pantalla y cómo verla en el juego. Para ello lo que voy a hacer es crear una instancia
de una clase llamada Texture. '¿Por qué Texture, si es una imagen?' Es así como en libGDX se las llama a las imágenes, Textura,
porque es el nombre interno que usan las tarjetas gráficas para estas cosas. Las tarjetas gráficas, parece que no, pero son dispositivos complicados
que tienen que, no sólo dibujar píxeles, deben preparar polígonos, preparar vértices y hacer unas cosas complejas que no interesan,
es por eso por lo que usamos libGDX, pero libGDX como sabe que por dentro se le llaman Texturas lo llama exactamente igual sin ningún tipo de problema.
Como soy una persona con poca imaginación a mi imagen la voy a llamar 'minijoe', porque realmente es como se llama la imagen. Ahora la importo y
esto es importante como ves hay dos clases que se llaman Texture. Siempre que tengas dudas, importa la que empieza por com.badlogic.gdx,
porque esta es la de la textura de libGDX. Si importas una que no es la de libGDX seguramente tengas problemas, así que asegúrate, en caso de duda,
que lo que estás importando sea una clase que pertenezca a este paquete: com.badlogic.gdx. Una vez que esté lista, puedo hacer dos cosas. Una, cargarla, y dos,
representarla. Por eso la he puesto como campo, porque me interesa usarla tanto en create para cargarla como en render para renderizarla.
Voy a ir primero a la parte de cargar, y para ello es bastante sencillo. Yo uso el constructor de Texture. Tienes un montón de formas de llamar al constructor.
Me interesa la más simple de todas, la que únicamente proporciona una ruta en forma de cadena de caracteres, como minijoe.png, que es como se llama mi imagen.
Si la has llamado pepito.png, pon pepito.png. Si está en una subcarpeta, pones el nombre de la subcarpeta, barra, como se llame.jpg. Os recomiendo PNG
porque se ve bien y pesa poco en comparación con los JPG, porque los JPG se ve luego borroso, no se ve bien. Usa siempre PNG si te es posible.
Una vez que ya lo tengo, tengo que representarlo. Seguro que hay un método para representar cosas, ¿no? Pues no. Porque representar una textura
es más complicado de lo que parece. Aunque no se note, porque dirás 'tengo un móvil potente, no se nota'. Hay que darle una serie de comandos
a la tarjeta gráfica que hacen que pierda rendimiento, entonces normalmente cuando dibujas texturas no quieres dibujarlas una a una, sino dibujarlas de golpe,
porque está comprobado que representar una textura en pantalla tarda lo mismo que representar 50, que es bastante en términos de microsegundos.
Así que en lugar de simplemente pedir que 'muestre esto', 'luego esto', 'luego esto', con libGDX se usa una estructura que sirve para decir 'a ver,
ya que va a tardar hacemos una cosa: di lo que quieras dibujar y cuando estés listo lo dibujo todo de golpe'. Y así es más rápido. Probablemente alguien diga
es una tontería, son microsegundos'. Pero cuando hayan decenas de texturas cargadas esto será una diferencia. Esta clase de la que hablo se llama SpriteBatch,
y como su propio nombre indica trabaja con texturas por lotes, que es como lo llamaríamos en español. A esta clase se le pide que dibuje esto, esto,
y esto. Y cuando esté listo, manda los comandos de golpe y tarda muchísimo menos. Al igual que la textura, se le debe iniciar en el método create.
Y una cosa de la que no he hablado pero que es importante, es el tema de liberar recursos. Si no liberamos estos recursos cuando cerremos el juego,
se quedarán en la tarjeta gráfica, sobre todo la textura, y eso no se quiere porque el juego contaminaría la memoria de vídeo y hará que el rendimiento
del teléfono baje. Así que por favor, por favor, cuando dejes de usar una cosa, libera sus recursos. Para liberar sus recursos hay un método llamado dispose,
que es otro método de ApplicationAdapter, y que se ejecuta el último de todo cuando se va a cerrar el juego. Aquí hay que liberar todo tipo de recursos
que se hayan usado para que no se queden perdido vagando en la memoria de vídeo o en la memoria. En el método dispose liberaremos la textura
y el SpriteBatch. Simplemente llamamos al método dispose de minijoe y al método dispose de SpriteBatch. Como ves, como son cosas liberables,
tienen una llamada a dispose. Todo lo que sea liberable tendrá una llamada a dispose. Algunas cosas no son liberables, porque se eliminan solas,
si son Java puro y duro. Eso no se tendrá que liberar. Pero todo lo que sea disposable, hay que liberarlo. Porque no quieres fastidiar el rendimiento
del teléfono ni el rendimiento del ordenador por culpa de texturas que se hayan quedado ahí. Y ahora, a dibujar esto por pantalla.
