AssetManager in LibGDX

Question

Sto cercando di utilizzare la classe AssetManager in LibGDX e capisco come funziona, ma sto cercando di implementare una schermata di caricamento. Ho seguito il file AssetManagerTest.javahere, ma sto facendo fatica a cercare di capire come farlo funzionare correttamente. Qualcuno può indicarmi la giusta direzione? Il mio obiettivo è caricare le risorse (trame, suoni, caratteri, ... ecc.) E aggiornare una barra con la percentuale completa sullo schermo. Non capisco lo ResolutionFileResolver e lo Resolution[] nel link che ho fornito. A cosa servono? Il mio obiettivo è supportare una classe statica che possa darmi accesso a tutte le risorse di cui ho bisogno nel mio gioco da qualsiasi schermata. C'è un metodo preferito per fare questo? Grazie.

Answer 1

Dopo aver esaminato la fonte per ResolutionFileResolver e gli altri "resolver", penso che sia solo un modo di caricare le trame che meglio si adattano alla risoluzione dello schermo, ma la corrispondenza si basa solo sui modelli di nome file.

Quindi in AssetManagerTest, ha trame per dimensioni schermo 320x480, 480x800 e 480x854. Sembra che ogni gruppo di trame debba trovarsi in una directory chiamata ".320480" o ".480800" o ".480854" (anche se il nome può essere qualsiasi cosa tu voglia, come "basso", "alto" e "largo" se queste sono le tue directory) e specifica tutte queste informazioni quando crea la matrice di resolver su line 56 del test.

Il vantaggio di fare tutto questo è che quando chiama lo manager.load(), sceglie solo un nome di file come "data/animation.png". Quindi il resolver trova il pacchetto di trame che si avvicina di più alla risoluzione dello schermo corrente e lo carica.

Penso che il resto dell'esempio dovrebbe essere abbastanza chiaro, almeno per le nozioni di base di AssetManager. Creare un gestore, impostare il caricatore, chiamare load(), chiamare get() per utilizzarlo e quindi chiamare unload() al termine.

Per aggiornare una barra di avanzamento, è necessario farlo manualmente dopo ogni chiamata da caricare.

E l'utilizzo di una classe statica per la gestione delle risorse è certamente una possibilità. Un'altra opzione simile è usare solo un singleton. Ha i suoi nemici, ma penso che in un semplice progetto in un ambiente garbage collection dovrebbe essere ok, anche se è quasi come una statica pubblica.

Un'altra opzione - forse la migliore? - consiste nell'utilizzare una classe base con una copia statica dei globali di gioco, quindi tutte le altre classi di giochi ereditano da essa. Questo è l'approccio utilizzato in Replica Island. Vedi lo base class e lo object registry. Replica Island è ben commentata e vale la pena di verificare per Android giochi Java &.