[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Attach Lua script To C++ class!
- From: "Matthew Harmon" <matt@...>
- Date: Thu, 21 Jul 2005 09:37:33 -0500
Glad to see you found the article in GPG5 helpful. I tried to boil it down
to it's essence, but in hindsight there are probably a few things that could
have been simplified even more.
If I can get clearance from the publisher, maybe I'll post the source code
on my website and add any basic features that people feel would be useful.
I'll also tighten up some terminology to clarify the sample code. (i.e. the
LUASCRIPT class would be better named LUASTATE, etc.)
I think a lot of people starting up with Lua encounter these issues right
away, and having some simple source to look at can be a big help to anyone
integrating Lua into a real-time app/game/simulation.
[mailto:firstname.lastname@example.org] On Behalf Of Richard Ranft
Sent: Wednesday, July 20, 2005 8:21 PM
To: Lua list
Subject: RE: Attach Lua script To C++ class!
Sounds pretty similar, though the LuaManager class in the example manages
the Lua state. It also spawns off child states off of the master state
instead of using threads. The Script class isn't part of a resource
management system, because it's a simple example, but it would lend itself
well enough to that. Here's a link to the source and project files (VC++ 7
I think, I had to update them to 7.1). And it's 1.10, not 1.13, in GPG5, in
case you get the chance to look into that.
Main downside is that it only supports one parameter for C++ functions
called from Lua. This is easy to fix with the samples in the C API section
from PiL. I have been trying to decide which class to include the Manager
in, but it finally occured to me that I should probably make it a global
object and have each class register its functions as they are created.
BTW - anyone know if you can make multiple calls to luaL_openlib()? From
what I can tell you should be able to add tables with different table names
as needed. Or will I need to do some trickery with metatables? Basically I
want each class to be able to register its public functions under an
appropriate table name ("Object", "Actor", "ParticleSys", that sort of
thing). According to the docs a new table is created with an unused table
name, or the table is overwritten if the name exists (re-used, I'm
interpreting as overwritten - or does it just replace the first entries in
the event that the new table is shorter than the old?).
[mailto:email@example.com]On Behalf Of Antoine
Sent: Wednesday, July 20, 2005 5:49 AM
To: Lua list
Subject: Re: Attach Lua script To C++ class!
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
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.