Libgdx Cross-platform Game Development Cookbook

More Information
  • Wield the power of the 2D graphics API; get to grips with textures, atlases, particles, fonts, and shaders
  • Learn how to build and render LibGDX bitmap fonts
  • Manage input from different devices, including touch, keyboard, mouse, gamepad, and accelerometer
  • Increase player immersion with the Libgdx audio API
  • Quickly design maps with an editor and load them directly into your game
  • Exploit the 2D stage features to build great user interfaces
  • Create amazing physics simulations with Box2D
  • Master the deployment process and reach a wide audience

Libgdx is a very popular open source, cross-platform, Java-based game development framework built for the demands of cross-platform game development. It simply lets game developers write lines of code just once which you can then deploy to a huge range of platforms, including Windows, Mac, Linux, Android, iOS, and browsers.

From the basics aspects of LibGDX to more advanced issues, this book features practical solutions to a wide range of 2D game development tasks and challenges. Beginning with an overview of the framework and project creation, the book moves on to the 2D graphics API that enables you to create efficient and visually rich games. With tips and guidance on building and rendering LibGDX bitmap fonts you can be confident you'll give your projects a quality visual experience. You'll also find more recipes on input detection and audio and file handling, as well as details of how to make use of amazing features such as Box2D rigid body physics, lighting, and artifical intelligence techniques to name a few. With further insight on how to modify Libgdx to suit your needs and how share your creation with the world, this game development cookbook is a vital resource for anyone looking for a simple solution to cross-platform development.



Read an Extract from the book

Asynchronous asset loading

Imagine what will happen if a Triple-A RPG game has to load a graphically awesome world where the final boss is waiting for you while spitting tons of different hungry flunkies. That’s a 10 second loading time with a decent machine. The player is freaking out because of the hype generated by his friends. You cannot disappoint him with an eternal black screen, or he will panic thinking the game is broken. However, if you satisfy him a little by providing a dynamic loading screen where some kind of teaser is revealed, his adrenaline will start pumping. What's the moral of the story? The player needs to receive continuous feedback. Nonresponsive interfaces are not okay.

The sample shown in this recipe will illustrate how to take advantage of loading resources asynchronously by displaying a reactive loading screen while our AssetManager class is working on it.

How to do it…

This sample is hosted by the file. In order to build a reactive loading screen, you must make the player feel that something is changing and, at the same time, show the progress of the change, making its end clear. To this purpose, a progress bar will do the trick.

Next, we will explain a very easy and simple way to develop a progress bar by rendering a gray base image container; on top of this, we have the real progress bar image setting its width to the current progress of load.

First and foremost, let's declare all variables that will go into action:

private Texture progressBarImg, progressBarBaseImg;
private Vector2 pbPos;
private AssetManager manager;

The trivial matter is that progressBarBaseImg will contain the gray base image bar; progressBarImg will contain the front width-changing bar. Since the only dynamic element on screen will be the related-to-progress width of the actual loading bar, it is a good idea to cache its coordinates, pbPos.x and pbPos.y, instead of calculating them for every frame.

The next figure illustrates what we intend to do:

Within the create() method, once AssetManager is instantiated, just load the aforementioned textures:

manager.load("data/progress_bar.png", Texture.class);
manager.load("data/progress_bar_base.png", Texture.class);

The images used to draw the progress bar need to be loaded synchronously before starting to bring the required resources for the next screen from the disk, on another thread. Consequently, we should not forget to write the following line of code:


Then, retrieve the textures:

progressBarImg = manager.get("data/progress_bar.png");
progressBarBaseImg = manager.get("data/progress_bar_base.png");

It is a good idea to display elements relatively to other components on the screen in order to fit any resolution. In this case, the loading scene will contain a Libgdx logo that will be placed in the center, taking into account the application's width and height. The progress bar will be positioned below the logo:

pbPos.set(logoPos.x, logoPos.y– (logo.getHeight());

To close the create() method, queue the real bulk of resources needed for the next screen:

manager.load("data/1.png", Texture.class);
manager.load("data/2.png", Texture.class);

The next step is to draw the progress bar, but this is not that simple. To carry out the visual effect, it is necessary to know the current loading progress. This is achievable in two different ways. The first way is more laborious, but also more interesting. It starts by adding a private int loaded field to your class. Add the following code to your create() method after calculating the coordinates of the progress bar:

loaded = manager.getLoadedAssets();

The reason to do this is to know how many assets have been loaded only for the loading screen. It allows us to get the current progress by using the following code:

int currentAssets = manager.getLoadedAssets();
 float percent = Math.min(1, currentAssets – loaded) /
((float) (currentAssets + manager.getQueuedAssets() – loaded));

As you can see, we introduced a new method called getQueuedAssets() that returns the number of currently queued assets.

The second way of getting percent is as follows:

float percent = manager.getProgress();

Regardless of the way you choose, percent will store a float between 0.0 and 1.0 with the loading progress. Now that the real-time value is known, all we have to do is render, but with a slightly different method from SpriteBatch:

void draw(Texture texture, float x, float y, float width, float height)

Apply the following code to the context and at the end of render():

batch.draw(progressBarBaseImg, pbPos.x, pbPos.y);
batch.draw(progressBarImg, pbPos.x, pbPos.y,

Note that the order of drawing is important to keep the progress bar rendered on top of the base container.

To conclude, still within render() and right after drawing the progress bar, you must make sure that the loading screen does not last forever and it gives way to the next screen.

The update() method will return true, once the progress bar reaches 100 percent:

if(manager.update()) {
   // Go to next screen

In the meantime, you have a wide range of possibilities to keep the player's attention. Lots of games understand the loading screen as a fantastic moment to show some gameplay tips or relate story bits. Other games such as Call of Duty prefer to take advantage of the space by displaying a mission briefing. FIFA titles offer an interactive training mode; classic load screens such as Metal Gear Solid 4's warns against smoking.

How it works…

Reading a resource from disk is slow, and during the time the computer takes to retrieve
a few of them, it can keep executing other code so that the load is made in another thread.

It is important to make two key concepts highly bound to this chapter clear:

  • Synchronous: Here, the application will wait for the load process to finish in order to carry on with the execution. All the action takes place on the rendering thread.

    Note that the black area in the preceding diagram is drawn to make the diagram simpler to understand, but it does not mean that the screen has to be black during synchronous asset loading. It will just keep the last rendered scene.

  • Asynchronous: Here, some parts of the asset are loaded on a worker thread, and the OpenGL descendant part is performed on the rendering thread. Most of the load is managed in the background so that it is a nonblocking task, keeping your application responsive. The example scenario is illustrated in the following figure:

Every asset that you queue into the manager is treated as a task, or called AssetLoadingTask in Libgdx. It implements the AsyncTask interface that entails a public call() method to submit it to AsyncExecutor. This class is in charge of allowing asynchronous executions of AsyncTask instances on a worker thread.

The AsyncExecutor class internally relies on the java.util.concurrent package to manage threads. It is widely used in concurrent programming.

The AssetLoadingTask class is ruled by its update() method, which, if the asset is asynchronously loaded, calls the loadAsync(...) function from the loader on a separate thread. At the end of its execution, the rest of the asset is loaded on the rendering thread by calling loadSync(...).

The TextureLoader class is a good example of loading the asset, making use of both methods. The asynchronous concept loads the pixel data, whereas Texture is created synchronously. Do not hesitate to take a look at its source code, which is available on

There's more…

So far, we have covered the usual flow of managing assets in a general application, but in some cases, you might want to offer support to pause and resume the app. It means that some assets must be reloaded whenever the user restarts playing, since OpenGL-context was lost. This issue is seen in Android when sending the app to the background by pressing the home button or receiving an incoming phone call, causing all OpenGL-associated resources (such as textures) to be deleted.

Resuming the app can take a few seconds, so why not give some feedback and say what the app is doing through a loading screen? You can carry out this once you have instantiated your AssetManager class and call the next function for each asset type:


Libgdx give us a resume() method when implementing the ApplicationListener interface. This is the place to locate your call to the loading screen and wait until update() returns true.

If you decide not to manage this scenario with AssetManager, all resources will be reloaded on the rendering thread, causing your app to be unresponsive for some seconds.

  • Gain an in-depth understanding of every Libgdx subsystem, including 2D graphics, input, audio, file extensions, and third-party libraries
  • Write once and deploy to Windows, Linux, Mac, Android, iOS, and browsers
  • Full of uniquely structured recipes that help you get the most out of Libgdx
Page Count 516
Course Length 15 hours 28 minutes
ISBN 9781783287291
Date Of Publication 29 Oct 2014


David Saltares Márquez

David Saltares Márquez is a C++ software developer at a top-tier financial data company. He was an Artificial Intelligence programmer at Crytek, UK, for two years, where he developed emergent systems for Homefront: The Revolution. He then moved to Sony Computer Entertainment Europe to work on multimedia applications for PlayStation 4. He is part of the Libgdx core team, works on small indie games in his spare time, loves game jams, and often delivers presentations at universities. Find out more about his work on his personal blog at

Alberto Cejas Sánchez

Alberto Cejas Sánchez is an indie game programming enthusiast who graduated with an MSc in Computer Science and whose work revolves around games and simulations across 2D/3D technologies with different target platforms. He has also worked on automatic game code generation tools.