Been a while since the last release. Here’s what’s new!
[1.9.3] - Switched to MobiDevelop's RoboVM fork (http://robovm.mobidevelop.com) - 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: Gdx.graphics.setUndecorated/setResizable API added to Graphics https://github.com/libgdx/libgdx/pull/3847 - API Addition: Gdx.graphics.getGLVersion(), grab the GL version and implementation type. https://github.com/libgdx/libgdx/pull/3788 - 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 https://github.com/libgdx/libgdx/pull/3953 - API Change: moved shape builder logic out of MeshBuilder, see: https://github.com/libgdx/libgdx/pull/3996 - API Change: Table reset now calls clearChildren, not clear. - Fixed crashes in AndroidMusic.java 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 https://github.com/libgdx/libgdx/pull/4025 - 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
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
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!
The libGDX team