AssetManager en LibGDX

Question

Estoy tratando de usar la clase AssetManager en LibGDX y entiendo cómo funciona, pero estoy tratando de implementar una pantalla de carga. He seguido el archivo AssetManagerTest.javahere, pero estoy teniendo dificultades para tratar de encontrar la manera de hacerlo funcionar correctamente. ¿Alguien me puede apuntar en la dirección correcta? Mi objetivo es cargar los activos (texturas, sonidos, fuentes, etc.) y actualizar una barra con el porcentaje completo en la pantalla. No entiendo el ResolutionFileResolver y el Resolution[] en el enlace que proporcioné. ¿Para qué son? Mi objetivo es apoyar una clase estática que me permita acceder a todos los recursos que necesito en mi juego desde cualquier pantalla. ¿Hay un método preferido para hacer esto? Gracias.

Answer 1

Después de ver el código fuente de ResolutionFileResolver, así como de los otros 'resolutores', creo que es solo una forma de cargar las texturas que mejor coinciden con la resolución de pantalla, pero la coincidencia se basa únicamente en los patrones de nombre de archivo.

Por lo tanto, en AssetManagerTest, tiene texturas para los tamaños de pantalla 320x480, 480x800 y 480x854. Parece que cada grupo de texturas debe estar en un directorio llamado ".320480" o ".480800" o ".480854" (aunque el nombre puede ser cualquier cosa que desee, como "bajo", "alto" y "ancho") si esos son sus directorios), y especifica toda esta información al crear la matriz de resolutores en line 56 de la prueba.

La ventaja de hacer todo esto es que cuando llama al manager.load(), simplemente selecciona un nombre de archivo como "data/animation.png". Luego, el resolvedor encuentra el paquete de texturas que más se aproxima a la resolución de pantalla actual y la carga.

Creo que el resto del ejemplo debería ser bastante claro, al menos para los conceptos básicos de AssetManager. Cree un administrador, configure el cargador, llame al load(), llame al get() para usarlo, y luego llame al unload() cuando haya terminado.

Para actualizar una barra de progreso, solo tendrá que hacer eso manualmente después de cada llamada para cargar.

Y utilizar una clase estática para la gestión de activos es ciertamente una posibilidad. Otra opción similar es usar solo un singleton. Tiene sus enemigos, pero creo que en un proyecto simple en un entorno recolectado de basura debería estar bien, aunque es casi lo mismo que una estática pública.

Otra opción - ¿quizás la mejor? - es usar una clase base que tenga una copia estática de tus juegos globales, y luego todas las otras clases de juego heredan de ella. Este es el enfoque utilizado en Replica Island. Vea el base class y el object registry. Replica Island está bien comentada y vale la pena echarle un vistazo para Android & juegos de Java.