gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Announcements And Comments > Yet Another GBA Lua

#169703 - Karatorian - Thu Jul 30, 2009 7:43 pm

I'm working on an RPG project (please don't bring up any dead equines please, start an new thread if you must) and I figure any RPG engine worth it's salt needs scripting. I could probably write my own (I've done some small language projects before), but that'd be a lot of work. So I decided to look into using Lua. Figuring that someone had most likely already made a port, I started Googling around for what I could find.

There are a couple of interesting projects out there. There's what looks to be a mature DS port here, and, once apon a time, it seems there was a GBA port there. However, I decided to go with Torlus's project. (Well, at first anyway.)

So I downloaded and played around with it. The supplied ROM images worked fine, but I couldn't recompile it due to some issue with bitrot (my toolchain is a lot newer than the one he used). This only required a few adjustments and then everything was good. So I started to dig a little deeper into the code.

Besides having been (apparently) abandoned once the proof of concept was working, the code wasn't really to my liking. Firstly, he modified the Lua code in a way that wasn't required. I wanted to avoid that if at all possible, so I downloaded the latest Lua sources. I made a few changes to the Makefiles to add a "gba" target (but didn't change any sources, woot) and everything seemed to work great, but there was no way to be sure as it was just a library (the command line tools where of no use, clearly).

So the next task was to get Lua4gba to work by linking to the library rather than it's own custom version. This was a little trickier than I'd hoped it would be. He used his own console implementation (which is fine), but for Lua to work with it required the modified version (not so good). So, being lazy, I simply gutted his console code and used the one from libgba, which worked with the standard Lua right out of the box.

Once all that was working, I started looking at the rest of the code. I didn't really like what I saw. The code was kinda a mess. It was composed of a cut down version of "lua.c" interspersed with bits of GBA specific stuff. Basically, it was a port of the Lua intepreter, which wasn't really what I was after. What I wanted instead was to embed Lua using the normal C API (which seems much cleaner to me). So I pretty much started over.

The only part of the code I ended up keeping was the part that loaded a script from a GBFS. I split it out into a seperate function and wrote a new version of main to call it. I based my code on a couple of Lua embedding tutorials I found. It's probably not as robust as the original (error handling? what's that? =_=), but it's cleaner and much smaller.

My code works basically the same way as Lua4gba does. It loads a script from GBFS (the first file found) and attempts to run it. It's not very useful at the moment, but it could be used as the basis for something bigger.

My plans for this in the long term are a little vauge right now. The next thing I plan to do is make an option to embed just the VM and not the compiler. As tight as resources are on the GBA, the slight inconvience of having to precompile the scripts is definitely worth it. Second up will be looking at the options for number types. Lua defaults to using double precision floating point for all numerical calculations. As the GBA has no FPU, that'll have to change. Luckily, there are some compile options for alternatives, so I can hopefully avoid rolling my own. (Although I might if I decide to optimize division and modulo (likely) or do something crazy like fixed point (possible)).

From that point, I'm not really sure. If someone knows of (or is willing to write) a decent virtual keyboard, it'd be cool to do a full fledged port of the interactive interpreter. (But that's not really my aim.) Mainly, I'm going to focus on what I need for my engine, and as a lot of the design is still up in the air, I can't really say for sure what I'll end up doing.

I suppose that one could couple this with some sort of generic game engine and build a game construction kit thingy out of it. If anyone is interested in such a thing, I'd be willing to help out, but I'm not gonna do anything of the sort solo. Furthermore, it looks the the DS port I mentioned above would be a better starting point for that sort of thing.

Anyhoo, you can grab a source tarball from my website and try it out. Sorry, there's no prebuilt ROM images at the moment, but I'll get some up soon.

Comments, critques, and suggestions welcome. Thanks in advance.

#169727 - sgeos - Fri Jul 31, 2009 7:47 pm

Karatorian wrote:
and I figure any RPG engine worth it's salt needs scripting.

Correct. Lua is usually the correct choice for a canned scripting language.

Why not get in touch with Ruben and add lua to his engine if he is OK with that? It seems like two people cooperating on an RPG project would increase the chances of success by at least an order of magnitude.

Karatorian wrote:
The next thing I plan to do is make an option to embed just the VM and not the compiler.

This is a good idea. FWIW, you might need a lua script compiler that runs on the GBA or DS.

Karatorian wrote:
Lua defaults to using double precision floating point for all numerical calculations. As the GBA has no FPU, that'll have to change.

Actually, I'm not sure it will. How heavy are your scripts going to be? For now I'd stick with lua out of the can, using float or double for the type of lua_Number and fuss about something more efficient later when and if the scripting engine becomes a problem. Admittedly, switching to some sort of integer should be relatively painless, but that wouldn't be my top priority.

Karatorian wrote:
(Although I might if I decide to optimize division and modulo (likely) or do something crazy like fixed point (possible)).

Fixed is possible, evidently in hours if you know what you are doing. My first attempt failed. I have a list of places the source needs to be changed, if you want it. I'd love to see a fixed point version of lua for embedded systems.

Karatorian wrote:
If someone knows of (or is willing to write) a decent virtual keyboard,

Port the project to the DS and this problem is solved.

FWIW, I wrote a couple of lua modules to tag (RPG) messages. You can extend them with your own tags. If you want them PM me.
Code:
'I see... #PROPER(#X_NOUNS(a,potion,potions,$1)) and you want #X_NOUNS(a,gold coin,gold coins,$2) for #NOUNS(it,them,$1)?'
(0,21) -> I see... No Potions and you want 21 gold coins for them?
(1, 0) -> I see... A Potion and you want no gold coins for it?
(4, 1) -> I see... 4 Potions and you want a gold coin for them?

(Yes, the message has a bug.)

#169737 - Karatorian - Sat Aug 01, 2009 5:55 am

sgeos wrote:
Why not get in touch with Ruben and add lua to his engine if he is OK with that? It seems like two people cooperating on an RPG project would increase the chances of success by at least an order of magnitude.

Well I don't know what Ruben's working on, but I'm not making a traditional RPG, I'm making a tactical RPG (didn't seem relevant enough to mention above). So I don't know how much use cooperating would be.
Quote:
This is a good idea. FWIW, you might need a lua script compiler that runs on the GBA or DS.

Well, the compiler in the interpreter works on the GBA and the standalone compiler builds for GBA just fine. (Though, of course, without a command line, etc, I don't know if it actually works.) So the option is there. It'll probablly end up being a compile time option.
Quote:
Actually, I'm not sure it will. How heavy are your scripts going to be? For now I'd stick with lua out of the can, using float or double for the type of lua_Number and fuss about something more efficient later when and if the scripting engine becomes a problem. Admittedly, switching to some sort of integer should be relatively painless, but that wouldn't be my top priority.

I'm not entirely sure how much scripting I'll need, so I can't say if it'll be a problem or not. That said, it looks like Lua has some built in (compile time) options for other types, so I might play around with those. At the moment, I'm not very interested in changing the Lua sources more than I need to.
Karatorian wrote:
Fixed is possible, evidently in hours if you know what you are doing. My first attempt failed. I have a list of places the source needs to be changed, if you want it. I'd love to see a fixed point version of lua for embedded systems.

Well, at the moment, I'll stick with the stock version, but if I ever do decide to experiment with it, I'll be sure to ask you about it.

If a robust fixed implementation was done, I wonder how hard it would be to get it officially accepted upstream. Maintaing a fork is always a pain.
Quote:
Port the project to the DS and this problem is solved.

Well, I don't own a DS and am not planning on buying one anytime soon. (I know, I must be crazy, but hey.) Besides which, it looks like MicroLua for the DS is much farther along than me, so in that case, I'd probably be better off using their stuff.
Quote:
FWIW, I wrote a couple of lua modules to tag (RPG) messages. You can extend them with your own tags. If you want them PM me.

I'd be interested if for no other reason than that I don't know Lua very well. Personally, I'm a Pythonista, but the thought of porting that to anything scares me. (Have you seen the Python internals? It's solid code, but not exactly easily hackable.)

Of course, it would be interesting just to do it (after all, Torlus ported the Java VM to the GBA), but I can't see there being any resources left over to use for anything else.

#169738 - wallacoloo - Sat Aug 01, 2009 6:23 am

What a coincidence, I'm developing an interpreter right now too. I've finished the virtual keyboard, though it's got a few minor glitches that need fixing. Nothing major, just the way newline characters are handled.
It's for the GBA, meaning no touch screen.

You can see some screenshots and download the ROM from here:
http://smileyunlimited.com/source.php?p=GBA/vKeyboard
Make sure to read "notes.txt", and sorry for the bad UI :-(

I'm not sure if this is what you're looking for or not, but maybe it'll help.
It's written in C++, I can share the source code if you're interested.

Java VM on the GBA? Could you send me a link?

#169739 - dantheman - Sat Aug 01, 2009 6:51 am

wallacoloo wrote:
Java VM on the GBA? Could you send me a link?

http://torlus.com/index.php?2004/01/05/25-java4gba---a-java-virtual-machine-for-gba

This code was later ported to the DS (java4nds) and then modified to add MIDP support, turning it into a mobile phone java game emulator (PSTROS DS)

#169741 - Karatorian - Sat Aug 01, 2009 7:37 am

wallacoloo wrote:
What a coincidence, I'm developing an interpreter right now too. I've finished the virtual keyboard, though it's got a few minor glitches that need fixing.

Interpreter for what language? Something standard or your own? I'm kinda a programming language geek (even though there's only a few I really use), so I'd love to hear more about it either way.
Quote:
I'm not sure if this is what you're looking for or not, but maybe it'll help.

Well, mostly I intend to edit and compile the scripts on my build system and only execute them on the GBA. However, I mentioned the virtual keyboard thing as I figured some people would be more interested in using it interactively, so a port of the standard interpreter would be a nice addition.
Quote:
It's written in C++, I can share the source code if you're interested.

Well, I'm more of a C guy myself, but code's code, so I may be interesed. However, you should know that I intend to release this project under the MIT License (same as Lua itself), so don't offer to contribute if you're not comfortable with that. (It's a new style BSD license, which basically means: Do what you want, give us credit, and don't blame us if it breaks your toys. It's also been referred to (as a spoof on "copyright" and "copyleft") as a "copycenter" license, meaning "Take it down to the copy center and make some copies.")

#169742 - wallacoloo - Sat Aug 01, 2009 8:24 am

Yeah, it's a language of my own. The syntax is a cross between javascript and python. I haven't gotten very far on it yet. It can handle function calls with passing parameters. It can also parse math expressions. Very little support for math at this point. Integers only.

Anyways, I've uploaded the source code to that url I posted earlier (as source.zip). It's documented very poorly, sorry for that.

The function compileAndRun under the file "vKeyboard.c" is where you'll want to add whatever code will be interpreting the text.

I'm not familiar with many licenses. All I care is that I can still use this code in my own projects. By the sounds of it I can, so I'm fine with that license.