 |
lua-l archive |
|
|
||
|
On 21/10/2011 7.23, Miles Bader wrote:
Thus, for operations which don't really need to be that fast, individual calls from Lua into the core are fine, but for operations where massive amounts of data need to be operated on, "bulk" interfaces avoid the overhead of a large number of calls into the core.
One possible approach to minimize cross-language calls with plain Lua, which I adopted in 2D games, would be to divide responsibilities between a C++ renderer/interpreter and high-level Lua logic.
I kept rendering data on C++ side and gameplay data on Lua side; basically, a Lua function was called (or resumed) at each frame and did a brief amount of game logic (e.g. handle an event, start an animation, etc.), sending requests back to C++ through a streamlined API set. The requests (e.g. animate this image with such and such parameter) were then served on the C++ side. On a given frame, there were only a handful of cross-language calls; I didn't even bother to optimize them. Long Lua operations were suspended and put into a resume queue handled by a C++ dispatcher. (it could also multitask on Lua side using coroutines, but I then limited it to one task per frame to reduce maximum frame time usage)
So the engine ran in C++, but the game scripters only saw Lua (which allowed them to run their code almost immediately). It worked beautifully in a resource-limited handheld system (with a Lua budget of about 1 ms and 1 MB RAM, game data included).
Of course there are many other possible approaches; system constraints and costs should be carefully weighted in the design phase.
-- Enrico