4 ms·
That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C o
by silentbicycle 17y ago
That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C or C++, write or generate a simple Lua wrapper for its API, and then the do logic in Lua, moving hotspots to C as necessary. (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers http://c2.com/cgi/wiki?AlternateHardAndSoftLayers, as they say.) As a bonus, the cross-language boundaries are often natural seams for containing complexity.
TCL was also designed with this style of programming in mind, and John Ousterhout describes it pretty well (http://www.vanderburg.org/OldPages/Tcl/war/0009.html http://www.vanderburg.org/OldPages/Tcl/war/0009.html).
FWIW, LuaJIT is only available for i386 at the moment, though amd64 porting is in progress. Standard Lua is still pretty fast, and it's great for prototyping. It's a good idea to get algorithms and overall design right before spending much time on low-level tuning.