Categories
Looking glass
Navigate/Search

Lua and XNA

After seeing if Managed C++ work under XNA, I would try and do something useful and get Lua working. But safe mode only meant a nightmare porting Lua. It would be easier to port Lua to C#… So looking around I saw the Lua2IL project.

Started by the original author of Lua, it was a Lua 5.0 byte code to IL converter which sounded pretty good. While it does mean running the Lua scripts through a compiler first before hitting the 360, as that what the content pipeline was for didn’t feel like much of a big deal to me.

The first oddity is that Lua2IL’s website seems to have disappeared from the internet for last year or so. I bit of searching using the Wayback machine and I had my hands on the zip file. It was fairly easy to get it ported and running on the 360, the next big step was producing a Content Pipeline plugin that would auto convert a .lua file and have it ready to load.

This proves much trickier than expected. .NET Compact 2.0 will only load from on disk files, Content Pipeline expects everything to go through .xnb. I have a solution but its not ideal, so something to come back to. The other real stumpy is the way AssemblyBuilder handles paths, simply put it doesn’t, give it a path anywhere and expect and really odd error… Took me the best part of week, and help from the XNA forums before I solved that one…

Also Lua2IL only a very minimal Lua runtime library, as its running on the CLR virtual machine, All the base libraries need writing. I’ve done a few, still more to go but hopefully the main ones, or at least those useful in a game script engine will be done soon.

So the upshot of all that, is that Lua runs on the 360. You can drop .lua files into GSE and have them dynamically loaded and run on the 360, which is nice. Cos Lua is a lovely language for entity customisation and things like that.

So still got some work to do before a public release, tidying up, finishing up the runtime libraries etc, but still even before that if your interested in running Lua code under XNA (including 360) give us a yell.

I’ll write some more at some time, at some of the issues and problems I’ve had. Some are simply yet really annoying, things like no plugin support in GSE means no syntax highlighting, even tho the plugins are written and freely available on the web. Would be nice if MS would grant permissions ( AFAICT Express can run them, it just needs a key) for a few of the community plugins that would make GSE even better. Also I need to send a few request in about some changes to the content pipeline, it feels very designed at the moment for thing like producing .xnb files, while that nice, it could do with some better support for when you can’t do that (in this case its .NET Compact thats causes me not to use .xnb, I have no choice)

4 Responses to “Lua and XNA”

  1. Zygote Says:

    Awesome info. Let us know when you have something we can check out :)

    Thanks,
    ziggy

  2. waruwaru Says:

    Hey cool! I like Lua, a very cool language. I worked on DSLua (Lua for the Nintendo DS) awhile back. Looking forward to check it out! :)

  3. rock Says:

    Heja…
    You dont have to use the Content Pipeline to get files loaded. Especially for scripting it would be better to load the files dynamicaly without “compiling” it before.
    Anyway i hope we see this sooner than later.

    markus

  4. Deano Says:

    You do have to compile the scripts because the Lua parser is in C and until its ported to C# or at least a safe CLR language it can’t run on a 360.
    If its PC then yeah you can do it all in one step, the approach i’ve done to get this on 360 is to do the C Parser and IL emit stage on the host PC in a content pipeline plugin and then host and use the CLR VM with a Lua like environment on the 360.
    Advantages: Lua is JIT
    Disadvantage: You have to compile to lua to IL (via byte code) before hand.

    But to be honest, as the only way of getting files onto your 360 is via GSE having to pre-compile really isn’t that much of a problem.

Leave a Reply