Good job!

Awesome, sounds like a ton of good updates! Still haven’t used all the great stuff that was already there, so have to spend more time “exploring” everything

Thanks for putting so much time into it for all of us!

The new ui framework is straight up sexy! Have just implemented it in my main menu and settings classes with buttons and fields being skinned with the Skin example in gdx-tests. One question, do you mind if we use a modified version of the skin in our production code?

Also I’ve been looking at using the new AssetManager stuff and a blog post or a quick writeup on the best practice on how to use it would be much appreciated, any chance of getting that? Top stuff guys

i also just realized, after following some basic tutorials about libgdx and growing fond of it, that it’s not supposed to work inside a live wallpaper, which was also my use case. i currently do all the rendering stuff manually in my lwp and it seemed to be a waste of time and resources since some good libs like libgdx should also do the 2d rendering, just better.

i tried the lwp-backend project with the recent libgdx, but i got tired after adapting the first dozen of classes. it’s clearly outdated and i think it’s not even a good idea to continue updating it since the initial approach is just wrong: it consists of a bunch of copied classes from libgdx, stripped and modified to work with a wallpaper service instead of an application. that at one point one of the copies gets left behind and falls apart is not surprising.

even if it was up to date i think you would have to refactor the classes anyway as you also don’t want to have mostly duplicated code in two locations. it’s a clear sign that a design is not up to the task it’s used for.

so i wonder in how far you intend to adapt libgdx to also work within an lwp context? if one diffs the files from Elijah with the originals one can clearly see that he mainly removed or worked around some assumptions that libgdx makes internally about it’s context, mainly being an application with activities, not a service.

i think that someone who knows the control flow of the current implementation well enough should be able to move the common part of those files modified by Elijah into abstract classes and derive from them, one application-based and one service-based class. that would combine both versions in a maintainable way.

the question is of course if you intend to do this or if you are not interested in live wallpaper support for libgdx.

btw, just as a sidenote: after realizing the current state for lwp usage i tried andengine, which is supposed to support lwps out of the box. this project seems to be in a desolate state altogether. on the main page they link to google code, but it turns out there you will just find old remains of the project, the current sources are on github. then you get all the projects from there and the stuff doesn’t even compile.

then you start wondering, check the forums and yes, there are lists of which classes you have to modify how to make it work. so people commit changes to the official repository that lead to compilation errors and this state is then kept for months. not really a code base i want to invest much of my time into.

there are also private repository clones some people created due to those problems, but they resulted in even worse problems when i tried them. then you can’t run the examples in the emulator as even the basic ones require ogl 2.0 and the emulator is broken since april if you enable gpu emulation. there are loads of bug reports, but google doesn’t seem to care, the answer is use the linux version, only the windows gpu emu is broken.

then i tried it on my phone and was disappointed to see much lower performance than i had hoped for for several of the demos. i know my nexus one is not up to date anymore, but that really put me off.

my preferred framework would clearly be libgdx at this point: active developers, good performance, documentation and the wonderful ability of testing things on your desktop. if it just came with official wallpaper support

maybe you can take a look at the required changes to integrate this into one of the next versions, my impression is that it’s not overly time consuming if you know the insights.

i’m still on vacation for a few more days and the weather isn’t great, so i’ll try my best to get something out of this situation

first i’ll try to fix the lwp project setup (it doesn’t compile against the gdx project but against local jar/lib file copies), clean it up (remove duplicate gdx classes that were only copied but not modified) and make it run again with the latest libgdx. in the end it should consist of just the handful of classes that had to be modified to work with a service instead of an application.

as i have no idea what limitations Elijahs version had i can’t say for sure that i wont make it worse, so once i get some of the few examples Elijah used to render within an lwp context i consider this step done

the question is if you’re interested in such an intermediate version to integrate it into libgdx? intermediate since it won’t be launching the full gdx test suite, so it’s not possible to check if every feature works in the lwp context (i strongly doubt that). it wont be a full integration but a proof of concept. like Elijahs project, just a bit cleaner and up to date