[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Design mistakes in mixed C/C++ and Lua projects
- From: Enrico Colombini <erix@...>
- Date: Fri, 21 Oct 2011 09:33:15 +0200
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
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.