Libgdx goes HTML5

update #2: and another port, basilisk ported his game bumble, see below. F’ing A!
update: twbompo already ported his game QB :D, see below

I wrote a GWT backend for libgdx over the weekend and ported Super Jumper. Click on the below screenshot to try it out. You need Firefox/Safari/Chrome/Opera 11 with WebGL support. You can also run it in Opera Mobile on Android or on the Xperia Play browser. If nothing shows up, please check if WebGL works on your browser/OS/GPU combination, e.g. by trying some of the WebGL experiments. If nothing helps, i’m afraid your browser/OS/GPU isn’t cool enough. Use your mouse to navigate through the “menus”, use the left and right arrow key to move the dude ones you clicked on “Ready?”.

Stefan Wagner, alias twbompo, already ported his game QB. Click the image below:

And here’s another quick port by basilisk from Molded Bits.

This means we can now compile libgdx apps to Javascript and have the run natively in the browser. The code runs totally unmodified (save for 2 fixes due to Super Jumper formally being a GLES 1.0 game. Just removed glEnable(GL_TEXTURE_2D) and cam.apply(gl10). Check the SVN if you don’t trust my word, the gwt project for Super Jumper is in there as well :)). The port took 10 minutes, setting up the GWT project in Eclipse took most of that time.

What’s done

  • Graphics fully implemented, full GL ES 2.0 capabilities. There’s some space for optimizations.
  • Input 90% implemented, need a solution for Input#getTextInput()
  • Files 80% implemented, files are preloaded before the app starts. They will be fetched from the browser cache on second startup. Files are accessed via Gdx.files.internal, so your code can stay the same. Currently you can’t read binary files, i’ll try to work around that with a few tiny tricks, no promises.
  • Most of the graphisc classes like Mesh, ShaderProgram, SpriteBatch, TextureAtlas, BitmapFont and so on are fully working
  • All of the math classes are fully supported.
  • Almost all collections in utils/
  • More stuff i forgot.

You can check out this file to see which libgdx classes you can currently use. I have to gradually include more classes and check if everthing still works.

What’s left to do

  • Audio, most likely leveraging Sound Manager 2 which falls back to Flash if the audio tag doesn’t work
  • Preferences and local files, most likely implemented via the Web Storage APIs.
  • Binary file support. This one is a bit harder to do with regards to caching, but it should be possible. XmlHttpRequest to the rescue (screw IE)
  • Making sure the rest of libgdx compiles and works (scene2d, some stuff in the packages utils and g3d).
  • Figuring out a good way to embed GWT apps into any web page

What i’d like to integrate eventually

  • Web Sockets. The GWT Quake 2 port did i, so can we. This would mean the inclusion of a new module for libgdx that provides networking capabilities. So far this was unnecessary as all backends have access to the standard Java networking classes.
  • Mobile HTML5 apis, e.g. anything that PhoneGap exposes (multi-touch, accelerometer etc).
  • App cache support, so you can play offline.

What you won’t be able to do with the GWT backend

  • Native code, obviously. That also means no Box2D, unless you use JBox2D or the cleaned up version by the PlayN guys.
  • Concurrency, Javascript is single threaded, there’s no way to do anything fancy. However, we can easily abstract things like http requests via callbacks. Web workers seem to be in their infancy at the moment, and communication is done via message passing. A Java-compatible version of that is unlikely (e.g. concurrency primitives you usually work with won’t be available)
  • All the caveats of GWT apply. Reflection is not available, which is a pain because our awesome Json class relies heavily on reflection. A lot of standard Java classes aren’t available either in GWT. I did my best to port over a few crucial ones, like most of the and java.nio package from Harmony/Avian/gwt-quake-2. Big shout out to those projects, and Stefan Haustein in particular, who did a lot of ground-work with gwt-quake. Standing on the shoulder of giants here 🙂
  • Local file storage will be limited. I’m new to this html5 stuff, but if i’m correct, then you can store just a few mb on the client side.
  • Other things i overlooked so far, e.g. integration of in-app purchases and so on. Given that we use GWT, the simple interface approach you already use on Android/desktop should work here as well.

Where’s the code?

In SVN. Check out the gdx-tests-gwt project and the superjumper projects. If you want to play around with things, check out the SVN trunk, import everything into Eclipse, make sure GWT is installed and away you go. I’ll post a full guide how to setup a desktop/android/gwt project once i’m done with the above list. Note that running GWT projects in hosted mode is terribly slow and not representative of the real performance. Think Android emulator…

What about PlayN?

After Google I/O last year i contacted the guys. They were not really interested in a collaboration (yeah, i was kinda disappoint). They were aware of libgdx at the time, which is unsurprising given both frameworks have a very similar architecture and target audience (it’s a pretty obvious design choice :)). Here’s why i think that libgdx might be more valuable in the end. It is also not meant as an attack on the project, i sincerely like what they guys pulled off (especially their non-Google contributors which seem to keep the project going). The work Ray Cromwell did on the GWT backend is fantastic, he’s a beast 🙂 Take the following as a justification for me to invest time in the GWT backend.

PlayN doesn’t expose OpenGL directly, as they fall back to Canvas or a DOM renderer if WebGL is not available, a good choice if you want to stay as compatible as possible. This might also be a wise decision should WebGL not get the adoption it deserves. With the GWT backend i do not aim for maximum compatibility. WebGL is a requirement, so IE is out (unless you use Google Chrome Frame maybe). I place my bet on WebGL, hence the full exposure of the GLES 2.0 like API in the backend, which enables you to do anything graphically. update: Stefan Haustein just send me a mail, he’s now working on PlayN (a good thing ™) and will add a GL ES 2.0 interface.

The Android port seems to have a few performance problems, which given the age of the framework is more than forgivable. This is something that can be solved over time. Libgdx does not sacrifice anything in that regard, it’s probably as fast as can be given it’s Dalvik/JVM heritage.

The Flash port is basically dead, which is kinda sad. In my opinion this was the big point for PlayN, Flash is everyhwere, HTML5 not yet.

There’s currently an iOS port in the works, based on IKVM and MonoTouch (sounds familiar?). I’m not sure if this will allow to debug the transformed Java/CLI code in MonoDevelop, but if it does it’s a pretty cool thing. What’s less cool is that MonoTouch costs 399$ in its most basic version. My work on the Avian based iOS backend is currently on ice, i can’t stem all of the work i’d like to do at the moment. Avian would mean no debugging support (unless i can add a JDWP bridge, which is unlikely, Avian is a complex beast). It currently also means no FPU support, the ARM backend emits software float code. An ARM emitter with FPU support is in the works it seems, not sure about it’s current state. There’s a lot of drawbacks using Avian, but in the end it is fun to do something a tad bit more complex from time to time, and it would mean i don’t have to pay for MonoTouch. PlayN has an easier time targeting other platforms like consoles should the Mono port come to fruitation. Avian can be made to work there as well, however, the dependency on OpenGL is a major drawback.

The build system of PlayN seems to be based on Maven with all its benefits and complexities. At the moment it seems to put off beginners, eventually that might be a big plus for PlayN. The more platforms you support, the harder it can be to setup a project. Whether Maven is the way to go in terms of dependency managment and project setup is another story. At the moment it seems to be hard to escape the claws of Maven.

Documentation is a big issue, for both projects. I like to think that we are a tad bit ahead in that regard, i might be totally wrong. Our forums seem to be filled with a lot of knowledgable people that actually help out, we have a few video tutorials to help absolute newcomers and mostly complete java docs. For libgdx, i think we are on the right track. We still lack a unified tutorial/dev guide system. PlayN is still in the process of gathering a community. Again, the age of the project probably plays a major role in that regard, and given time this can and will improve.

In the end it’s a matter of taste and targets. Choose your poison 🙂

32 thoughts on “Libgdx goes HTML5

  1. This is very, very, *very* cool. Being able to turn any libgdx Android game almost trivially into a web game is a great plus.

  2. This is huge. I was just rewriting my solitaires code to HTML5 (with canvas), I will definitely try this approach. HTML5 might open the doors to porting libGDX to Windows 8.

  3. Sad that the PlayN guys didn’t want to cooperate. For me, Flash backend was the biggest selling point on PlayN. So, nothing changes, I’m (even more eagerly) still using libgdx. 🙂

  4. Very nice… I’m always curious when there is relative silence on your blog in regard to what big bomb is going to be dropped next. ;P I pondering GWT and all myself recently. Once I get all the ducks in a row over here (yeah still working on that daily) I’ll be taking a good look at all these shoulders to stand on including your and the libgdx communities work.. Keep it going! 🙂

  5. Heavily nice. I always wondered if you sleep during nights. Now I’m sure you’re a vampire. Very nice job.

    I’ll be happy to write a detailed tutorial on how to deploy with GWT, once I’ll understand how to deploy with it. Shouldn’t be too long (I hope).

  6. hey, thanks a ton for the post, really helpful and a great news for the entire libgdx community. Really looking forward to the post u write when u’ve ported your first game

  7. Brice, you can already use it if you go with SVN. I don’t want to package jars until it’s stable enough (getting there fast).

  8. Wow Mario, still unbelievable what you achieve here!

    Your Move to the Web is the right one, as even Google want’s to unify all Games as “Google Games”, not split up anymore under Android, Chrome or what else. And Websockets will play a major Role in that, of course.

    Wouldn’t it be smart to use the Native Api from Chrome, to allow Box2d to run here too? It seems to me that Chrome will sooner or later be the Gaming-Middleware running on my Android Phone (Beta is good already), GoogleTV, Desktop PC and Tablet.. and things like Google+ integration and In-App Payments will be available soon, too..

  9. I don’t think that Chrome will gain that kind of traction for the foreseeable future to be honest. NaCL is incredible technology, but i wouldn’t want to place my bet on it becoming relevant to big audience. I’d rather create an abstraction over JBox2d/native Box2d than have box2d only work via NaCL in Chrome. Google+ seems to be for Tech people only, i don’t see normal people migrating anytime soon.

  10. I think next time, you’ll be rejecting PlayN guys so you’d better get revenge words ready 😀

  11. That’s a retrofitted JBox2d version, the current one in PlayN’s master branch is pretty outdated. I already started porting the latest JBox2D which shares all the features of the latest native box2D version.

  12. I did a first try at porting my solitaires. In my code the only problems seems shuffle from Collections which might be hard to replace. I got also some errors with BitmapFont and ui.Label. Still, quite impressive so far, and I learned how to use GWT, which is a great plus. 🙂

  13. Mario can you please help me ? I want this game to be Open Source like your SuperJumper, but I took not my images for this game, I took them from this Game Project

    Is I allowed to take not my images for OpenSource project ? If not can you help me please to make my LineBirds Clone OpenSource with other free images like in SuperJumper ? I cannot draw that’s why I took not my images. Can you help me with this question please ? I want to share this project for all world …

    Sorry for my bad english.

  14. Mario, Thanks a lot for your amazing Open Source framework LibGdx !!! And Thank YOU Very Much for your perfect book !!!

  15. That’s a really cool game you have there. In terms of free images i’m afraid i can’t help a lot. I’m not an artist. In general you can only use assets that are marked for free use. You could check out maybe they have something you can use.

  16. Mario, what are you thinking about this cross-platform framework ? Can you port LibGdx for iOS by PLAYN Cross-Platform FrameWork ? Or can you bind LibGdx & PlayN frameworks to make One Single Cross-Platform framework (for Android, iOS, Flash, Html5, Desktop, …) ?

  17. @NanoMobile

    Hey! I saw your code and it’s pretty damn good. I was making a game similar to the classic helicopter game but instead of helicopter I am using a flying duck. 🙂 But I am stuck with one logic – I don’t just want to generate random x and y for placing objects/blocks like in a classic copter game. Rather, I want to combine that with also predefined location for placing objects. In that way I can place multiple coins in a nice pattern. Can you give some tips or a block of code that will help me generate that pattern?

    I was thinking of your code but wanted it as Unit Based so that I would know how many imaginary grid in there where I can place the blocks.


Leave a Reply

Your email address will not be published.