LibGDX Tutorial 2: Hello World

26. September 2013


There is an old law, possibly predating the age of man, that all tutorials must start with Hello World.  I am nothing if not law abiding, so therefore let’s create a Hello World app.  Hello World is generally one of the simplest programs you can create, you simply display the words Hello World on screen.  Of course, there are always complications in life… that’s what makes it interesting!


To get started I created a simple project using the Project Setup tool we discussed in the prior tutorial.


We are going to jump in with the code in a second, but first let’s take a quick look at the code created by the project tool, gdx-setup-ui.  Your project should look like this:



Obviously your file names will vary depending on what you used during the project setup tool.  The key thing to note is the basics of how code is laid out.  The non-suffixed folder ( hello-world ) is where the shared code goes.  The –android, –desktop and –html folders are where platform specific code goes and hopefully you will have minimal need to use these.  I will look at them a bit closer in a few minutes, but for now it’s the file that we are interested in.  This is where a very important class called an ApplicationListener is implemented.  Here is the code I used:


package com.gamefromscratch.helloworld;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;

public class HelloWorld implements ApplicationListener {
    private SpriteBatch batch;
    private BitmapFont font;
    public void create() {        
        batch = new SpriteBatch();    
        font = new BitmapFont();

    public void dispose() {

    public void render() {       , 1, 1, 1);;
        font.draw(batch, "Hello World", 200, 200);

    public void resize(int width, int height) {

    public void pause() {

    public void resume() {


The first thing you may notice is… there’s no Main!  Well there is one and we will take a look at it in a second.  At the end of the day though, LibGDX is an event driven engine.  You implement an ApplicationListener and GDX calls a number of functions that you can respond to.  The render() method will be called each from, so if you want to, you can think of that as your event loop.  Otherwise there are functions that are called in response to various events, these include create, resize, pause and resume.  I imagine you can guess what event each one is in response to!


The bulk of our code is in create() and render().  In create() we allocate a new SpriteBatch, BitmapFont and set the font to the colour red.  SpriteBatch’ing is a common activity in 2D game engines built over 3D libraries, if you’ve used XNA you are used to it.  Basically behind the scenes, LibGDX is using OpenGL ( or WebGL depending on platform ) to do the rendering.  In OpenGL there is a fair bit of overhead in drawing … well, anything.  A spritebatch combines them all into a single operation to reduce the amount of overhead.  In a nutshell, it makes 2D rendering a great deal faster.  A BitmapFont is exactly what it sounds like, a 2D bitmap containing all the characters.  If you don’t specify a Font in the constructor, you will get the default font Arial-15 included with LibGDX.  The font file looks like this:




In the render() method we clear the screen to white by making the OpenGL function call glClear() and glClearColor().  The parameters to glClearColor are the red, green, blue and alpha ( transparency ) values to clear the screen with.  The function glClear actually clears the screen.  As you can see, the underlying OpenGL functionality is exposed in, although generally you wont work at that level very often.


Next we start our sprite batch by calling begin(), then render our text to the batch using the font.draw method.  The parameters to draw() are the batch to draw to, the text to draw and the x and y coordinates to draw the text at.  If you run this code ( right click hello-world-desktop and select Run As->Java Application ) you will see:




Voila!  It’s Hello World.


One important thing to be aware of is the project hello-world is not an application that you can run, its a library used by the other projects.  I’ll show you what I mean, take a look at code in hello-world-desktop for example:



Hey look, it’s Main!  Let’s check out the code:


package com.gamefromscratch.helloworld;

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;

public class Main {
    public static void main(String[] args) {
        LwjglApplicationConfiguration cfg = new LwjglApplicationConfiguration();
        cfg.title = "hello-world";
        cfg.useGL20 = false;
        cfg.width = 480;
        cfg.height = 320;
        new LwjglApplication(new HelloWorld(), cfg);


This is the actual entry point for your application, or at least it is for the desktop target.  This is where the Desktop specific configuration happens.  You then start your game off by creating a LwjglApplication object, passing in an instance of your ApplicationListener as well as the Lwjgl specific configuration settings.  If Lwjgl is new to you, it’s a Java based game wrapper over top of OpenGL and is what LibGDX uses for desktop rendering.  Beyond configuring it here, you will have no other interactions with it, LibGDX takes care of all of that for you.


To really understand how cross platform magic works in LibGDX, let’s also take a look at the Main for the –html project.  In this case it’s not actually called Main, but instead




Gwt stands for Google Web Toolkit, and it’s a technology Google provides for compiling Java into JavaScript for use in a browser.  It’s the secret sauce that LibGDX uses to make your game run in HTML.  It’s also horrifically annoying at times, you have been warned!  That said, if you dont care about HTML, you can remove this project completely and save yourself a number of headaches. 


Let’s take a look at


package com.gamefromscratch.helloworld.client;

import com.gamefromscratch.helloworld.HelloWorld;
import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.backends.gwt.GwtApplication;
import com.badlogic.gdx.backends.gwt.GwtApplicationConfiguration;

public class GwtLauncher extends GwtApplication {
    public GwtApplicationConfiguration getConfig () {
        GwtApplicationConfiguration cfg = new GwtApplicationConfiguration(480, 320);
        return cfg;

    public ApplicationListener getApplicationListener () {
        return new HelloWorld();

Look’s a lot like the –desktop project main doesn’t it?  The basic concept is exactly the same, you create the platform specific configuration bits, and create an instance of your ApplicationListener.  The GwtApplication class is callback based however, so it looks a bit different.  Once again, you should rarely be working at this level.  One important thing to note though is the values being passed to GwtApplicationConfiguration… this represents the size of the HTML canvas being created.  So if you want your HTML app to be more than a small square in the middle of the screen, this is where you change it.


So basically LibGDX works by having you create a single common library that implements your game in a cross platform way in the form of an ApplicationListener.  To support multiple platforms, you have a project for each platform where you create a platform specific application ( an instance of GwtApplication in the case of HTML targets, LwjglApplication for desktop targets, AndroidApplication for Android targets, Application for iOS targets… not shown because I am working on Windows currently ) , configure it and pass in the ApplicationListener.  It is this application class that will be calling back to your ApplicationListener each frame.  The nice news is, most of the time, you wont care about any of this… but it’s handy to understand what’s happening behind the curtains.



Oh yeah… about GWT


Remember I said it was a bit of a pain?  Well let’s take a look at what happens when you run the hello-world-html application ( right click hello-world-html->Run As->Web Application):





Ugh…  so basically our code is trying to do something GWT does not permit.  If we flip back to Eclipse in the Console panel we can get a bit more insight into the nature of the exception.



It’s line 17 in HelloWorld.Java that is causing the exception:

        font = new BitmapFont();

So, what exactly is going on here?  Well, remember earlier when I told you that BitmapFont’s default constructor would use the built-in arial-15 font.  Well, when I said built in, that file actually resides in gdx.jar which is included in your project.  A jar file is actually just a zip, so if you extract the file you can see all the code and assets that make up the gdx library itself.  Of particular interest to us is the folder \gdx\com\badlogic\gdx\utils, this is where the font file resides among other files:




Basically the GwtApplication is trying to access this file and doesn’t have permission to do so.  What’s the moral to the story?  Cross platform is awesome… but not always free!  Unless you need to support HTML, I would suggest not creating an HTML project, as it is by far the most fragile part of LibGDX and working with GWT causes all kinds of heartache and complication.  Your mileage may vary!


That said, there is a very simple fix to this, and it nicely illustrates how you deal with files between your projects… a process that may not be particularly intuitive.  The simple solution is to add the files arial-15.fnt and  arial-15 to the project and change the line:

font = new BitmapFont();



font = new BitmapFont(Gdx.files.internal("data/arial-15.fnt"),false);


This version of BitmapFont’s constructor takes a file handle of the font file you want the BitmapFont to use.  Gdx.files is used for file manipulation, internal returns a file handle to a file that is included within the project.  The false parameter is specifying that the font’s graphic isn't flipped upside down.


So, how do you actually add the file to the project?  You add them to the assets\data folder of the hello-world-android project:



You can add the files by simply dragging/dropping from Finder or Explorer to the data folder in the Package Explorer.


Now that the font file has been added, we can now run the HTML target:



So that’s Hello World in LibGDX.  Next up we look at something more advanced than Hello World.

Programming ,

LibGDX Tutorial 1: Creating an initial project

19. September 2013


In case you’ve never heard of it, LibGDX is a Java based game library capable of targeting iOS, Android, Desktop ( Windows, Mac and Linux ) and HTML5.  It provides a full suite of 2D game functionality including Input, Graphics, Fonts,  Physics, Storage and increasingly, 3D.  So basically LibGDX is pretty much a one stop game libGDXdevelopment library.  This series is going to look at all of those aspects of LibGDX eventually.


The first part of getting started with LibGDX is installation.  If you haven’t got a Java/Android development environment set up yet, this portion is going to be a bit annoying.  In a nutshell you need to install in order the Java JDK, Android SDKEclipse, then Google ADT and finally the Google Plugin for Eclipse ( for GWT ).  I am not going into specifics about how to install all of these, however I went into pretty extreme detail in these instructions for setting up PlayN that cover most of the Eclipse related configuration.  If you run into a problem during the install, those instructions might help.  The process is actually pretty straight forward, it’s just long.  Oh yeah, one more thing you are going to need of course is LibGDX itself!  You can download it here.  In my limited experience, the nightly builds are actually pretty safe to use.  Common sense dictates you should use the stable version, but I am neither common nor sensible, so I’m going to risk it.


From this point on, I am going to assume you have a properly configured Eclipse install.  I am no huge fan of Eclipse and you have other options like NetBeans ( instructions ) or IntelliJ ( instructions ), but they are the less supported and slightly more complicated route.  Like it or not, if you are working with Android, Eclipse is still the path of least resistance.  Android Studio is a very encouraging option but sadly it’s Android focus make it a poor fit for LibGDX.


OK, let’s get started…


If you haven’t already, unzip the LibGDX archive somewhere.  I personally went with C:\dev\libgdx-0.9.8.  Keep the zip archive however.

Located and double click gdx-setup-ui.jar in the root directory of the libGDX.

The following Window should load:



If it doesn’t, you appear to have a problem with your Java install.

Click Create.



Fill in the resulting dialog.  You can see the values I used above.  You can optionally create a desktop, html and ios project.  The core and Android projects are mandatory.  Note, if you change the destination, you will have to specify the path to the LibGDX zip file.


Once you’ve specified the LibGDX path ( or if you didn’t change Destination ), the Generation button should be enabled:



Click it.

The following screen appears:



Click Launch.

All things according to plan, you should see:



If you don’t see the above messages, welcome to the LibGDX forums. Smile  StackOverflow is another good place for LibGDX related support as there are already 1,500 LibGDX tagged questions.


At this point we are done with the setup tool, you can close it.  If you navigate to folder you specified as the destination, you should see the following folder structure:



It should mirror the platforms you selected during setup.


Now it’s time to fire up Eclipse.

Now select File –> Import



Then select General->Existing Projects into Workspace and click Next.



Then the following dialog will appear:



With Select Root Directory checked, click Browse and navigate to the folder you chose as a destination earlier.  You should then see a list of available projects, all of which should be checked.  Then optionally choose if you want the project file copied within your Eclipse workspace.  When complete click Finish.


Now you should see:



hello-world ( or whatever you named the project ) is the common project, while each additional platform has a –platform suffix.


Running the desktop project


Let’s run the Desktop project now.




Right click helloworld-desktop, select Debug As->Java Application:

A dialog will appear and ask you what you want to run.  Locate your project main, then click OK.



Congratulations, your first ever LibGDX application!




Running the HTML project


Now try the same thing with the html5 appllication, right click, this time select Debug As->Web Application



A few seconds later you should see:



Double click the link and:



By the way, if you are running Chrome on WIndows 8, expect trouble.  This is why I hate working with Google tools…  anyways, the 5th suggestion in this post fixes the problem.  Or you could just use Firefox.


When working with HTML5 builds in Eclipse, there is something you should be aware of.  Running the web application again in the way listed above will fail.  It will try to start another web server and find the built in one already running and throw up.  You have two options, both in the Development Server window.




You can either use the red stop icon to shut down the internal web server, allowing you to run it using Debug As->Web Application.  Or you can hit the yellow arrows to reload your code.


Running an Android Project


When it comes to running an Android application, you’ve got a couple options.  First you can plug in an actual device.  If you use a device, make sure the ADB driver for it has been installed.  The ADB usb driver is part of the Android SDK.  This is by far the best way to work with Android.


If you don’t have a device, you can instead run the emulator.  If Eclipse doesn’t detect an attached device, it will try to launch the emulator.  If it cant find an emulator, it will fail.  Just a heads up, working with the emulator, especially for games, SUCKS.  Get a device, really, trust me on this one.


If you haven’t got a device and havent created an emulator yet, do so now.  You can do it from within Eclipse.  Select Window->Android Virtual Device Manager.



In the resulting dialog, click New:



Here is an example I’ve used.  Prefer emulating the Intel Atom chipset, it runs much faster.  If you are running an Intel chipset with HyperVisor support install the Intel Hardware Accelerated Execution Manager which can be downloaded here.  Or better yet, get a real device.  Did I mention that already?




The emulator is notoriously fragile, you will come to hate it quickly.  Did I mention you are better off getting a real device?


Now that your emulator is created, select it and click Start…



Go make some tea…


Drink your tea…


Perhaps a few crumpets?  A bagel perhaps?


Oh, hey, happy birthday!


Congratulations on your first born!!


Ok, it should be loaded now.  For the record… leave the emulator loaded.


Now you can run your Android application using Debug As or Run As->Android Application



And a few moments later, you should see:



Back in Eclipse, get to know and love LogCat.



It’s a great source of Android debug information.  This is where all trace, debug and error information is displayed.


So, what about iOS.  Well first off, I’m running on Windows right now, so there is no option.  Second, libGDX is currently in a bit of a transition state.  Previously it relied on MonoDevelop to deploy to iOS. Now it is transitioning to RoboVM for iOS support.  In the future I may specifically cover deploying to iOS… when I am on my Mac would be a good start!


In the next part we will look closer at project layout as well as get down to some coding.

Programming ,

Looking for a Java book recommendation for experienced developers getting up to speed

12. September 2013


So after finishing up my ongoing Blender tutorial series, I intend to take a closer look at LibGDX and hopefully launch a new tutorial series.  This however presented a bit of a challenge to me.  You see, although I have experience with Java, it’s pretty out of date.  Since the release of C#, I’ve done very little work in Java other than some dabbling here and there.  So my knowledge is certainly out of date.  For example, when I last seriously programmed in Java Annotations ( ie @Override ) didn’t exist and the language didn’t yet have generics.


Obviously I need to get up to speed with modern Java before I start writing some truly embarrassing code.  This however presented a terrible problem for me.  Most texts are either targeted towards complete beginners or are more advanced and targeted at a very specific domain or technology.  The beginners texts make me want to scratch my eyeballs out, as after a decade of working in C#, and a few years of working in Java before that, reading about what a class is, or what a private variable does is a little…  behind me.  On the other hand, the little tidbits of information I need ( about what’s new ) are buried in these descriptions. 


I’ve been looking for an ideal book and I haven’t found one.  Something along the lines of Effective C++ or JavaScript: The Good Parts would be absolutely ideal.  Both of those books present best practices for experienced programmers in the modern usage of each language.  Both are incredible reads and will change the way you program.  Sadly, I haven’t found a Java equivalent yet.  There are a couple books I’ve tried.


The first was Java: The Good Parts.  By the title, I was really expecting something like the JavaScript book I mentioned earlier.  I will say, I do recommend this book, but it really isn’t what I am looking for.  The author Jim Waldo has been at Sun ( er, Oracle ) a very long time and has a deep insight into the Java language and how it evolved.  It answers a lot of the “why the hell did they do this???” questions you might have about various language features.  That said, the target audience seems a bit confused, at times covering brutally simple tasks in detail, like it was aimed at a beginner.  Then jumping into a topic at a more advanced level.  Basically this means I have to read through a lot of stuff I already know quite well.   I don’t regret reading it though, again, it gave some pretty good insight behind the curtain of language development.


Then I went with Learning Java 4th Edition as it was one of the most up to date releases ( July 2013 ), was reasonably well reviewed on Amazon and Safari and seemed to be partitioned nicely into beginner and more advanced topics.  At the end of the day, I guess I am resolved to have to go through all the beginner stuff to pick up what’s changed.  Oh well I guess.


So, to any of you Java developers out there… are there any books along the lines of what I am looking for?  A text that focused on writing modern Java code.  That illustrate what parts of the language are cruft and what various best practices are?  A text aimed at a non-beginner?  If there is a book you recommend, I would love to hear it!.

Programming ,

Looking at LibGDX and once again I find myself hating Google and Java developer tools

1. September 2013


I finally decided to check out LibGDX, a very cool and popular Java based cross platform game development library.  I’ve been meaning to check out LibGDX for ages, it’s the Java part that turned me off.  It’s not the programming language, Java is a really good one, it’s the eco-system.  Always it seems like when dealing with Java I deal with a whole slew of new headaches.  Often it seems the cause of those headaches is Google.  Today sadly was no exception.  This post reflects not at all upon LibGDX, a long time ago I intended to run a series of PlayN tutorials, but I spent so much time supporting the build process or fragility of Eclipse that I simply gave up.  Fortunately LibGDX ships with a setup tool that makes a bunch of these problems go away, but it’s certainly not solved the problems completely.


The first problem is partially on me, partially on Eclipse and a great deal on Java.  I installed Eclipse as it’s the preferred environment for LibGDX and often trying to do things the non-Eclipse way can really make things more difficult, at least initially.  ( I massively prefer IntelliJ to Eclipse )  Right away I fire up Eclipse and am greeted with:

failed to load the JNI shared library

If you are a veteran developer this is no doubt immediately obvious to you.  I checked the most common things, first make sure JDK is installed.  Make sure JAVA_HOME is set, make sure javac runs from the commandline, run javac –version to make sure things are working right.  In the end it was a version mismatch.  I downloaded the 64bit version of Eclipse and the 32bit version of the Java JDK.  The obvious answer is to download the 64bit JDK but I really wouldn’t recommend that.  Amazingly enough in 2013 the 64 bit version still causes problems.  For example, FlashDevelop wont work with it.  That is just one of a dozen applications I’ve seen that wont run with the 64bit version.


Not really a big deal.  Eclipse should have done a heck of a lot better job with the error message.  If it said “64bit JDK required” this would have taken about 10 seconds to solve.  Keep in mind this is a problem that’s existed for 3 or 4 years, so don’t expect an improvement on the Eclipse side any time soon.  Accessibility and polish has never really been a priority when it comes to Eclipse.  The fact 64bit Java is still problematic, that’s 100% on Java though!



Anyways, other than fighting with Eclipse and Java, everything went wonderfully with LibGDX.  I got my project made and configured without issue ( beyond oddly enough, the Setup UI wanting the original GDX install zip file, I had already deleted… oops ).  Then when I went to run the HTML5 target in Chrome I get:




I click the Download the GWT Developer Plugin button.


Nothing.  No error, no page load, nothing.  I reload and try again.


Check my internet connection… all good.




So then I grab the URL for that button and it loads a Chrome Store page ( at least it did something! )



This application is not supported on this computer.  Installation has been disabled.


Lovely.  If I got that message when I clicked the initial link, things would have made a great deal more case.  Want to know why I hate Google for this one?


First off… it works in Internet Explorer and Firefox.  It’s only in Chrome that the GWT developer plugin doesn’t work ( on Windows 8 as it turns out ).  But that’s not the hatred part.

Take a look at GWT issue 7778.

"This application is not supported on this computer. Installation has been disabled" while installing GWT developer plugin on Chrome

So, its a known issue of Google’s developer tool working in Google’s browser on Windows 8.  But the hatred part…



November 9th, 2012.  It’s been a known and reported problem for almost a year.  Fixed?  God no!


Welcome to working in Google tools.  You will spend a stupid amount of time trying to debug what the problem is, only to find yourself looking at year(s) old tickets that have been ignored by Google.  When working in Android I ran into common tickets with hundred of comments that were years old on nearly a daily basis.


This isn’t a one off rant, this kind of stuff happens EVERY SINGLE TIME I work with Google technology.  I have literally never once NOT run into a problem, from Android, to DART, to NaCL to GWT.  Every single time.


It’s not such a big deal for me, I’ve got the experience enough when working with Google tools to expect minimal or wrong errors when problems occurred and for half assed support when I research the problem.  Frankly I just stay the hell away when I can.  Where its a gigantic deal breaker is when a new developer runs into these additional hassles.  In some ways it’s kind of infuriating as great libraries like LibGDX become that much harder for developers to access.

Programming ,

Whats changed in the game development world since I wrote my game dev guide?

1. September 2013


One of the oldest and most popular articles on my site is I want to be a game developer… now what?  It offers a collection of advice for new game developers.  I keep intending to update it but frankly, not enough changed.  The following was recently posted on
This article was written 2 years ago, and is very informative about each game development language, but 2 years sounds like too much for how events quickly change now, XNA is partially dead, more books released, etc..

Is there a newer article of that kind of information? and is C++ still a bad choice (with the introduction of SFML 2.1 and SDL 2)?


Which got me to thinking about what all has changed since I wrote that guide.  The following was my answer.  Of course, I have no idea how many thousands of things I forgot to mention.  All told, the world hasn’t changed all that much, languages don’t really move all that fast.


Truth is, I keep meaning to update it, then look at the state of the game development world and there hasn't really been enough changes.  I will be doing a v2 eventually, but in summary, here is what's changed since the article was written:



SFML 2/2.1 released.  Frankly it's not all that different.

SDL 2 was released.  Again, not massive changes.

Gameplay3D engine released  Site Link My Look

Hands down the biggest change to C++ ( and over the last two years ) was the release of C++11.  This completely changes the C++ book recommendations.  C++ changes a lot about the language, especially how it should be taught.  Some books did a horrid job updating to the new standard ( just bolting on the new features ), while others did a better (less lazy) job.  I will probably do a post specifically about C++11 books at some point in the future.



XNA was put out to pasture by Microsoft.  Fortunately, Monogame also got a lot better.  XNA is still an option, just not as good of one as it used to be.

PlayStation Mobile was released and C# based.  SDK Link (My Tutorials)

Unity 3D is now free.

Mono for iOS and Android 100$ cheaper

C# 5 released.  Outside of parallel programming functionality (async), not much changed.  Nowhere near the change of C++ for example.



Slick2D is dead or abandoned.

Java took a few hits in terms of deployment due to security concerns ( Apple yanked it for example ).

LibGDX is probably the strongest option in Java now.

Don't believe there were any major language updates ( 1.7 then and now ), just service releases.



Um.... anything?

Otherwise there would be a few things I would mention that weren't as relevant 2 years ago.



Rise of the Lua game engines.  Add Dreemchest to that list as well.

In the mobile space, Lua just simply put got big.  Lua is also the scripting engine of choice for CryEngine, Gameplay and Project Anarchy.  Lua is a very very very good starting point for people looking to just start out.  Corona is now available free and at the same time, is more expensive...

HTML5 got a little bit more viable ( but still limited ) Flash suffered some major blows ( but still viable ).  There are now a number of solutions that make appifying HTML5 applications possible, such as CocoonJS.  Tons of libraries exist for HTML5 game development..

Previously niche/limited game maker software ( GameMaker, Construct2 ), as well as cross platform tools like Haxe (tutorial series) or LoomScript ( my look ) have made cross platform game development a hell of a lot easier.

The 3D engine space saw a bit more activity.  As mentioned earlier, RIM released GamePlay3D.  On top of that Torque was released for free, CryEngine leaked it's developer information in a hack attempt... ( thanks for that btw... :( ) and Project Anarchy (my look) was announced and released.  Project Anarchy is a bundle of Havok's game developer technology released completely free for mobile development.  On the 3D game engine space the story is Unity Unity and Unity.  Frankly Unity had a good year, made partnerships with pretty much every single platform available and is available in a free version for pretty much every platform now.

Grand total, not all that much happened, not really enough to full write a v2 version, hands down the biggest changes in the last two years:

C++ 11

XNA killed

Unity took over the world.

I miss anything?


Anything else I missed in the last two years of game development?

Programming , ,