Phil Hassey - game dev blog
Phil Hassey as Syndrome
"Look, stores don't sell
costumes like this to just anyone."

Lua on Javascript comparison – lua.vm.js, lua.js, lua.js-phil, lua5.1.js, native

So I spent a bit of extra time this week messing with my Lua on Javascript stuff for game jams. Here’s the resulting game Turkey Tomahawk Turbo.

I checked out the following Lua on Javascript implementations: lua.vm.js, lua.js, and lua5.1.js. I also made a fork of lua.js called lua.js-phil.

Here’s the short summary breakdown:

– lua.vm.js: An asm.js (emscripten) port of Lua 5.2. It has slickest web presence, but WORST implementation. It’s crazy buggy and doesn’t work for anything beyond the cool tech demo. If you really like what they have so far, you’ll want to spend a week or so fixing their API so it actually works for non-trivial programs. I never got my game working fully with this due to sporadic runtime errors and other mess.

– lua.js: A script that converts your Lua script to Javascript. The official distribution works great, but it is missing some functions so you’ll may have to modify your program somewhat to work without those functions. (The string formatting and pattern matching is not implemented.)

– lua.js-phil: A fork of lua.js. I added string.format and improved performance by making the following assumptions: you will not use meta-methods (__index, __call) for anything but calling functions / methods. You will not use the math meta-methods (__add, …).

– lua5.1.js: An asm.js (emscripten) port of Lua 5.1. It has a very nice working API that is exactly like the C API, so if you are used to integrating Lua in C, you’ll find it pretty easy to integrate with your Javascript program. It is a build of Lua 5.1, so no missing functions or other quirks.

Here’s the performance data in FPS. For comparison, with Lua running on my Mac, I got 400 FPS.

Chrome 31

Firefox 25

Safari 7

IE 10

Average
lua.js

51

50

20

110

58
lua.js-phil

72

59

32

160

81
lua5.1.js

85

75

4

60

56

So to conclude, lua5.1.js would be my preference, except asm.js code takes a horrible performance hit on Safari, and a non-trivial performance hit on IE. Once all browsers are optimized to work with asm.js code, that would be the best option for sure. Since I was able to modify my game (about 5 lines of code different) to work with those restrictions I mentioned above, I was able to get pretty good performance with my fork of lua.js. The original lua.js is quite good, short of the missing functions.

Lastly, there have been many claims of how “you’ll get near native performance using javascript, especially now that we have asm.js and emscripten” and whatnot. Well, I’m sure in theory that’s great and all. But no matter how I slice it here, I’m getting a 4x+ performance hit by running my games on the web. Still I’m impressed by what I’ve seen and I hope more work goes into getting asm.js support in browsers so we can get nearer to native performance!

-Phil

P.S. You can download the whole mess with build scripts and the various Lua things here.

Comments are closed.