BrokenBlog ? Blog Archive ? How to Make a Massively Cross

quasiceo 2014-01-20

展开全文

November 23rd, 2011

I’ve been working on a game engine recently, and here are some of my experiences and lessons learned. Despite the title, there are many ways to approach this problem, and this is just the one I took.

So, what’s massively cross-platform? It’s a rejection of the ideology of picking a single toolkit or environment (Flash, Unity, XNA, iOS, Android, etc) to base code in. It’s about making the game itself the model in MVC programming with the controller and view being handled by whatever environment I’m porting it to. Many of these toolkits are cross-platform, but sometimes they have poor performance, limited functionality or don’t support many of the targets. I wanted to support everything and have it perform well across the board, which involves four major areas…

The Desktop. Linux, OSX, and Windows. The easiest to target, due to the ubiquity of free and open-source tools for these platforms.
Mobile. Android and iOS (maybe Windows Mobile 7). More limited in options, and wildly different in some ways, but the basic set of tools are readily available.
The Web. IE, Chrome, Opera, Firefox, Safari. The most unusual of the four targets, because of the limited choice of languages.
Consoles. The Xbox 360 (and/or XNA), PS3, and Wii. Excluding XNA, expensive to target. Still, there’s a lot of similarities between them and the desktop target. I haven’t gotten around to this part yet because it’s expensive, so it’s not covered here.

So, basically I want to write a game engine that can support 9+ wildly different platforms, and have it be pretty easy as well. Turns out it can be done.

Choosing a language (or the core environment)

So, at the core of this game, I want to write game code once that can be shared amongst the different ports. I also wanted the nice warm embrace of a quality scripting language, with minimal impact on speed. Here’s some of the options I went through until I found the right one.

Javascript

The web target is basically the hardest to target, since there’s really only Javascript, or Flash, which is also basically Javascript. I could go the Unity route as well, but a good web developer should avoid requiring plugins whenever possible. There’s also Java applets, but I’ve had lots of problems with applets in the past and they’re not particularly user friendly.

So, why not use Javascript itself and clear up the web target problems easily? I tried finding a portable Javascript runtime but had trouble. Rhino, the Javascript interpreter for Java, seemed plausible for Android. I could probably manage with V8 on the desktop. Initial research suggested I couldn’t use iOS’s Javascript interpreter easily, and V8 wouldn’t meet iOS’s code execution guidelines. This seemed like a minefield of potential problems, plus I had a huge bias, I don’t like Javascript over some of the other possible choices. I decided to look elsewhere first, but ended up never looking back.

PyPy / RPython

At this point I felt if I could get something to compile to C or LLVM bitcode I could make it work. I found a project called emscripten that converts LLVM bitcode to Javascript. Additionally, if this didn’t work there was always Alchemy, which does basically the same thing for Flash.

I started checking out PyPy, or more specifically, RPython. Python being my favorite language to code in, it might be perfect for the job. I could even get PyPy to generate C that seemed vaguely usable. PyPy however seemed to be made solely for creating binaries, not C code or llvm bitcode. Additionally, many cool Python features were not available in RPython, so there was just no way I was going to get the full Python experience. I moved on.

Ruby

Perhaps… Ruby? Rubinius compiles to llvm. Unfortunately, it was easy to determine that this was not an option. Oh well.

Haskell

I tried getting ghc to generate LLVM bitcode, but this was consistently troublesome. It could also generate vanilla C, but this was also difficult. I tried getting ghc to use Alchemy’s tools directly, but they just never worked.

Then… Lua

To me, Lua was a toy language, something that non-programmers used to program. This isn’t true. It ended up being my final choice and proved itself to be a top tier programming language. I was impressed by it quickly, and was confident I could get it onto my desktop, mobile, and console targets with ease. Still, there was the web target, but I found ways around this problem, which I detail below.

Choices I didn’t investigate fully

Lisp. A solid lisp implementation could be easily ported everywhere. I think this would’ve been my choice had I not found Lua.
Javascript. I abandoned this choice pretty early. While I think Lua is a better language to work with for this kind of thing, Javascript still remains a valid possibility.
haXe. Created by Flash demigod Nicolas Cannasse, it could potentially be compiled to every target mentioned. It didn’t fit in well with the manner in which I wanted to develop this game though, and the C++ targeting didn’t seem mature enough, so I looked checked out other options first.
EDIT: playn. This was suggested in the comments, I never tried it out during this project. It does not currently support iOS and Console environments, and relies on Java, but it’s open-source and so it’s possible I could do that myself. Worth investigating.

Porting Lua to everything

Each platform usually had it’s own quirks and needs, so I had to figure out the best way to make Lua work on each of them.

Lua on the Desktop

There were no real problems here. I used Lua 5.1, and it just worked. Eventually I switched to luajit 2. Not because I needed the performance boost, which luajit did give me, but to familiarize myself with luajit’s much more complicated build process so I could use it in other targets. Both are fantastic pieces of software, but I would say only use luajit if speed is very important.

Lua on the Web

I first tried compiling Lua using Alchemy. Lua compiled easily, but some hastily made speed tests placed it at a few hundred operations per second, which is extremely low. I decided to try working with emscripten instead. It was also pretty easy, but my first live test of lua code running via the lua runtime via emscripten via a Javascript interpreter was also extremely slow (EDIT: This may have changed, emscripten now has emcc, a tool which may offer significantly better speeds than what I experienced). It seems obvious in retrospect, but I was hoping for the best. In the end it could barely manage 10 fps, even with rendering turned off.

I still stuck with Lua however, and wrote a Lua->Javascript source code translator called lua.js. This would avoid any speed problems due to Alchemy and emscripten. Javascript turned out to be a good host for translated Lua applications, approaching near-Javascript speeds.

I’ve open-sourced this translator, which you can find here.

Lua on Android

Originally I used standard Lua which compiled easily for Android. When performance was a problem, and improvements to the rendering had already been made I switched to luajit. Luajit 2 is in beta right now, and for unknown reasons crashed on Android with JIT turned on, but it can be turned off. There was a slight speed boost, but overall the rendering was still the problem so it may not have been necessary. I talk more about that below.

Lua on iOS

I didn’t waste any time here and went straight to luajit. Not much needs to be said about it, although the JIT compiler cannot be used on iOS because of Apple’s code execution guidlines. I have seen some suggestions that this is not true in certain cases, but if it didn’t seem necessary anyway.

Graphics

The easiest path here is to keep the art simple, at least at first, so I decided to make a 2D game. Generally speaking 3D games are more time-consuming and expensive as well. Knowing what I know now, it’s very possible that each target could handle a simple 3D game. For my own sanity though, I kept it 2D. Take a source image, draw it to the screen at a location. That’s it.

Drawing on the Desktop

I first went with SDL 1.2. It’s stable, wildly popular and portable, and also surprisingly slow. It turns out 1.2 is pretty much exclusively a software-rendering system with no vsync. The result was choppy animation that tears, and has a lower framerate than I’d like. I tried SFML, but found the API lacking, and for a while settled on Allegro 5.0.4. Allegro 5.0.4 has a lot of potential, but is rough around the edges, little niceties like the transition to fullscreen on OS X were missing.

I then decided on SDL 1.3, which is still being developed, but I haven’t had any problems. The core set of features I wanted all have worked flawlessly. It basically combined all the nice things about SDL and Allegro, with none of the bad things. Performance improved and the game looked smooth on all platforms.

Drawing on the Web

Originally, I figured Flash was the best option for this, since traditionally it’s been much faster to render in Flash. As I discovered, this changed with the advent of Canvas and HTML5, but I still wanted to support Flash for any users that might not have Canvas available. I tried several different drawing methods (copyPixels, using Bitmaps) but performance was worse than Canvas in every browser I tested, regardless of the method used. Compared to Canvas on Chrome, it was around 4x slower. With some extreme effort, I’m sure Flash could improve, but even still it didn’t think I could ever reach the dizzying highs of 60fps in Chrome. I eventually dropped the Flash target entirely, since it couldn’t meet my standards. I figured letting users play a poorly performing game would give them a bad impression, and soliciting them to upgrade their browsers was actually a better choice.

Drawing on Android

I first used Android’s Canvas, but it was way too slow. Apparently there’s hardware acceleration for Canvas in Android 3+ but I couldn’t see a performance difference when I tried to enable it, and I still wanted to support 2.x if possible. I then wrote my own OpenGL renderer, that mostly relied on glDrawTexfOES to draw images. It was much faster but still too slow.

I managed to find libgdx, and was immediately impressed. The fps doubled immediately compared to my more naive solution. libgdx is so good, I’d use it on the desktop targets if it didn’t require the user to have a Java VM installed.

Drawing on iOS

I was expecting this to be easy since iOS is popular and libgdx left me feeling positive about rendering libraries for mobile platforms, but all the choices on iOS either didn’t fit into my display model or weren’t free. Mostly both. I reluctantly wrote my own OpenGL renderer for iOS, but this time I learned a little bit more about what keeps performance high on mobile devices and relied on a method that used glBufferData and glDrawElements instead. The performance ended up being what I wanted, even on an iPhone 3G.

Audio

Like the art, I needed to keep audio simple. There are event sounds, which play once, and background sounds, which loop forever but can be stopped at any time.

Audio on the Desktop

Originally I planned to use whatever audio system was available with my display library, but after switching around I disabled sound in whatever library I was currently using and looked elsewhere. The first was libao, but it was prohibitively licensed. I investigated a couple alternatives, including PortAudio, until I eventually I found OpenAL. Despite a high learning curve it met all my needs, including some I didn’t think I had. It also favored pushing data over polling data (callback-based audio playback being pretty common), which was great since I wanted event sounds to be as responsive as possible.

OpenAL just plays sounds, it doesn’t decode them, so I embedded libogg and libvorbis, so I could play Ogg Vorbis files. Unlike other formats, using Vorbis doesn’t require me to pay a license. I eventually switched to stb_vorbis though, which is an entire Ogg Vorbis decoder in a single file, because it simplified my build process and appeared to be faster as well.

Audio on the Web

There’s only one real choice here, the HTML5 audio tag. This was also the most worrying, since delays in sound playback can’t really be controlled and I don’t have the option to seek an alternative. Overall though, it seemed to work great across all browsers.

Audio on Android

MediaPlayer seemed to work just fine.

Audio on iOS

I had some performance issues here when I used AVAudioPlayer, so I wrote an OpenAL version instead. It was better overall, but the game still runs significantly slower during sound playback. This is actually an ongoing problem, so I’d say my next option would be to try a good sound playback library for iOS, since the selection seems a lot better than the rendering libraries for iOS.

EDIT: Audio issues were CPU-bound on my iPhone 3G, so I found a compressed audio codec that iOS supports called IMA4. The files it generates are much bigger, but CPU usage is much much better. I found details on how to encode IMA4/CAFF files here. I use Extended Audio File Services to decode the files, and the data is then passed to OpenAL.

Posted in Actionscript / Flash, MXNA, Programming | 40 Comments ?

40 Responses to “How to Make a Massively Cross-Platform Game”

ben Says:
November 23rd, 2011 at 1:38 pm
Nice read, thanks for sharing your findings.
Will probably save a lot of folks some time!

Out of interest, having never played with HAXE, what about it didn’t suit your needs. Did you want something more scripting based?

Oh and one quick quibble:

“a good web developer should avoid requiring plugins whenever possible”

“a good web developer should use the right technology for the job, if a plugin is not necessary to get the required result (including performance, cost, maintainability…), then there is no need to use one”

Par example,
To achieve what you could in unity in one day could take a month in js and still perform much worse.

Anyway just a small wording thing, I only picked up on it because people often take whatever they read to heart without questioning or testing for themselves.

Thanks again for sharing your findings
Max Says:
November 23rd, 2011 at 10:02 pm
I honestly don’t remember everything about why I moved on from haXe. I remember fighting with it to install and use haxelib libraries in a folder of my choosing so I could commit everything haXe-related to source control. The whole experience was like this, I wanted things to go a certain way, but haXe was trying to take care of that for me and doing it in a way I didn’t want.

This is not a good reason to avoid haXe because I had to fight with other software as well, but at the time I figured I’d have better luck with another language. That’s why I mentioned it might still be useful to others.

I don’t think avoiding requiring plugins and using the right technology are mutually exclusive. I said “avoid” not “don’t use”. Requiring a long plugin installation process for a large percentage of users was not the right technology for this project, unless other options were not available.

Additionally, Javascript met my needs, and browser-only Unity is unlikely to offer me anything better. Not in cost, performance, or maintainability.
Virgil Dupras Says:
December 28th, 2011 at 5:10 pm
Shameless plug, but you might want to read an article I’ve written on this subject: http://www./articles/cross-toolkit-software.htm

The problem with this type of software is to decide how much responsibility you give to your core code.
Markavian Says:
December 28th, 2011 at 7:31 pm
I’m looking at massively cross-platform web-development from a PHP perspective with Flash AS3 (FlashDevelop/Flex SDK) for rapid prototyping.

By building the core data model and business logic (game logic) in PHP, and then connecting up webservice calls to my flash IDE, I can rapidly write and test features.

The Flash IDE can be used to rapidly create layouts (much faster then I could build a (PhotoShop > CSS) layout (or other OOP + Assets).

The idea being that I can develop a production product quickly, and once I’ve nailed down the details, cross over to another language for a platform specific build.
Max Says:
December 28th, 2011 at 8:14 pm
Virgil: Pretty much. This was a game engine so minimal native code is needed, putting almost all the responsibility on the core code.

Markavian: Massively cross-platform means a meta-platform, which yours is not, so it’s not massively cross-platform. Additionally, latency problems make it impossible for some kinds of interactions to be put on the backend.
Donavan Says:
December 28th, 2011 at 9:11 pm
Or you could just use a product designed for cross platform game development like Unity..,
Max Says:
December 28th, 2011 at 9:30 pm
Donavan: Relying on Unity is the antithesis of the goals of this project. Unity does not support Linux, the Nintendo (3)DS or the PS Vita, and I have no control over that. If there’s a performance or functionality issue, I have no options available to me, because I have no control over the runtime. For the web target, I would have to require users install a plugin. My options for tools are limited and formats proprietary. Using certain features or targeting certain platforms costs money.

Not having these kinds of restrictions allowed me to do some interesting things that would otherwise be impossible, and I learned a great deal about things that Unity would hide from me.
Hermann Says:
December 28th, 2011 at 11:42 pm
“Javascript isn’t exactly known for portability though”.
I don’t really get that statement for Javascript works pretty much everywhere.
Max Says:
December 28th, 2011 at 11:55 pm
Hermann: You’re right, that comment doesn’t make much sense, so I modified it. I just meant that the Javascript VMs aren’t as lightweight which I felt was linked to portability.
azakai Says:
December 29th, 2011 at 12:31 am
I wonder, did you optimize the Emscripten-compiled Lua interpreter? Emscripten’s new emcc makes it pretty easy to do so, and optimized code is orders of magnitude faster than unoptimized code. There is a tutorial at

https://github.com/kripken/emscripten/wiki/Tutorial

and more optimizing details at

https://github.com/kripken/emscripten/wiki/Optimizing-Code

If you are still interested in the Lua=>JS route, I would be happy to help with this (I work on Emscripten).

- azakai
Max Says:
December 29th, 2011 at 12:46 am
azakai: Hi! I love emscripten, I think compiling languages to JS is the future (hence lua.js) and I think emscripten is a big part of that.

I don’t recall encountering emcc when I tried emscripten, which was last summer. Even so lua.js converts Lua very directly to JS code, while emscripten would still have to rely on the Lua runtime. Since speed is extremely important to this project, lua.js is the best option for me right now even if emcc offers some significant gains over what I originally tried.

Out of respect for your project I’m adding a note about emcc, so I don’t discourage the use of emscripten. Emscripten is the superior choice for those who want high compatibility with Lua 5.1, which lua.js does not offer.
azakai Says:
December 29th, 2011 at 12:54 am
Max: Ah ok, your not seeing emcc makes sense since I just landed it a week ago

Yeah, I think you are right: Directly converting Lua code to JS will be faster than running the Lua interpreter through Emscripten. Emscripten should be able to get to the speed of handwritten JS, but the *interpreter* is compiled here, since there is currently no good way to generate LLVM bitcode from Lua.

The cost is the loss of compatibility (both library functions and some language features), but if you can live with the subset of Lua you are compiling, that sounds like the right choice.

Side note, the best way to run Lua (or Python or any dynamic language other than JS ) on the web would probably be to compile a VM to JavaScript using Emscripten, and have the VM JIT directly to JavaScript. This would give full compatibility, and just as good performance if not more than directly compiling Lua to JS. But, it would mean writing a JS JIT backend for a Lua VM, and that Lua VM would need to be compilable into JS itself – I don’t see a good candidate for that (with Python, PyPy might be a good candidate, I don’t know enough about it to be sure though).

- azakai

P.S. Thanks for writing this blogpost! Very interesting stuff.
rlyeh Says:
December 29th, 2011 at 4:02 am
lua+moonscript is a good combo too : )
Paul Says:
December 29th, 2011 at 1:58 pm
Why not just use Corona SDK? It uses Lua, work on all platforms already, has a physics engine and network support ?
Matthew Turland Says:
December 29th, 2011 at 2:43 pm
There appear to be a few instances where you ended up rolling your own solution for a given problem, but haven’t opened the source (or at least haven’t linked to it). Any chance we’ll see that happen? Excellent post, by the way. Chock full of good content.
Mark Harper Says:
December 29th, 2011 at 4:15 pm
Have you considered PlayN?
http://code.google.com/p/playn

You write in Java and compile to Android, desktop, HTML5, and Flash.
Todd Says:
December 29th, 2011 at 4:17 pm
You might be interested in Moai too – a new open source Lua game engine and cloud platform for iOS, Android, Chrome, Windows, Linux and Mac. Getmoai.com
Wolfos Says:
December 29th, 2011 at 4:29 pm
Or you could just use C++ and SDL, leave the consoles be and use NaCl for the web.
Kay Says:
December 29th, 2011 at 4:40 pm
Can you show some code about your engine? Particularly iOS/Android integration would be very interesting.
Making Massively Cross-Platform Game | BushidoIT Says:
December 29th, 2011 at 5:44 pm
[...] really becoming more and more important tool in creation of games. Whole article can be read here: http://blog./2011/11/how-to-make-a-massively-cross-platform-game/ It may be a really nice tutorial for many unexperienced developers. You should check it out if [...]
Max Says:
December 29th, 2011 at 6:36 pm
Paul: Corona costs money and doesn’t support all the platforms I want to support. I honestly don’t know that much about it, but it appears to be proprietary enough to limit my options when dealing with technical problems.

Matthew: Most of the code you’re talking about is just connecting commands from Lua to whatever api is needed. Besides that, there’s lua.js, which I have open-sourced. What else do you mean?

Mark Harper: I wish I had known about this before I started, I would’ve given it a test drive. Still, it doesn’t support console environments or iOS. Since it’s pretty open-source I might’ve been able to do that myself though. I’m adding a comment about PlayN in my post.

Todd: Moai is seems interesting, although having to sign up to download the SDK is a huge turn off. It appears to use NaCL so it lacks real web support right now and doesn’t support consoles. It seems possible I would be able to add support for these things though, since it’s open-source. It seems like an interesting project, worth checking out.

Wolfos: NaCL isn’t the web, it’s Chrome, so it would lack true web support. SDL support for various platforms is limited or broken depending on the version, and the api changes significantly between versions. I would use SDL on most of these platforms if it was the best option anyway, but this project isn’t limited to a single rendering library — that’s the point. I also mentioned I wanted the warm embrace of a scripting language. C++ makes writing game code more complicated and I am just one programmer.

Kay: The Android code is very straightforward, it just uses libgdx and MediaPlayer, and uses the JNI to bridge the C code to the Java code. This iOS code is more complicated, since it involves sprite sheets and a more complicated OpenAL driver. I’m not sure what you’d glean from it that I didn’t mention above though. The OpenGL code focuses on using glDrawElements to glBUfferData to cache and draw as many sprites as possible with fewer OpenGL calls. The OpenAL code isn’t really worth it, because sound is still a problem on iOS.
Todd Says:
December 29th, 2011 at 8:46 pm
Thanks Max.

The signup is for Moai SDK + Moai Cloud. You can get the Moai SDK directly by itself at https://github.com/moai

We would definitely welcome your contributions to Moai!

Covering every possible platform means a lot of tradeoffs. We have optimized for mobile, then native desktop and Chrome via NaCl. I agree that Chrome NaCl isn’t the silver bullet for all possible Web browsers, but it’s the least painful path in our experience to go from Lua to a browser environment, cover a third of the market (the third that actually plays games in a browser) and also the Chrome Web Store helps you with the distribution of your apps.

I’ve yet to see anyone deliver a great HTML/JS solution for games that is performant enough for our needs of making casual physics and arcade style games. I’ve seen demos on a desktop browser but very little compelling content that runs on a phone.

We haven’t focused on consoles, but the Moai engine is pure C++ and OpenGL and has already been ported to embedded TV devices. Of course, you can’t get to XNA from here as you already noted, but in reality less and less developers focused on consoles today. There are more iPads than Xboxes in the market today, and the phone an tablet market is growing at a much quicker rate with a much more developer friendly distribution infrastructure than the console business.
Aaron Snoswell Says:
December 30th, 2011 at 12:57 am
Where is part 2 of this article! I half expected to see an example / link to a github project at the end! Can’t wait to hear more!
Victor Says:
December 30th, 2011 at 1:27 am
Hey there,

I am interested in what made you drop portaudio? I have also tried both portaudio and OpenAL. And I decided it would be portaudio for me.

Thanks.
adamredwoods Says:
December 30th, 2011 at 1:37 am
“monkey” is a massively multi-platform programming language. There’s more targets than what they have listed, as users have added NDS, Unity, among others. And it’s still young.

http://
Max Says:
December 30th, 2011 at 5:17 am
Aaron: No plans for a part 2, I’m not sure what I would put in it.

Victor: I kept notes on different things I tried, but forgot to write down why I dropped PortAudio. I wouldn’t worry about it, it was probably just preference.

adamredwoods: Not bad, but it’s proprietary, doesn’t run on Linux, and costs money. I assume the lack of Linux or console support is fixable, but that’s also a problem. For this kind of project it’s not useful, but it still seems worth trying.
Bruno Says:
December 30th, 2011 at 5:17 am
Regarding haXe and C++, wondering if you came across NME http://www./ it does magic
Max Says:
December 30th, 2011 at 5:36 am
Bruno: I did not. It seems pretty good. I would’ve definitely checked it out if I went with haXe.
Writing a cross-platform game ? justaguyinphilly Says:
December 31st, 2011 at 5:56 pm
[...] was an interesting post on writing cross-platform games: http://blog./2011/11/how-to-make-a-massively-cross-platform-game/ Share this:TwitterFacebookLike this:LikeBe the first to like this post. Uncategorized games [...]
dodgycoder Says:
January 4th, 2012 at 12:50 pm
Great article – thanks for detailed explanations. I think your solution sounds very much like the Moai open source project. I have just posted a blog article on modern cross platform development toolkits for those interested here.
Max Says:
January 4th, 2012 at 12:56 pm
dodgycoder: Somone already brought up Moai in the comments. Like most projects people bring to my attention it’s definitely very cross-platform, but doesn’t achieve the same level of platform independence that the goals of this project required. I liked your article though, it was an interesting read, thanks for sharing.
devu Says:
January 5th, 2012 at 8:54 pm
Nice article, just looking for different options here and there, however regarding to Drawing on the Web

“Originally, I figured Flash was the best option for this, since traditionally it’s been much faster to render in Flash. As I discovered, this changed with the advent of Canvas and HTML5″

Seriously? Can you tell me what you have been using and testing exactly on both sides? Especially on Mobile devices?

Because it sounds like you compared AS2 vs Canvas. JS as a runtime is 3 times slower than AS3. In many cases Flash is a good fall-back on Android devices. Drawing API looks even worst because something has to control it. Canvas itself is not doing anything at all. It might get better with GPU acceleration though but JS is still a drawback. I’m really curious.

Check out my blog/Speed Test if you don’t trust me.

Thinking of tandem like AS3 controlling Canvas for above reason IF canvas will get advantage over flash on Mobile Devices. Because will get closer to Flash GPU Stage3D in terms of performance but will be better for 2D content.
Max Says:
January 6th, 2012 at 12:22 am
devu: I mention some of the techniques I tried to improve Flash’s speed, but I found it to be consistently slower for this game. I have not found JS to be 3x slower than AS3 (I never used AS2 for this project), but actually quite a bit faster in most browsers for this project. This could be due to the fact I favored JS-style scripting over AS3 classes, but regardless, rendering also remained very slow in Flash compared to a Canvas equivalent in all browsers I tested. Like you say, some browsers were definitely using the GPU here to gain an advantage, so it’s possible using Stage3D could help. Basically, I tried to make it work with Flash but after enough time spent pursuing dead ends I decided it wasn’t worth struggling with for this project.

All of the above only refers to JS and Flash on desktops, since there was a native version for mobile devices.
Alessio Says:
January 25th, 2012 at 12:10 pm
Are you using libgdx on android via lua?
Max Says:
January 25th, 2012 at 2:08 pm
It’s a bit complicated, but I don’t see how to improve it right now so here’s how it works. I have code that deals with Lua written in C and code the deals with libgdx written in Java, and they call each other using the JNI. When a frame needs to be executed and drawn, a native function is called in Java, which actually calls a JNI’d C function. The C code then interacts with Lua, and calls a function in the Java code that draws elements, which is done using libgdx.
Sylwia Wilk Says:
February 6th, 2012 at 11:29 am
Hi Max,
My name is Sylwia and I’m writting from Software Developer’s Journal magazine.
Would you be interested in writting an article for us?
Our next issue will be entitled Cross Platform Development.
I think you can contribute relevant materials for our magazine.
Please let me know if you are interested in contributing.
My mail: sylwia.wilk@software.com.pl
Cheers
Sylwia Wilk
Editor of SDJ Magazine
Steve Longhurst Says:
March 6th, 2012 at 12:08 pm
Thanks for a very interesting article, I’m currently thinking about such massively cross platform solutions myself and your insights are very useful.

How do you approach debugging on the different platforms?

Whenever I’ve used multi language solutions in the past, it’s always been debugging that gets really nasty. You’re usually left with only print calls, nothing fancier.
Max Says:
March 7th, 2012 at 4:54 pm
Steve:

The actual game code in Lua was always pretty stable and straightforward, so a stack trace was always enough. I wrote an error handler that delivers one since Lua doesn’t do it by default. I was able to get every platform to at least dump print and error messages to a console, although any serious Lua debugging was always done on Linux, since it’s the easiest to develop for.

For Javascript code (including code converted from Lua to JS) I used the programmer tools in Chrome, for Objective C on iOS I used XCode tools, for C and Java on Android I used the Android SDK, for C on Linux/OSX I used gdb. For Windows I compiled the code and prayed, I don’t have a great solution to that one yet.