More LuaJIT MadnessPosted: February 16, 2012
I first joined the dark side when I picked up Lua in favor of the more traditional ‘C’ based languages. Learning new languages is always a slog, and this has been no exception. But, the concept count is fairly low, and the process from code to run is extremely short, so it’s not very hard to try things out.
My environment of choice right now is SciTE. As Integrated Development Environts (IDEs) go, this is not much more than a nice editor with syntax highlighting. It has some debug capability, but honestly, I haven’t even tried it as yet. My favorite “Print” debugger works the same as it has for the past 25 years, so I’ll stick with it until absolutely necessary.
Lua does satisfy many of the constraints I’ve given myself in terms of platform availability, succinct code, flexibility, and the like. Of particular value is the ability to run on really small devices like microcontrollers, cell phones, TVs, and whatnot.
Although I’ve been satisfied to date, speed is also a concern. Previously, I made a note about using LuaJIT, and that is the path that I am traveling down as well. It’s like throwing off training wheels. At the same time that I go down the LuaJIT path, I am contemplating my dependency chain. The various libraries that I use. I currently use iup (for basic UI) and IM (for imaging). I also use LuaSocket for collaboration. The challenge with iup is that it’s not easily on all platforms. Works great for Linux and Windows, not so much for Mac. I’ve also reconsidered my need to use IM. I don’t need to be able to read every type of image file that exists in the world. I’m just going to pick a few.
So, I’m changing things up. I’ve switched to using glfw as my core UI library. GLFW is the most bare minimum UI framework glue you could hope for. It combines being able to get a handle on a window with being able to get a GL context. Add in simple mouse/keyboard/joystick events, and you’re done. It does not try to solve all programming challenges like larger frameworks. So, this is very good. It works on Windows, Mac SO X, and many Unix-like systems using X Windows. Well, that’s a good start. Perhaps I can add the Android and iOS portions if they’re not already there, and call it a day.
This is great. Now that I’m using LuaJIT, and I’m takinig up GLFW, I get full access to the entirety of the OpenGL/ES API. I found a nice ready made set of FFI based interop stubs in this project UFO. Dimiter “malkia” stanve has done a great job of going down the path of providing interop to many different libraries, and across multiple platforms, including iOS and Android. That’s nice. Now I can truly write once, and run anywhere. That’s the benefit of the Lua talking.
One of the challenges I was facing when using the more pure lua (not LuaJIT) was the interop story. It’s extremely hard to write those perfect interop layers. As such, I was dreading having to write the fully expanded OpenGL API so that I could do some shader programning. Now, with LuaJIT and UFO, I have ready access to all the nice shader functionality. That’s really cool.
Now to try things out. LuaJIT is supposed to be fairly fast. So, I’m going to test that speed by doing some simple compressed target tests. That’s an easy task because Targa (.tga files) files use a simple run-length encoding scheme. So, let’s see, take a snapshot, compress, send over the net, decompress. Yep, that aught to about do it.