Just want to share my experience with using Lua for building applications. We have been using Lua fo building applications for quite some years now. THe binding is using tolua++ where we have exported most of osg, openal++, osgal, replicantbody, physics library etc...
We took the path of exporting all functionality, so that there is nearly a 1-1 match of programming in c++ and lua. You can if you want derive from classes and get c++ to call overridden methods written in lua and vice versa. Really time critical things is written in C++ and exported as one or more classes to lua. THis means that one can build whole applications more or less using a viewer, which loads the appropriate configuration scripts+luascripts+plugins (written in c++). This is really great for flexibility, fast prototyping, productivity really. The BIIIG drawback is the type flexibility of lua. You dont really know you are using the right types in a call until you get to that exact point in the code. This is rather tiresome, as you might write nodee, instead of node, where lua interpretes nodee as a NIL value (which is a NULL pointer really). I think there are plugins for checking this, but it has nevertheless been a timeconsumer in some projects. Other things are fear of new/delete, as tolua++ really uses that quite a lot for methods like: Vec3 Matrix::getTrans(); It allocates a new Vec3(), stores a reference to it and when the receiving variable goes out of scope, it is garbage collected (at some point in time). This required for some scheduling of garbage collection. When that was done, it worked quite well. So I guess this fulfills both 1&2 in the above list of use for Lua, both building functionality inside lua, and using C++ code exported into lua. Why choose:-) Just my 2 cents. /Anders On Dec 11, 2007 11:50 PM, James Halliday <[EMAIL PROTECTED]> wrote: > Jan Ciger wrote: > > Actually, I think that the focus should be on providing a meaningful API > > to export to these languages. That could even mean a wrapper in order to > > eliminate/minimize usage of pointers and some C++ functionality that is > > difficult to translate (templates?). Once you have that, the language > > bindings could be done very quickly for almost any language, even in an > > automated way (e.g. using SWIG or something similar). Ideally, the > > wrappers should be made automatically from the current code. > > I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a > project on a cave-type system combining python, vrjuggler, and osg. > osgswig supports python, ruby, java and lua, although I've only played > with the python features. I had tried to use osgPython and pyosg before, > but they only work with older versions of osg. > > Jan Ciger wrote: > >/ 1) Application is written in C/C++ and calls embedded scripts. This is/ > >/ fairly typical for game development - game is written in C/C++ and > e.g./ > >/ AI is scripted using a built-in scripting engine. Here Lua is great > (it/ > >/ was written for it), because it is fairly easy to maintain separation/ > >/ between different scripts (exception/error in one script does not > crash/ > >/ the whole thing). Furthermore, Lua is really tiny, with negligible/ > >/ overhead. Another contender is Javascript (e.g. VRML standard uses it/ > >/ for exactly this purpose). I wouldn't target this case, because it is/ > >/ very application-specific and there is little a generic scene graph/ > >/ binding could provide to it. > /// > >/ 2) Application is written in a high level language and calls into > C/C++/ > >/ code to run the performance critical stuff. I think that this is what/ > >/ you want ("... enable us to/ > >/ develop applications purely from scripting languages, so developers in/ > >/ this realm would just need the binaries to the OSG installed, and no/ > >/ need for C++ dev environment"). > > /The osgswig project seems to be primarily designed for scenario 2, > although in my application I've been using osgswig as in scenario 1 by > getting out a void pointer to the opaque values from the python api. I'm > not sure how possible this approach is with other languages though. > > > ~ James > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ________________________________________________________________ Anders Backman Email: [EMAIL PROTECTED] HPC2N/VRlab Phone: +46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
