RE: Attach Lua script To C++ class!

["Ive" <neosettlers@...>]

Hey thx for your help!

I have to solve the issue of using either one global lua_state or having
one lua_sate per script!

What s the difference? Anyone can clear this up?

thx

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Antoine
Chavasse
Sent: Wednesday, July 20, 2005 8:49 AM
To: Lua list
Subject: Re: Attach Lua script To C++ class!

On 7/20/05, Richard Ranft <rranft@lvcablemodem.com> wrote:
>  
> Look into the example from Game Programming Gems 5 - 1.13 Building Lua
into
> Games.  The author uses a script manager class that can allow
registered
> scripts to yield, etc - basically, assuring all scripts get a chance
to
> process in turn without bogging down the main loop.  His example needs
some
> modification to make it really cool, but it's a good start. 
>   

I don't know how similar it is to what is mentioned in that book, but
I just integrated lua in a c++ engine where I work.

I have a Script class that wraps a lua script into as a resource,
managed by our resource management system, so that if the same script
is needed in different places, it will be loaded only once (and
automatically disposed of when no one has references to it anymore,
using a smart pointer system). I have a global lua_State, the
functions generated from the loaded scripts are stored in the registry
table (using the address of the corresponding Script instance to be
able to retrieve them easily), and removed from it when the
corresponding Script instance is deleted (so that lua can
garbage-collect the function associated with the script).

I then made a LuaThread class, that wraps a lua_State. You pass it a
Script when you sonctruct it, and it does a lua_newthread from the
global lua_State and pushes the script's lua function on the thread's
stack.

I have two lists for the threads, one for those that are waiting some
event, one for those that are running. Each frame, I iterate through
the running threads, and do a lua_resume on them.
They call a function at some point that implies waiting for some
event, which is implemented through a lua_yield that returns a
boolean, so that we know that the thread should be moved to the aiting
list (as opposed to destrying it).

I'll need a system to share some variables between the scripts later
on, but I guess it can be done using a special environment table
shared among the threads.