Ok, I already mentioned the good, here is some of the bad I came across so far:
3rd party libraries like LWJGL or JOrbis should not be bundled together with LibGdx' own classes.
The benefit is small, potential problems are big if you get version conflicts if other libraries do the same or if you have to switch versions manually.
I had to downgrade OpenAL, upgraded LWJGL and had to remove duplicated JOrbis classes due to using Pauls's SoundSystem.
Furthermore, attaching source code for gdx-backend-lwjgl.jar to both LibGdx and LWJGL is not (directly) possible with Eclipse.
We made that decision early on. For 95% of our users it makes live a lot easier.
Same is true for bundling and extracting native libraries. Core application files should be installed under one roof (except user data). No auto extraction.
For installing, the most simple solution is the best. Supply the path to the libraries. Clean and simple.
Each library should get auto generated build entries with date, time and version number.
That's a good idea, i'll add that if i find the time.
I might be the first who is not using the official lifecycle stuff. Unfortunately, constructors of LwjglGraphics are not public, neither is it possible to create a LwjglInput on your own.
LwjglGraphics#setupDisplay is not public, etc.
It is ok to offer an easy-to-use setup and lifecycle, but people should not forced to use it, unnecessarily. I can assure you LibGdx works fine without
So, I had to take the ugly way, create a com.badlogic.gdx.backends.lwjgl package and move three of my classes into it.
Just upgrade the package scope to public. It is a framework, people are inventive of how to use it...
"Don't be forced to use anything, pick and choose."
I have to provide Gdx with a GdxApplication although it is just an empty class skeleton, a NullPointerException is the reply if omitted.
We can't anticipate all funky use cases of course. The only assumption we make is that you use Application and ApplicationListener. XNA is a framework as well, i'd like to see how you can rip out such a part from it
Furthermore, we try to keep the public API as slim as possible. Exposing internal methods is bad (both public and protected), we might change things in the future, people will cry rivers if their stuff breaks.
I don't understand the inheritance hierarchy of Actor. First of all, its long. Then, why is a Button a table ? Seems like widgets and layout are mixed up.
And if so, why are the other widgets like Label e.g. no tables ?
Because Buttons are composite widgets with children which need to be laid out (e.g. labels, images etc.).
In my code to build a screen with a few centered button I put this line months ago:
button.padBottom(20); // oddly high value required
Without that the text was painted outside the button borders. At least it used to. Today with Libgdx 0.9.6 the behaviour changed.
Back then, I couldn't figure out whether I was doing something wrong or whether it was buggy.
As announced on the blog and twitter multiple times (our only way to get info out to folks), the scene2d API changed quite a bit. We generally do not break APIs, in scene2d's case we made a big exception. We were diligent to inform everyone of this change.
Also, bugs get fixed occasionally, i hope you don't hold that against us
I have no idea how to convert an existing complex Swing UI into Libgdx.
Not exactly something we can help with. I have no idea how to convert a complex Swing UI to QT, wxWidgets, Tk etc. either.
I started with "Beginning Android Games" which is quite good even though I still don't have an Android device.
But I learned all need to know about OpenGL from it.
An updated version for Libgdx with all of its features would be nice (don't know if its possible, I vaguely remember reading about some legal issues)
The book has nothing to do with libgdx. Granted, the framework developed therein looks familiar, but that's about it. A book of similar scope using libgdx is out of the question.
Eventually, there need to be complete (yes!) JavaDoc. The web site states it is full, which is, well not quite true.
Ya, working on that ourselves and via 3rd party pull requests. Again, we aren't doing to terrible compared to similar offerings. Which is not to say we won't invest more time in making it better.
There are too many places between you have to jump back and forth to find required information.
Not sure what to say to that. That's the nature of big APIs i guess?
I did not find a history document listing all changes between versions.
We list those on the blog, giving an overview. We also have release tags in the SCM repo, if you want to know the exact details you can run through the commit history.Various
Feeding the sources to a dependency analyzer like JDepend shows a dependency mess only excluding 3 of all packages.
While not all shown dependencies are first level, there are cases like com.badlogic.gdx.math which relies on com.badlogic.gdx.math.collision
or com.badlogic.gdx.graphics needing com.badlogic.gdx.graphics.g2d
Pixmap seems to be more generic than Gdx2DPixmap but in fact it messes a lot with Gdx2DPixmap.
Generally there should be no dependencies pointing deeper into the package hierarchy, only the other way round.
This is very important for a library design. For the ongoing development when LibGdx evolves and grows, for splitting into modules and choosing only parts to use, to prevent from becoming an unmaintainable monolith.
Yes, there are some dependencies that i'd like to losen up. However, the mantra that a package shouldn't rely on a deeper package just isn't always applicable nor useful. I'm 100% certain that math doesn't rely on g2d, unless someone else (NATE) did a bozo. Pixmap is a wrapper around Gdx2DPixmap so we aren't dependent on the concrete JNI APIs of Gdx2DPixmap. Changing native methods has a cost, changing wrapper methods is trivial.
There are a lot of public fields which is owned AFAIK to the slow nature of Dalvik. I never messed with Android, so I can't really argue against it. But it's not nice. From looking at it, the information you get is "so all of this is being modified from all places of the library".
Yupp, we try to reduce those one by one were possible and were performance on Dalvik won't get hurt. There are still tons of 2.x devices out there, and all suffer from poor method invocation performance. We do sacrifice cleanliness for performance on Android.
Methods with 17 (!) arguments are just unusable.
Agreed, which method are you refering to?
Thanks for taking your time writting this up. I'll try to incorporate a few of your suggestions as time permits.