Look at the log file referenced in the error message. Describe what you are doing, what platform etc.

you need to duplicate the borderpixels of each tile. libgdx's texturepacker can do that for you.

citation needed...

@alaslipknot We power about 3.5% of all installed Android apps. 2% of the top apps. http://www.appbrain.com/stats/libraries/details/libgdx/libgdx We are on par with Unity on that platform. Even Google uses libgdx for their augmented reality game Ingress. We also have a few games on steam, and had strong usage in the last ludum dare. For a Java game dev library, that's pretty neat, and much more than i ever expected.</ad>

On the topic: i'm of the opinion that you should know what you do. There's nothing wrong with learning OpenGL. Whether you do that with LWJGL, JOGL, libgdx (You can accesss OpenGL ES 1/2 in a cross-platform manner) doesn't matter. davedes has a very nice lightweight lib for LWJGL that you can use if libgdx is to much of a hassle to setup. You'll be limited to the desktop, and will miss more advanced features, but that's enough to play around with rendering techniques.

Concerning the setup hassles: i hear you. That's what you get if you try to deploy to more than just the desktop. I personally do not thing that the burden is that big, order of installation is JDK, Eclipse, Android SDK/ADT, GWT, and optionally Xamarin.iOS. Not a lot we can do about that. For those who want to only develop for the desktop, that's easy as well. Don't use the setup ui, create a new project and link to gdx.jar, gdx-natives.jar, gdx-backend-lwjgl.jar and gdx-backend-lwjgl.jar. Add a second source folder that contains your assets and off you go.

TL;DR: learning low-level stuff is awesome and will make you a better person. What tech you chose does not matter a single bit.

It's a know bug i haven't come around to fixing yet. Your solution is interesting, i thought i needed to reinitiate the entire thing. Should be easy to fix. If someone happens to have a pull request before i get to it i won't be mad

Awesome. I'll update libgdx next week, which should gain you a few more testers on OSX. Thanks for all the hard work!

heh, it was a joke i've been making since the KS ended, usually multiple times a week on gtalk or when you stayed at my place. i know how much money's left over after all parties take their share, and it's not something i aspire to. I'm quite happy with how things are, and certainly not bitter

Poor little thing. Quick, dry your tears with all your KS moneyz.

Neato! Glad submission worked out as well. @scene2d: don't go there, it's a dark place!

You should, otherwise your complaint rights will get revoked

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.

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.

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?

Looks like shit's getting real: https://bitbucket.org/openjfxmirrors/openjfx-8-graphics-rt/src/008bdab5b9fbd5c56ace638874141cfc83be69d3/glass/glass-lib-ios/src/GlassApplication.m?at=default

My god, Rel, is that you? QB45, FreeBasic, etc. Not sure if you remember me, marzec here. Man, it's been 10 years. Glad you are still active

Working on that. Also on the roadmap: world peace, making sandwiches and coffee.

Coming from a country where i pay almost 50% taxes on my income, i would not assume that

How many folks do you employ? I quick back of the envelop calculation tells me that you actually make quite a bit of money if those numbers stay somewhat constant.

It's the best city in the world.

Thanks for the input so far folks. I guess we'll try our like, even if our chances are minimal

I put together an initial draft of ideas a student could make into a full-fledged proposal, see http://code.google.com/p/libgdx/wiki/GoogleSummerOfCode2013

If you have an idea, feel free to post it here and i'll try to incorporate it.

I for one am not working on OSS full-time

Hi,

a few of us libgdx contributors conspired and thought it would be a fun idea to try to take part in this year's Google Summer of Code. Google essentially sponsors students for 3 full months to work on OSS projects for which they handed in a proposal. You can read about our motivation and plan at http://www.badlogicgames.com/wordpress/?p=2877

What i'd like to get is feedback on whether you think this is actually worth it, whether you'd be interested to take part as a mentor or student, and also write about any creative ideas for projects you can come up with.

You can either post your feedback here or over on our forums (as linked to from the blog post).

Thanks a bunch,
Mario

Having to wrap Android APIs via JNI to call into them from Oracle's VM sure sounds like an efficient use of someones time.

I bet they use Zero on iOS. Reason being that JavaFX "does all the heavy lifting on the GPU", which is of course bullshit. I also wonder how interop with native UI APIs is meant to be done, e.g. integration of IAP dialogs, advertisement etc. If they ship their own VM on Android, that might be an interesting excercise in frustration, having both Dalvik and their VM coexist and communicate.

Played around with it some more. Couple of observations:

• uses Android's/Harmony's class library, so all limitations of that apply (no AWT/Swing, inferior implementation compared to Sun's)
• One assembly file is generated per class, with straight mappings to Java class methods etc. Looks like this:
• Previously compiled and unmodified classes are cached, recompilation of a project is very fast for native compilation (way faster than what i experience with MonoTouch, could just be me doing something stupid though...).
• JNI is supported to a degree that all of our libgdx core JNI code works (haven't tested the bullet wrapper yet though). Just needs to be compiled as a static lib and everything works out of the box. This actually worked on first try, i'm still surprised
• The resulting binary is pretty big at least on my test target, elf32. It's about 12mb.
• Loading classpath resources works, as oposed to the IKVM/MonoTouch solution
• Debug symbols are emitted for the assembly code generated, meaning you can somewhat comfortably debug assembly. Better than nothing, e.g. what you get with Avian
• Building binaries is very easy compared to Avian, together with the fast recompilation that's a huge plus.

I'm gonna try write an experimental libgdx backend with this for Linux, Mac OS X and iOS. Not a fullblown one, just enough to get all the demo games somewhat running. If that works out i'll invest time to write a proper backend.

TL;DR: looks promising, still waiting for the first crash.

I didn't rip anything off, i just didn't search for a RoboVM post assuming nobody discovered it yet. I'll pay davedes his lost... wait, what exactly did he lose?

jupp, vmkit would have been nice indeed. seems like all these solutions have the drawback of not supporting debugging :/

Essentially yes. Lots of questions though. I only had a few minutes to look through the source. Seems like Soot is used to parse class files, those are then emitted as LLVM IR. No direct LLVM binding. Uses Android's runtime libraries for better or worse, meaning all the nasty Harmony bugs are likely to be present. No idea which GC is used.

http://www.robovm.org/

This looks very promising. Still early days, but the LLVM backend is a good thing as it lets one target a lot of platforms and it optimizes things quite well.

Released way after libgdx glad you figured it out.