This release makes some internal changes to gdx-liftoff to hopefully address issues with gdx-tools and LWJGL3 conflicting, updates Gradle to 6.3 (which should allow Java 14 to be used; it could already be selected), and uses libGDX 1.9.10 both for user projects by default and for its own UI. This release may be less compatible with high-DPI screens because it uses LWJGL2 to show its UI instead of LWJGL3, but this should allow the texture packer to work from Gradle scripts.

This release is roughly the same in features as the last one, except that you can select Java versions from 7 to 14 smoothly on the Advanced tab, and the Gradle version projects will use is now 6.1.1. I don't know if Gradle 6.1.1 will be compatible with Java 14 when its final version is released, but you can use gdx-liftoff with Java 13 today.

This release is identical to 1.9.10.2 in most ways, but the Android project generation was pretty bad; I think it wasn't generating usable Android projects, or if it was, they needed some attention. This appears to fix Android project builds as long as you have all of your Android SDK installation in order; Android plugin version 3.5.0 seems to work well. It also turns off the daemon by default; it appears that some Android tasks run in the daemon use a phenomenal amount of RAM and don't give it back to the OS, meaning multiple daemons will quickly consume quite a lot of RAM.

It's another release! Java 13 is out and now so is Gradle 6.0, which is the first version to support Java 13. This gdx-liftoff version defaults to Gradle 6.0, and though there's still no convenient way to choose language level 13 in the app, you can set it by changing sourceCompatibility in your desktop and/or lwjgl3 modules and core. It's still probably a good idea for some usage to use language level 7, which is what libGDX uses, but many projects can upgrade to level 8 at least. Java 9 and higher are, of course, not compatible with Android, iOS, or GWT.

This release doesn't change much; it does make the GWT version non-selectable by users and instead matches the correct GWT version for the selected GDX version, since the two must change in lockstep. Hopefully this will fix lingering (unreported) issues with GWT versions when using gdx-liftoff.

This release primarily exists so the default version is 1.9.10, but it also makes some changes to match the official setup's support for resizable GWT applications (and it includes a useful part of a currently-unmerged PR, libgdx/libgdx#5691 ).

There's not many breaking changes in libGDX 1.9.10, so it's unlikely but possible that projects using 1.9.9 would encounter breakage. There are several breaking changes from 1.9.8 to later versions, so if you're updating from further back you may encounter some issues. I made this Gist that you can use to replace SpriteBatch if the changes to Batch color handling between 1.9.8 and 1.9.9 (and persist into 1.9.10) are a problem; in the uncommon case where rendering sets the Batch color extremely often, especially using packed float colors, then that Gist is something to try because it will make the API match 1.9.8 and should perform better if colors are being packed into floats often.

This updates Gradle to 5.5.1, with a surprising lack of frustration this time; the update process seems to be smooth now. The README.md has been updated to reflect how the lwjgl3 module uses jar instead of dist to generate runnable jars. The GWT files have been updated to match the official setup's resizable option. Other than that, this is just a minor release.

This release is a bugfix for an uncommon bug that could nonetheless be very frustrating when encountered. The copyAndroidNatives() task in Android's build.gradle wasn't getting called because of a change in what IntelliJ and/or Gradle (5.4.1) accept for valid plugin configuration. This was leading to APKs that built but instantly crashed when run, though I believe only when Kotlin was used with Android (the kotlin-android plugin was the issue). It has been fixed at least for projects that use the build.gradle to handle tasks. There were various constant warnings or errors in the eclipse and idea tasks for Android, so I just removed them from the Android build.gradle; using the IDE to build Android applications probably wouldn't even work for Eclipse and it would change with every update for IDEA. A quirk of the Android projects now is that they will preemptively copy Android natives to the folder where they are needed, and will do so before you build (actually, when you load the project). This is fairly quick, but may be unexpected.

There is a partially-known issue with LWJGL2 (legacy desktop) applications when run on MacOS; I suspect the default ApplicationAdapter template is doing no drawing at all, and so garbage VRAM is showing through in the window. It may go away if the screen is cleared as it normally is, but I don't have a Mac to test on. This doesn't happen for LWJGL3 (new desktop) or any other targets/platforms, so using LWJGL3 is even more encouraged.

This fixes a bewildering but fairly minor bug in the pack task with the default GUI assets, affecting at least the scene2d.ui template. If you depended on gdx-liftoff to generate GUI assets before, which is unlikely because they didn't work at all, they have been moved around and are now correctly in assets/ui/. It updates the dependency version for RoboVM/MobiVM, and also updates the version for the crowd-pleasing library typing-label along with its new GWT dependency info. The .png assets inside the jar have been optimized as best as I can losslessly, so the jar is a little smaller and project file sizes may be too. A few leftover assets from SquidSetup, which uses a squid tentacle as an icon, have been swapped out for the consistent space shuttle liftoff icon used here.

It's a setup application for libGDX that Just Works with Gradle 5.4.1, and so Just Works with Java 8-12 (at the least), and so should be a useful way to make new projects, especially for first-time libGDX users. This release is a minor improvement for some users, but is important if you develop LWJGL3 projects on MacOS. Before, the critical -XstartOnFirstThread argument was missing when the Gradle lwjgl3:run task was executed, which caused no problems on Windows or Linux, but blocked the task from running on MacOS. This is fixed. The version of Gradle in generated projects is now 5.4.1 instead of 5.4 . Generated files use tabs for indentation, which are more agreeable to more users than the previous mix of 2-space and 4-space indentation.

You use this much like the other setup jars: assuming you have Java installed (AdoptOpenJDK is recommended), you can run gdx-liftoff-1.9.9.2.jar like any other jar on your OS, and plug in the project name, project package, main class name, project directory, etc. Make sure to check any platforms you want to target; LWJGL3 or "new desktop" is recommended for all projects and is selected by default because it makes it easier to debug. Android is also selected by default and you can uncheck it if you don't intend to target that mobile OS. You can add optional JVM language support; Kotlin should be up-to-date in the 1.3.x branch but other languages are probably going to need updating in your project yourself. You can add various official and third-party extensions (third-party libraries) from the big lists on other tabs, and choose a different starting sample project template if you want. The Advanced tab lets you choose a different minimum JVM level (1.7 is safest for Android, but desktop-only can be 11 or 12 easily), a different libGDX version, and so on; most of the defaults are probably fine to stay with unless you want to use Java 8's Streams and lambdas, which would mean switching Java version to 1.8; a quirk of the naming convention means the setup can't generate projects that need Java 10 or newer, but you can configure that in the generated projects if you are sure users will have that version. When you're ready, press Generate; it's much faster than the official setup for various reasons. You should import the build.gradle file in your chosen project directory in your IDE of choice; the rest of usage follows the libGDX documentation.

I hope this can be useful!