| Archives | March

Libgdx goes Gradle: New Setup UI and Intellij IDEA support

Posted on March 23, 2014 by Mario Zechner

Here’s the new hilariously bad setup tutorial video

We’ve been hard at work in the last few days to finish up our new setup UI and the way libgdx projects are organized. Starting today, all libgdx projects can be compiled and packaged via Eclipse, Intellij IDEA and the command line. This was made possible by using Gradle, a build and dependency management system that’s also used by the latest Android development tools. This new setup has a few benefits:

Develop with Eclipse, Intellij IDEA and command line
Continuous integration by packaging your apps on the command line/shell
No more jars, just specify your 3rd party libraries in the build.gradle file
Switch between libgdx releases and nightlies by setting gdx.version in the build.gradle file
GWT Super Dev Mode is now the default run mode

Follow these steps if you want to give it a try:

Changes for existing Eclipse users

If you want to migrate to the Gradle based build, you’ll have to generate a new project and move your code and assets over. We do not provide a converter as that’s a huge, error prone task.

You also have to install a new plugin called the Eclipse Gradle Integration by Springsource. This makes Eclipse understand Gradle based projects. You can install it via this update site: http://dist.springsource.com/release/TOOLS/gradle

Note that the way GWT projects are executed has changed. We now invoke a Gradle task to run super dev mode instead of promoting the use of the normal Dev Mode, which is extremely slow and doesn’t represent the Javascript compiled behaviour of your app.

Also, there are not linked assets folders anymore! This means that you have to set the working directory of your desktop project to android/assets/!. If you don’t do this, your desktop app won’t find your assets.

You will also notice that there are no JAR files anywhere anymore, neither are their any native libraries. This is all managed by Gradle. The JAR files are stored outside of your project’s directories. This is nice as the JARs and native libraries will never polute your version control system!

Another upside is that it’s now super easy to switch between release and nightly builds. The build.gradle file in the root directory of your app has a constant called gdx.version. Just set it to whatever you want, e.g. 0.9.9 for the last release, or 1.0-SNAPSHOT for the latest nightly.

If you work with nightlies, you’ll get the latest version every time you update your Gradle project automatically!

We will still feature the old gdx-setup-ui for a while, but be warned that this will go away eventually!

Now go and give it a try. Please report any issues you have on the issue tracker!

Changes to Animation

Posted on March 21, 2014 March 21, 2014 by Mario Zechner

We got a nice pull request yesterday that changed the playmodes of the Animation class to use enumerations. Since we are heading towards 1.0, i thought it would be a good thing to merge this pull request and thereby clean up the API a little more.

Starting from tonights nightlies, Animation will take PlayMode enumerations instead of integers! Update your code accordingly!

Stage API changes: Viewport added

Posted on March 20, 2014 March 20, 2014 by Nate

noone had a great idea, to provide a Viewport class for determining how world coordinates are scaled to screen coordinates. This was already possible using Camera of course, but it was not noob friendly. Viewport is standalone and just manages a Camera. This means any app that uses Camera can use Viewport to control the strategy for scaling the world to the screen. For example, maybe you want to stretch the world to the screen, or scale it up without changing the aspect ratio by using black bars.

After a couple iterations we’ve now integrated the Viewport class. It’s quite slick, you just pick from one of the ready made Viewport implementations and you’re good to go. See the nice wiki page for docs.

Here’s where I tell you about the pain you are in for! It makes sense for Stage to have a Viewport instead of a Camera (remember Viewport has a Camera). This makes controlling scaling for scene2d super easy, but the bad part is Stage had to change. Instead of telling the Stage the viewport size, you give it a Viewport instance that does what you want.

If your old Stage construction code looked like this:

stage = new Stage(width, height, false); // OR
stage.setViewport(width, height, false);

1 2	stage = new Stage(width, height, false); // OR stage.setViewport(width, height, false);

Then you need to change it to:

stage = new Stage(new StretchViewport(width, height)); // OR
stage.setViewport(new StretchViewport(width, height));

1 2	stage = new Stage(new StretchViewport(width, height)); // OR stage.setViewport(new StretchViewport(width, height));

If your old code looked like this:

stage = new Stage(width, height, true); // OR
stage.setViewport(width, height, true);

1 2	stage = new Stage(width, height, true); // OR stage.setViewport(width, height, true);

Then you need to change it to:

stage = new Stage(new ExtendViewport(width, height)); // OR
stage.setViewport(new ExtendViewport(width, height));

1 2	stage = new Stage(new ExtendViewport(width, height)); // OR stage.setViewport(new ExtendViewport(width, height));

There is another important change, resize used to look like:

public void resize (int width, int height) {
    stage.setViewport(width, height);
}

public void resize (int width, int height) {

stage.setViewport(width, height);

}

Now you’ll do this:

public void resize (int width, int height) {
    stage.getViewport().update(width, height, true);
}

public void resize (int width, int height) {

stage.getViewport().update(width, height, true);

}

The boolean centers the camera if true (only really needed for UIs). It can be omitted, which is the same as false.

The other changes that may affect you are where you are using the Stage’s Camera. You can use stage.getViewport().getCamera(), but note that Viewport has project/unproject methods that should be used instead, since they take the viewport into account.

Not too bad for you guys I hope!