Is Slick2D still recommended or is libgdx the way to go?

Hi all,

I’ve been playing around with both Slick2D and libgdx for a while now, trying to decide which to use for my game. What’s the general consensus these days on which one to use?

My thoughts:


  • Easier to start using, more familiar to people who’ve used java 2d etc.
  • Does the basics and doesn’t have a whole lot of extra stuff I don’t need
  • The recent Mojang ‘Mojam’ seems to have made the forums busier again
  • Not really being maintained any more, the maintainer himself has suggested libgdx to people


  • Newer, maintained and still being developed
  • Seems to have plenty of featres…
  • … if you can find them in the semi-complete docs. It’s hard to find how to do even basic things at times
  • Almost seems to do ‘too much’ for my needs - I’m just creating a desktop game

So I guess my questions are, if I feel more comfortable using Slick2D, should I? Or should I put the time in to learn the ‘libgdx way’ of doing things?


If your programming skills are pretty decent, no problem in using libgdx. You can use common sense or try-error when something not well documented.

But there’s one big rule! Pick what you feel comfortable with. This is your only chance (indie) to pick what you like rather hear what people said, because that’ll happen for sure on real/business/work project until you scream “OMG why I have to use this!”.

Do you really think so? I know some things are missing, but I found it easy to get the basics up and running, like a game screen, to load textures, animation. The only thing that had me pull my hair was the tilemap loader, but that´s rewritten now (haven´t tried the new one though). And if you´re not satesfied with the wiki, there are at least a couple of LibGDX tutorials on youtube.

I have never tried Slick 2D so I can´t say you should pick one over the other, but I felt at home with LibGDX right from the start.

Regarding the features: You just use what you want and leave the rest alone or write your own. :slight_smile:

Perhaps it’s me not giving it enough of a chance :slight_smile: So as an example, one thing I’ve found difficult to find some basic examples of is how to use the cameras.

In java2d / Slick2D, I’d just create a camera class which follows the player, and when things are drawn to the screen, they’re offset by the camera position. It’s pretty simple and not much code. However, the wiki page for the OrthographicCamera in libgdx is just plain confusing and has so much stuff that’s just not relevant to me, I’m not even sure where to begin.

Using OrthographicCamera is incredibly simple:

// Initialization:
OrthographicCamera cam = new OrthographicCamera(,;
SpriteBatch batch = new SpriteBatch();
// Update loop:
cam.position.set(player.x, player.y);
// Rendering loop:
// That's it!

OrthographicCamera is nothing else, but a class holding information about how big your screen is n’ other stuff, like projections - being more complicated, but not important to you.
It’s purely information, nothing else.

Then you have your SpriteBatch, which wants to get the information about the position and rotation of your view (cam.view) but also about your screen (cam.projection). These are matrices, btw. They are set via [icode]batch.set[Projection / Transform]Matrix(cam.[projection / view]);[/icode].

Finally you have to draw your sprite.

If you want your camera to follow your player around, you have to change it’s information: The position. So what you do is, you set it’s position to the player position: [icode]cam.position.set(player.x, player.y);[/icode].
You also need to call [icode]cam.update();[/icode], so that these changes have an effect. This is very important! Otherwise the matrices (cam.projection, cam.view, cam.combined) won’t be updated!

Thank you, that’s a massive help. I wish that was on the wiki page for the camera!

One small question, does it have any built in support for draw order / depth? I realise there’s a PerspectiveCamera class as well, but I’m not sure if that’s what I want (My view will be something similar to any old top-down RPG, Zelda, Chrono Trigger, etc.) In Slick2D I would just sort my entities list by their ‘y’ position (faked depth) first before they’re drawn, but I’d rather do things the ‘correct libgdx’ way if I’m going to be using it :slight_smile:

I’m just sorting them by y value as well in my game RuinsOfRevenge… :slight_smile:

PerspectiveCamera is for 3D. You could use it together with the Depth-Buffer from OpenGL, but usually you’d just sort your entities. :wink:

That misses a cam.setToOrtho(true);
What that does is setting Y axis down, like in Slick2D and Java2D, and most people perfer it.
You will have to flip textures and fonts then, but its always just one line to do it.

Also I just do: spriteBatch.setProjectionMatrix(camera.combined);

Ah btw, the camera you mentioned using just an offset… I did that back in Java2D and Slick2D too. But once you use Libgdx camera, its juts a couple of lines and you can even rotate it and zoom and everything, just like that… because its an actual opengl camera

To answer your first question: yes, use Libgdx. Yes the docs are a mess most times. Just ask here or the libgdx forum for help - no matter how simple the stuff is you wanna do

for ordering, yeah just do it yourself, have a internal ordering or order by Y value… depending on how you game looks like

Thanks everyone for the replies, I’m convinced - libgdx it is :slight_smile:

I’d really like to get more input on “the docs are a mess most of the times”. Can you point out a few examples and make suggestions on how to correct them?

The hardest part for me was the very strange TiledMapPacker. But we all know, it’s getting rewritten now…

I should have written it down… I think there was something else, but I don’t remember :confused:

For me at least, one thing was what I mentioned above about how to use the camera. I would have got much more out of a basic example that matheus23 gave me over the longer current page. I think many of the code samples on the wiki introduce concepts from other parts of the framework that confuse them, e.g. the camera sample includes creating a mesh, binding a texture etc.

Another thing that I couldn’t find anything about was the use of the Screen class. The SimpleApp and AppLifecycle pages make no mention of Screen, or how to use it. Until I found via Google I didn’t even know the feature existed.

I’m sure LibGDX’s documentation and tutorials will improve over time. There are plenty of docs already, but most of them assume the reader understands certain concepts like matrices/vectors/GL states/etc. This can be a little intimidating for somebody who’s never worked with graphics before.

Hopefully I can help with this front; I’ve already started writing some tutorials aimed specifically at LibGDX beginners:
LibGDX Textures & Pixmaps

Here are the main problems with Slick2D:

[]It is dead and no longer maintained.
]It is buggy and will likely never be “properly” fixed. There are crippling bugs and design problems with almost every aspect of the library, including GUI, texture loading, font rendering, particle systems, polygon triangulation, geoemtry hit-testing, render-to-texture abstractions, sound API, etc.
[]It relies on old-school OpenGL techniques and doesn’t utilize any of the modern pipeline, like batching or shaders. You are way more limited with Slick2D, and will have a hard time doing things like this.
]It only ports to desktop. Slick-AE should not even be considered; it is basically just a hackish and extremely buggy Slick layer on top of LibGDX.
[]The vast majority of posters in the forums have no understanding of OpenGL, and therefore can’t help you with more advanced rendering techniques (like lighting or efficient sprite rendering). Most forum members are still struggling with basic programming concepts (methods, loops, etc).
]The set-up is actually more difficult than LibGDX since you need to pull from the development branch if you want the most stable source.
[*]The tools (texture packer, particle editor, Hiero) are buggy and not nearly as powerful as LibGDX equivalents.

Well first of all. Is “libgdx-users” considered “official” and up-to-date tutorial stuff ?
Because if not, we cannot use any of that stuff as examples… however they show up of course in google.

Since libgdx decides to break earlier code in order to improve the overall lib, which I support, many example wont work anymore using copy&paste.

here is just one example off the top of my head which I searched a year ago, which is just empty:

Awesome! That’s actually feedback that’s constructive and will help us improve. “It’s a mess” doesn’t.

A few thoughts and links in the mean-time:

We do not break APIs lightly. The tilemap API has been in its old state for about 2 years. We announced the change 2 weeks before we pushed things to master. We wrote an extensive wiki article and provided a total of 5 different examples, including a platformer in 300 LOC. All of those are linked to from the announcement on the blog as well as the wiki.

API changes are always handled like this. We first announce upcoming changes on the blog, we link to the discussion about the API change in the forum, and once live, we post another blog post with the details, and usually a link to the Wiki.

The user-wiki hasn’t been maintained in a year. It was never official, and the core team never had any involvement in it. I should contact the original maintainer and ask him to link to the official wiki. I’m afraid i can’t solve the Google ranking issue.

All available documentation (wiki, javadocs, example code in the repo, external tutorials) are linked to from the documenation page. That is kept up to date, authors of 3rd party tutorials are generally asked to update their tutorials if necessary (we don’t always get a reply). Your first check should be the official wiki, then the javadocs, then the forums and/or IRC.

I try extremely hard to make all development as transparent and traceable as possible. Eventually it’s up to the user to read the available information, especially the one specifying where updates are posted.

All that being said, nothing is perfect, and our docs are far from being perfect. We keep improving things, but please realize that we do this in our sparetime, and if folks fail to read, there’s not a lot we can do.

One thing, which is also very, very, very hard to use is: scene2D. I gave up on it twice. Now it’s working for me, but it seems like an impossible task to me to use scene2d without a standard skin, or at least an example skin. I then found the “example skin” in the tests on github, after somebody gave me a link to them. Only then it was possible for me to create something using libgdx’s scene2d…

Probably something where somebody should do a complete tutorial with files.
Also there are outdated scene2d tutorials telling about outdated json formats.

Did the old scene2d tutorial change since then? It seems like there is an up-to-date tutorial in the wiki now :/ ... my bad probably

Hm, what was the “old” scene2d tutorial? I’m not sure there was one. About 8 months ago, Nate published his last API changes to scene2d and put up the two articles that are currently on the wiki.

I agree, i myself have to lookup scene2d things every time. The examples at the bottom of the scene2d.ui wiki page help me get back into the flow.

I dont check the news so to speak, so I dont know if this was ever adressed: But at one point you fixed and broke the following “small thing”: when you had flipped textureregions the height, or width whichever was flipped had a minus value for the size… so getRegionWidth() or height would return a negative value. Since some version it was “fixed” and only returned positive values in all cases… which is good, but it broke some code for me which I iterated by using the negative value as a stepsize and such.

@Cero, that was a looong time ago, but I think it was me and I forgot to blog about it. Oopsie. :slight_smile: This shouldn’t ever happen again now that we have a new system in place where we document API changes in a CHANGES file, which makes for a central place for people to check for this sort of thing if all hell breaks loose after updating your app to the latest libgdx:

You should, otherwise your complaint rights will get revoked :smiley: