AssetManager in LibGDX

Question

I am trying to use the AssetManager class in LibGDX and I understand how it works but I am trying to implement a loading screen. I have followed the AssetManagerTest.java file here, but I am having a hard time trying to figure out how to get it to work correctly. Can someone point me in the right direction? My goal is to load the assets (textures, sounds, fonts, ... etc) and update a bar with the percentage complete on the screen. I don't understand the ResolutionFileResolver and the Resolution[] in the link I provided. What are they for? My goal is to support a static class that can give me access to all of the assets I need in my game from any screen. Is there a preferred method to do this? Thanks.

Answer 1

After looking at the source for ResolutionFileResolver as well as the other 'resolvers', I think it's just a way of loading textures that best match the screen resolution, but the match is just based on filename patterns.

So in AssetManagerTest, he's got textures for screen sizes 320x480, 480x800, and 480x854. It looks like each group of textures should be in a directory called ".320480" or ".480800" or ".480854" (although the name can be anything you want, like "low", "high", and "wide" if those are your directories), and he specifies all this info when creating the array of resolvers on line 56 of the test.

The advantage of doing all this stuff is that when he calls manager.load(), he just picks out a filename like "data/animation.png". Then the resolver finds the pack of textures that most closely matches the current screen resolution, and loads that one.

I think the rest of the example should be pretty clear, at least for the basics of AssetManager. Create a manager, set the loader, call load(), call get() to use it, and then call unload() when done.

For updating a progress bar, you'll just need to do that manually after each call to load.

And using a static class for asset management is certainly one possibility. Another similar option is to just use a singleton. It has its haters, but I think in a simple project in a garbage collected environment it should be ok, although it's about the same as a public static.

Another option--maybe the best?--is to use a base class that has a static copy of your game globals, and then all other game classes inherit from it. This is the approach used in Replica Island. See the base class and the object registry. Replica Island is well commented and worth checking out for Android & Java games.