libGDX 1.9.7 released

libGDX 1.9.7

Update time. All brought to you by Tomski, marking the first time in libGDX history that someone else did the release!

Heres ya loot drops.

Important and breaking changes

GLFrameBuffer has been refactored

For creating standard FrameBuffers, FloatFrameBuffers, and FrameBufferCubemap use the new static methods in the respective classes.
For creating custom FrameBuffers, use the respective FrameBufferBuilder.

An example for building a custom FrameBuffer with multiple colour attachments and a depth attachment:

GLProfiler has been refactored

In order to support Lwjgl3, GLProfiler has been refactored to be instance based instead of static.
Create an instance of GLProfiler by passing in the Graphics interface. Feel free to make the instance you obtain static.


- Update to MobiVM(RoboVM) 2.3.3
- Add iOS 11 support
- Update to Lwjgl 3.1.3
- Update to MOE 1.4.0
- API Change: GLFrameBuffer has been refactored Create standard FrameBuffers with static methods. Customized FBOS with FrameBufferBuilder
- API addition: Tiled group layer support 
- Fix Tiled properties, offset parsing for image layers
- API addition: Added utility methods for Vector equals with epsilon
- Fix Animation backing array type
- Fix Mesh copying with 0 indices 
- Fix restoration of pooled particle effects scale
- Fix loss of controller listeners on reconnect
- Added basic kotlin project generation support in the setup tool
- API addition: Allow APK expansion to be used in fragments and activities
- API addition: Added color properties support from tiled maps
- API Change: Added rotation vector sensor support on Android
- API Change: GLProfiler refactored for OOP and lwjgl3 multi windows
- LWJGL3: The creation of additional windows via Lwjgl3Application.newWindow() is now deferred, with postRunnable(), until all existing windows have been updated. This fixes a potential native crash with NVidia GL drivers on Windows, presumably caused by a GL context conflict.
- API addition: Lwjgl3WindowListener.created() is called after a new window has been created. It's unsafe to call Lwjgl3Window functions in between Lwjgl3Application.newWindow() and this callback.
- Updated LWJGL3 backend to 3.1.3.
- Lwjgl3Graphics.setUndecorated() and Lwjgl3Graphics.setResizable() now delegate their work to the respective GLFW functions.
- API addition: ProgressBar.isVertical() - returns whether a progress bar is vertical or horizontal.
- API Change: SplitPane now by default does not allow the split amount to shrink children below their minimum sizes (cropping them). This behavior can be reverted by overriding clampSplitAmount or wrapping the children in Containers set to minSize(0) and fill(). SplitPane also now correctly includes the handle min size in its own min size calculations.
- API Change: SplitPane.getSplit() renamed to SplitPane.getSplitAmount() to match other getter and setter names.
- Improved internal Timer synchronization.
- API Change: List#drawItem, added float width parameter.
- API Addition: Make it possible to disable sound on the GWT-Backend with disableSound=true.
- API Change: ScrollPane setWidget deprecated in favor of setActor to match other APIs.
- API Change: removed JGLFW backend
- Fixed mixed up use of TexturePacker.Settings.stripWhitespaceX|Y.
- Added joystick POV support to LWJGL3 controller backend.
- Added support for 2d particles sprite animation.
- API Change: ParticleEmitter getSprite, setSprite, getImagePath, setImagePath are now getSprites, setSprites, getImagePaths, setImagePaths.
- Added support for 2d particles independant scale X and Y.
- API Change: ParticleEmitter getScale, matchSize are now getScaleX/getScaleY, matchSizeX/matchSizeY. Added scaleSize(float scaleX, float scaleY)

Happy coding,
The libGDX team

libGDX 1.9.4 released

libGDX 1.9.4

Summer’s almost over, time for a release! Here’s what’s new (plus a ton of bug fixes, see the commit logs on GitHub.

- Moved snapping from ProgressBar to Slider to prevent snapping when setting the value programmatically.
- Bullet: added btSoftBody#getLinkCount() and btSoftBody#getLink(int), see
- API Change: Wrapping for scene2d's HorizontalGroup and VerticalGroup.
- Fix hiero problem with certain unicode characters. See
- Switched to RoboVM fork 2.2.0, fixes incompatibility with Android Gradle plugin and iOS 9.3.4

Please update your projects as usual.

If you use MobiDevelop’s RoboVM fork make sure to update your Eclipse/IntelliJ IDEA/Android Studio plugin. It works with iOS 10 devices, but does not work with the Xcode 8 beta just yet.

In other news, Multi-OS Engine has been open-sourced by Intel. It’s now being maintained by its originator, Migeran, who previously sold the IP to Intel. We will update to the OSS version in the coming week(s) and do another release.

Happy coding,
The libGDX team

libGDX 1.9.3 released – New iOS backends

libGDX 1.9.3

Been a while since the last release. Here’s what’s new!

- Switched to MobiDevelop's RoboVM fork (
- Addition of Intel Multi-OS Engine backend for deploying to iOS
- Updated iOS native build scripts to iOS 9.3 and TVOS 9.2
- API Addition: GestureDetector#pinchStop() called when no longer pinching
- API Addition: API added to Graphics
- API Addition:, grab the GL version and implementation type.
- API Change: Lwjgl3WindowListener -> filesDropped(String[] files) adds drag'n drop support for the lwjgl3 backend
- Added isComplete() to ParticleEffect to make it easier to know when all the emitters are done, behaves the same as in the 2D API.
- API Change: renamed Lwjgl3WindowListener.windowIsClosing() to closeRequested() to better communicate its intent.
- Add IndexData.updateIndices method to increase performance when used with IndexBufferObjectSubData. 
- Added FlushablePool
- Added ShapeCache see
- API Change: moved shape builder logic out of MeshBuilder, see:
- API Change: Table reset now calls clearChildren, not clear.
- Fixed crashes in when isPlaying is called. Errors are now logged only rather than crashing the app.
- Added emulation of ScreenUtils for GWT
- Improved performance of glReadPixels() on GWT. New method is 20-30 times faster
- Fixed crash on Mac when using LWJGL2, custom cursors and embedding the game in an AWT window
- Fixed getDisplayModes(Monitor monitor) returning wrong data on LWJGL2 backend
- Fixed Gdx.input.getCurrentEventTime() not being set on LWJGL3, fixes GestureDetector and flick scroll not working
- Fixed not being able to select non-latin characters in TextFields
- Bullet: added CustomActionInterface, see
- Add window size limits option to LWJGL3 app and window configurations

Please update your projects as usual.

Now for the juicy bits. New iOS backends!

Re-evaluating our iOS strategy

A few weeks ago, we announced changes to our iOS backend strategy. With RoboVM winding down, we need a new way to get to iOS in the future. After an analysis of various alternatives we decided that Intel’s Multi-OS Engine is the way forward.

The post received a ton of feedback from all over the community. Many people within the community and the libGDX core team feel uncomfortable with relying on yet another proprietary piece of technology like Intel Multi-OS Engine. BugVM was mentioned as an alternative, which is a fork of the old RoboVM OSS project.

MobiDevelop and Xoppa gave BugVM a whirl and concluded that its name is not too far from the truth. The Gradle and IDEA plugins are broken in various ways, everything has been renamed, and many fixes of dubious quality have been applied. It is also unclear who is behind BugVM, what the release schedule is, and how contributions are handled. Finally, the whole repository is a mess and hard to maintain.

As a result, MobiDevelop created his own cleaned up fork of the last OSS release for RoboVM (version 1.8) from September 2015. Since then, Xoppa, MobiDevelop and Tomski have added various improvements to the fork. The guys have performed the first release of the fork, version 2.1.0, so there’s a stable version out there already. If you plan on using RoboVM in any capacity going forward, I’d suggest using this fork over any other forks. Keep in mind that there’s still the bitcode issue which is unlikely to ever be fixed.

Going forward, we have decided to provide two iOS backend options:

  • The new Intel Multi-OS Engine backend
  • MobiDevelop’s RoboVM fork

In order to support both Intel Multi-OS Engine and the MobiDevelop’s fork, we had to make some changes to the setup UI that generates your libGDX projects. You can now select either “ios” or “ios-moe” (or both if you want to compare) in the setup UI.

Each backend comes with pros and contras that we’ll look into below.

Using OSS RoboVM

When selecting “ios” in the setup UI, the resulting iOS project will depend on MobiDevelop’s fork, with groupId “com.mobidevelop.robovm” and version “2.1.0”. If you have an existing project, change the RoboVM related groupIds in your build.gradle to com.mobidevelop.robovm and the roboVMVersion to “2.1.0”.

New projects will automatically use the MobiDevelop RoboVM fork. If you want to switch a new project to the last official RoboVM build, change the com.mobidevelop.robovm groupIds to org.robovm and the roboVMVersion to “1.14.0”.

The MobiDevelop RoboVM fork comes with an Eclipse and IntellIJ IDEA/Android Studio plugin which you can install in your favorite IDE, just like the official RoboVM. This will allow you to compile and run your iOS app without a command line. The Gradle plugin is also fully functional and used by your Gradle builds. Find out more on the MobiDevelop RoboVM fork site.

The existing RoboPods have a dependency on the last official RoboVM release. They have not been tested with the MobiDevelop’s OSS RoboVM version. MobiDevelop will eventually also fork the RoboPods. Contributions welcome!

Pro & Contra OSS RoboVM

Since the MobiDevelop’s RoboVM fork is based on the last OSS RoboVM release from September 2015, there are of course a lot of limitations:

  • No debugging support
  • No TvOS support
  • No interface builder support
  • No bindings for the latest iOS versions
  • None of the proprietary bug fixes done by the RoboVM team since September 2015 are included. Everything that got fixed in the open-source portions has been included in the fork
  • RoboPods may or may not work
  • No Maven support, as libGDX is Gradle based
  • No Junit support, not useful for libGDX anyways
  • No RoboVM Studio. IDE plugins are enough, and RoboVM Studio doesn’t add much for libGDX game development
  • Not bitcode compatible

Here are the upsides:

  • Drop in replacement for RoboVM
  • Working IDE plugins for Eclipse, IDEA and Android Studio
  • Working Gradle plugin
  • Known source, release schedule and contribution policy
  • Stable and tested

Using Intel Multi-OS Engine

When selecting “ios-moe” in the setup UI, the resulting iOS project will depend on Intel Multi-OS Engine. Before you can create a new project, you need to install Intel Multi-OS Engine.

Once your project is generated, you can follow the Intel MOE documentation to get a better understanding of how it works. The workflow will be very similar to RoboVM, i.e. you create iOS run configurations in your IDE of choice, or invoke Gradle tasks on the command line. Tomski is working closely with Intel to improve the workflow and stability of Intel MOE together with libGDX. Due to that collaboration, Intel MOE now also installs a plugin for IntelliJ IDEA instead of just Android Studio.

Pro & Contra Intel Multi-OS Engine

Let’s start with the contras:

  • The libGDX backend is not as mature
  • RoboPods won’t work, all 3rd party libraries need to be bound anew (though that may be easy with the binding generator)
  • You need to have Multi-OS Engine installed for the Gradle build to work. The MOE Gradle plugin is not available in any repository. If you haven’t installed MOE locally, your Gradle build will fail
  • No Eclipse support
  • Higher build times on code changes as everything needs to be proguarded and dexed

Here are the pros:

  • Actively maintained, with bitcode in the pipeline
  • Debugging support
  • Interface builder support
  • Automatic-binding generator
  • Bindings for latest iOS APIs
  • Can compile from Windows if you have a Mac OS X build slave

Up Next

We believe giving you the choice on what technology stack to build your games is the right thing to do. Which of the two options will ultimately pan out is hard to say at this point. There are risks associated with both of them.

For Intel MOE, we hope to receive feedback over the following weeks and months that we can communicate to Intel to improve their solution. Please report any issues you find on the Intel MOE forums or on the libGDX issue tracker if it’s a problem with the libGDX MOE backend.

For RoboVM, it’d be great if the community could look into RoboPods and see if and how they work with the OSS RoboVM version. The best course of action would be to integrate them with MobiDevelop’s fork, push them to that repository and integrate them with the build. Furthermore, Xoppa and Tomski are working on getting line numbers in exceptions working, which is the precursor for (non-JDWP) debugging.

We have updated most of the wiki with new instructions for Intel Multi-OS Engine. If you miss something, speak up on the issue tracker!

Happy coding,
The libGDX team