I took another stab at using SWIG for the bindings and I have a working branch that provides about 90% of the OF api now. I have function, class, enum renaming working so this approach doesn’t require all of the tons of boilerplate I wrote for Luabind to rename things, plus overloading is handled for you.

It’s on the swig branch: https://github.com/danomatika/ofxLua/tree/swig

Pluses of SWIG compared to Luabind:

  • easily distributable generated .cpp bindings
  • no BOOST C++ lib requirement so building ofxLua is painless
  • no templating craziness (aka Xcode slowness, etc)
  • no requirement for a separate Xcode project for Luabind
  • more maintainable as SWIG handles function overloading and renaming
  • Luabind development not completely coordinated (aka not sure who’s work to use since the main dev haven’t worked with it for a few years now)
  • SWIG allows for generating Python, Javascript, etc bindings as well as Lua

Minuses of SWIG compared to Luabind:

  • can’t inherit C++ classes in Lua
  • no Lua “class” instance provided by Luabind (I add a “class” object with Lua code that works the same way)
  • need to install SWIG if you want to add your own custom bindings
  • making custom bindings needs to be done separately, not at build time
  • have to run SWIG to generate custom bindings as a separate step

Overall, I see the pluses of SWIG being worth it. This branch is fully working and tested on OS X and iOS. It should work pretty easily on Win and Linux now that Boost isn’t required.

After a few months of use, I’ve decided to merge the swig branch with master. The older Luabind version of ofxLua is now in the ‘luabind’ branch. I don’t plan to keep developing the luabind code but I could spin it off into a new Haddon, maybe “ofxLuabind” if anyone want’s to take it on.

how does ofxLua deal with ofFbo

on trying it does hit a slight wall. since when you end an fbo with say ‘fbo.end()’ it would run into problems with lua, since end ends functions
what would the walk around be?

did try fbo:end() but again it still leads to the end problem


They’ve been renamed for that exact reason. Check your of table printout.

It’s beginFbo() / endFbo() for ofFbo, beginShader() / endShader() for ofShader, & beginCamera() / endCamera() for ofCamera.

It’s in the language DIFF prints from the SWIG interface file, but I’ll add these notes to the ofxLua readme.

cool spot. thanks dude. i did try to find them, but obviously overlooked them

thanks again

You didn’t overlook them, I didn’t make them easy to find. I should have added that specific info to the readme. Giving me feedback helps me fix things like this :smiley:

1 Like

Ok, relevant info now in the readme: https://github.com/danomatika/ofxLua#basic-documentation

awesome, thanks man

just to ask.
how could you store your lua files within the application that has been built. i have tried just doing some simple building etc, but if i say move the built app to somewhere else then run, it does not show the lua code. i get why, but how can this be embeded into so it will run no matter where it is placed


For an OSX .app bundle, you can add the data folder as a folder reference (not a group) when you drag and drop it into Xcode. When the app is built, Xcode will copy the contents into the Resources folder inside the app automatically without you having to add every new file. Then you need to redirect the ofDataPath to use the resources folder:

// read from the app bundle
    ofLogVerbose() << "Data path is \"" << ofToDataPath("")  << "\"";

I generally call this pretty early in my ofApp setup function. The #ifdef block is to make sure this only happens on OSX.

Hey there! Great addon.
I wonder if there’s any way to relatively quickly hook up some functions to make them available from the Lua script? I mean some sort of per-project binding. Is it possible?

ofxLua is now updated for the OF 0.9.0 api & lua 5.3.2

Note: deprecated functions are not included in the bindings, so you may have to update some scripts ie. things like ofImage::width are no longer available, use ofImage::getWidth() instead. See https://github.com/danomatika/swig-openframeworks/blob/master/interfaces/deprecated.i for the list of deprecations, as marked in the 0.9.0 api.

@lewislepton I noticed ofxFileWatcher the other day. Could be used to watch lua scripts and reload whenever they are saved to match love2d …

1 Like

Thanks for the work, i’m looking for this type of binding long time ago for add levels to a game project.

Just a question about your experience; my “game” is an app that generate visuals in real time (60fps), sometimes just some squares, sometimes a list of 3D objects textured. Currently i only use .ccp classes compiled to switch between “levels”, without performances problems (but i cannot add new contents without recompiled).

In theory, i can use Lua files for my level graphics part, send some variables and get the render, but what do you think about performances ? In your opinion, there is a big performance difference between compiled classes or embed interpreted files ?

Thanks in advance for you help/vision

@taktik I think the performance will be fine. lua is a small and very fast scripting language so, in my usage, I’ve stayed at 60 fps using Lua scripts for pretty much everything. Also, keep in mind you can keep parts of your rendering in C++ and make a custom lua wrapper for it using SWIG so you can call it from lua, this way the most intensive parts of your project can stay in C++.

But I’d also just suggest trying it out. Take the luaExample and modify one of the scripts to do one of your scenes, etc. I think you’ll see it’s still pretty fast. If not, then you can replace lua with luajit which is an order of magnitude faster.

Thanks danomatika, my first test a really surprising, Lua is really what i need.

In fact, i was just looking for additionnal content package system, load at app start, but the possibility of easy edit and reload script (without relaunch the app) open me lot of possibility. Thanks again for your addon :smile:

@danomatika Do you think it’s possible to tie up some C++ function to some Lua command at runtime? Maybe with std::function or with function pointer.

I don’t think so since the wrapper files are generated by SWIG before you build the app. This might have been possible when ofxLua used Luabind but Luabind is a beast with indeterminate development at this point.

If you need to wrap your own custom code, see https://github.com/danomatika/ofxLua#making-your-own-bindings

My long term solution is to look into a way to build dynamic loading so you could build your own modules separately and just load them after runtime.

Actually, if you use Luajit instead of the base Lua included with ofxLua, you can use the Foreign Function Interface: http://luajit.org/ext_ffi_tutorial.html

Note: FFI works with C functions, so it will be trickier to use with C++ due to class & namespace mangling.