Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
2. October 2013

 

This is the part people always find the most fun, the actual act of putting graphics up on screen.  Let’s start with about the simplest project that we can.

 

We are going to display this sprite (created in this tutorial):

jet

 

On screen.  One important thing to note, the above graphic is 512x256.  OpenGL in general and LibGDX in specific, require your image files to be in power of two dimensions.  This means your width and height are 2,4,8,16,32,64,128,256,512,1024,2048, etc… pixels in size.  Be sure to add this file to the assets\data folder in the android project before continuing.

 

Let’s jump right in with code:

 

package com.gamefromscratch.graphicsdemo;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class GraphicsDemo implements ApplicationListener {
    private SpriteBatch batch;
    private Texture texture;
    private Sprite sprite;
    
    @Override
    public void create() {        
        batch = new SpriteBatch();
        texture = new Texture(Gdx.files.internal("data/jet.png"));
        sprite = new Sprite(texture);
    }

    @Override
    public void dispose() {
        batch.dispose();
        texture.dispose();
    }

    @Override
    public void render() {        
        Gdx.gl.glClearColor(1, 1, 1, 1);
        Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
        
        batch.begin();
        sprite.draw(batch);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }
}

 

And if you run it:

image

 

The image is drawn relative to the origin.  In the case of LibGDX (0,0) is the bottom left corner of the screen.

 

As to the code, there isn’t actually a ton new compared to the Hello World example in the previous tutorial.  The only new concepts are the Texture and the Sprite.  The texture represents the underlying OpenGL texture.  One important thing to keep in mind with Texture ( and other similar classes ) is they implement the Disposable interface.  This means when you are done with it, you have to call the dispose() method, or you will leak memory!  A Sprite holds the geometry and colour data of a texture, this means the positional data ( such as it’s X and Y location ) are stored in the Sprite.  We construct our texture by passing it’s path in, obtained in the same manner we access the font in the prior tutorial.  We then construct the Sprite by passing in our newly created texture.  There are other ways of creating Sprites, that we will see shortly.  Just like in the Hello World sample, we start a SpriteBatch, and draw our sprite to it using the draw() method.

 

Dynamic textures with Pixmap

 

Your Texture’s source doesn’t have to come from a file.  Here we are going to use the Pixmap class to create the texture’s source dynamically.

 

package com.gamefromscratch.graphicsdemo;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.Color;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Pixmap;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class GraphicsDemo implements ApplicationListener {
    private SpriteBatch batch;
    private Pixmap pixmap;
    private Texture texture;
    private Sprite sprite;
    
    @Override
    public void create() {        
        batch = new SpriteBatch();
        
        // A Pixmap is basically a raw image in memory as repesented by pixels
        // We create one 256 wide, 128 height using 8 bytes for Red, Green, Blue and Alpha channels
        pixmap = new Pixmap(256,128, Pixmap.Format.RGBA8888);
        
        //Fill it red
        pixmap.setColor(Color.RED);
        pixmap.fill();
        
        //Draw two lines forming an X
        pixmap.setColor(Color.BLACK);
        pixmap.drawLine(0, 0, pixmap.getWidth()-1, pixmap.getHeight()-1);
        pixmap.drawLine(0, pixmap.getHeight()-1, pixmap.getWidth()-1, 0);
        
        //Draw a circle about the middle
        pixmap.setColor(Color.YELLOW);
        pixmap.drawCircle(pixmap.getWidth()/2, pixmap.getHeight()/2, pixmap.getHeight()/2 - 1);
        
        
        texture = new Texture(pixmap);
        
        //It's the textures responsibility now... get rid of the pixmap
        pixmap.dispose();
        
        sprite = new Sprite(texture);
    }

    @Override
    public void dispose() {
        batch.dispose();
        texture.dispose();
    }

    @Override
    public void render() {        
        Gdx.gl.glClearColor(0, 0, 0, 1);
        Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
        
        batch.begin();
        sprite.setPosition(0, 0);        
        sprite.draw(batch);
        sprite.setPosition(Gdx.graphics.getWidth()/2, Gdx.graphics.getHeight()/2);
        sprite.draw(batch);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }
}

 

Once again, the code is remarkably similar to our prior example.  The biggest difference is instead of loading the textures image data from file, we create one dynamically using a Pixmap.  At the simplest, a pixmap can be thought of as a grid of pixel data in memory.  It contains a number of graphical functions, many of which we demoed above.  The drawing code is pretty well commented in terms of what it does, so I wont go into details here.  One very important detail though, in the modern GPU driven world, these kinds of per pixel operations are REALLY REALLY SLOW.  Generally you want to avoid them as much as possible. 

 

The only other thing of note in this example is the changes in the render() method.  Notice how the same sprite is drawn twice to the sprite batch?  Well this behaviour is perfectly OK, and has minimal performance overhead in doing so.  Sprite’s setPosition method is used to position a sprite, once again, (0,0) is the lower left hand corner of the screen by default.  The only other new code here is the Gdx.graphics.getWidth() and getHeight() method calls.  These return the window’s ( or Canvas in the case of HTML5 ) dimensions.  Of course in production code you would probably cache them locally instead of retrieving them every pass through the render loop.

 

TextureAtlas

 

Quite often you want to deal with a sprite sheet, which is a number of sprites combined together into a single image.  Such functionality is built into LibGdx.  The first thing you are going to need is a directory of images that are going to be combined into a sprite sheet.  Like this:

image

 

Open a command line or terminal window and run the following command:

java -cp gdx.jar;extensions/gdx-tools/gdx-tools.jar com.badlogic.gdx.tools.imagepacker.TexturePacker2 c:\tmp c:\tmp spritesheet
tmp

It looks more unwieldy than it is.  Basically you are running the TexturePacker2 class inside the gdx-tools jar.  The first parameter is the source directory, the second parameter is the destination direction and the final parameter is the filename to use.  It will automatically add the required file extensions.  This process will create two files, a .atlas file and a .png.  The atlas file is a text file describing how the sprites are laid out in the spritesheet image, with the images filename used as the key ( minus extension ), like so:

spritesheet.atlas:

spritesheet.png
format: RGBA8888
filter: Nearest,Nearest
repeat: none
0001
  rotate: false
  xy: 1, 651
  size: 192, 128
  orig: 192, 128
  offset: 0, 0
  index: -1
0002
  rotate: false

 

While the sprite sheet itself looks like this:

spritesheet

 

The spritepacker tool automatically pads the image out to be a power of 2 in size.  I’ve only scratched the very surface of what this tool can do.  You can set it to run as part of your build process, run if from code or within Eclipse or even run it at program run time. There are a wealth of options you can configure.  You can read much more about it right here.

 

So how do you actually use a texture atlas then?  It’s very simple, first copy the generated png and atlas file to your assets.  The following code shows how to use a TextureAtlas:

 

package com.gamefromscratch.graphicsdemo;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.g2d.TextureAtlas;
import com.badlogic.gdx.graphics.g2d.TextureAtlas.AtlasRegion;
import com.badlogic.gdx.utils.Timer;
import com.badlogic.gdx.utils.Timer.Task;

public class GraphicsDemo implements ApplicationListener {
    private SpriteBatch batch;
    private TextureAtlas textureAtlas;
    private Sprite sprite;
    private int currentFrame = 1;
    private String currentAtlasKey = new String("0001");
    
    @Override
    public void create() {        
        batch = new SpriteBatch();
        textureAtlas = new TextureAtlas(Gdx.files.internal("data/spritesheet.atlas"));
        AtlasRegion region = textureAtlas.findRegion("0001");
        sprite = new Sprite(region);
        sprite.setPosition(120, 100);
        sprite.scale(2.5f);
        Timer.schedule(new Task(){
                @Override
                public void run() {
                    currentFrame++;
                    if(currentFrame > 20)
                        currentFrame = 1;
                    
                    // ATTENTION! String.format() doesnt work under GWT for god knows why...
                    currentAtlasKey = String.format("%04d", currentFrame);
                    sprite.setRegion(textureAtlas.findRegion(currentAtlasKey));
                }
            }
            ,0,1/30.0f);
    }

    @Override
    public void dispose() {
        batch.dispose();
        textureAtlas.dispose();
    }

    @Override
    public void render() {        
        Gdx.gl.glClearColor(0, 0, 0, 1);
        Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
        
        batch.begin();
        sprite.draw(batch);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }
}

 

Here is the HTML5 version of the above code:

 

 

As you can see, it’s remarkably consistent.  The majority of the code above is actually part of the demo related, as opposed to being part of using a TextureAtlas.  Instead the only import new code is:

batch = new SpriteBatch();
textureAtlas = new TextureAtlas(Gdx.files.internal("data/spritesheet.atlas"));
AtlasRegion region = textureAtlas.findRegion("0001");
sprite = new Sprite(region);

Just like working with a texture, but instead you load a TextureAtlas.  Then instead of assign the texture to the sprite, you use an AtlasRegion, which describes the coordinates of the individual sprite within the spritesheet.  You get the region by name by calling the findRegion() method and passing the key.  Remember this value is set by the file names of the source images.  The TextureAtlas needs to be dispose()’d or you will leak memory.

As you can see by the call:

sprite.setRegion(textureAtlas.findRegion(currentAtlasKey));

You can change the region within the sprite sheet that the sprite will refer to by calling setRegion().

 

The rest of the code simply positions and scales the sprite up 2.5x times.  We then schedule a Task using Timer.schedule().  This task will be called ever 30th of a second.  It simply changes the key we will use within the TextureAtlas.   In this case the files were named 0001.png, 0002.png, etc…  so we want a value between 0001 and 0020.  We then use this value to update the region the sprite refers to.  As a result every 30th of a second, the sprite moves on to the next frame of animation, rolling over when it gets to the end.

 

EDIT: I should state for the record, this is NOT how you would use a TextureAtlas to perform animation, this code was simply for demonstration purposes.  There are dedicated animation classes and we will cover them later on.

 

Be warned though, if you try to run this under GWT, you will see:

image

 

This is because the GWT compiler ( this has nothing to do with LibGDX ) doesn’t support String.format() for some reason.  If you want to run this example in a browser you can simply replace

currentAtlasKey = String.format("%04d", currentFrame);

With:

String base = new String();
        
        if(currentFrame >= 10)
            base = "00";
        else
            base = "000";
        
currentAtlasKey = base + currentFrame;

 

Now the HTML target should run just fine.

 

In the next part we will take a look at controlling input in LibGDX.

 

Configuring LibGDX to use GL 2

 

It was brought to my attention by Mario Zechner that LibGDX is not limited to power of 2 texture sizes.  That instead is an artefact of OpenGL ES 1.  If you run using OpenGL ES2 it will work fine.  That said, OpenGL and the underlying hardware still perform better if you stick to power of two.  If you want to use GL2, you set it during as part of the configuration process, we discussed briefly in the Hello World tutorial.  Simply set the useGL20 value to true in the configuration you pass in to your application listener.  Here for example is Main from the desktop project configured to use GL 2.

 

public class Main {
    public static void main(String[] args) {
        LwjglApplicationConfiguration cfg = new LwjglApplicationConfiguration();
        cfg.title = "graphicsdemo";
        cfg.useGL20 = true;
        cfg.width = 480;
        cfg.height = 320;
        
        new LwjglApplication(new GraphicsDemo(), cfg);
    }
}

 

Remember of course to configure this for all targets you are supporting.

 

EDIT:

12/18/2013 – It was pointed out to me that I didn’t include the atlas files, making this tutorial hard to follow along with.  I have included an archive of the data folder used for this example, you can download it here.

Programming


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:

image

 

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 HelloWorld.java 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;
import com.badlogic.gdx.graphics.Color;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.g2d.BitmapFont;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class HelloWorld implements ApplicationListener {
    private SpriteBatch batch;
    private BitmapFont font;
    
    @Override
    public void create() {        
        batch = new SpriteBatch();    
        font = new BitmapFont();
        font.setColor(Color.RED);
    }

    @Override
    public void dispose() {
        batch.dispose();
        font.dispose();
    }

    @Override
    public void render() {        
        Gdx.gl.glClearColor(1, 1, 1, 1);
        Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
        
        batch.begin();
        font.draw(batch, "Hello World", 200, 200);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    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 frame, 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:

 

image

 

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 Gdx.gl, 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:

 

image

 

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:

image

 

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 GwtLauncher.java.

 

image

 

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 GwtLauncher.java:

 

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 {
    @Override
    public GwtApplicationConfiguration getConfig () {
        GwtApplicationConfiguration cfg = new GwtApplicationConfiguration(480, 320);
        return cfg;
    }

    @Override
    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):

 

image

 

 

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.

image

 

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:

 

image

 

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();

to

 

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:

image

 

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:

image

 

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

Programming


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.

 

EDIT: Sept 9/2014

The setup process changed slightly again.  On the bright site, it’s easier now, read here.

EDIT: Jun 24/2014 

** IMPORTANT READ ME **

The process for creating a LibGDX project has changed substantially since this post was created.  There is now a Gradle based application that makes creating new projects much simpler and allows you to use IDEs other than Eclipse.

Read this post on getting started.  The portions of this post on running/debugging in Eclipse should still be valid.  For configuring IntelliJ IDEA to run LibGDX applications, refer to this post.

** END IMPORTANT READ ME **

 

 

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:

image

 

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

Click Create.

image

 

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:

image

 

Click it.

The following screen appears:

image

 

Click Launch.

All things according to plan, you should see:

image

 

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:

image

 

It should mirror the platforms you selected during setup.

 

Now it’s time to fire up Eclipse.

Now select File –> Import

image

 

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

image

 

Then the following dialog will appear:

image

 

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:

image

 

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.

 

image

 

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.

image

 

Congratulations, your first ever LibGDX application!

image

 

 

Running the HTML project

 

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

image

 

A few seconds later you should see:

image

 

Double click the link and:

image

 

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.

 

image

 

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.

image

 

In the resulting dialog, click New:

image

 

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?

 

image

 

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…

image

 

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

image

 

And a few moments later, you should see:

image

 

Back in Eclipse, get to know and love LogCat.

image

 

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


GFS On YouTube

See More Tutorials on DevGa.me!

Month List