RE: multiple lua states

["Joel Pritchett" <jpritchett@...>]

Yes, it will be slower. But with the amounts we are using it we didn't
notice a speed hit. For us it wasn't much of a choice because of the
memory constraints of the project. Every bit helps, even if it was only
60k or so.

Even though we didn't notice a speed hit, if we find ourselves using the
same object repeatedly in a script we've instructed the scripters to
cache the value returned from 'Actor.GetNamed( ... )' in a local
variable just to make everything fast as possible. 

Joel

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Brett Bibby
Sent: Monday, November 03, 2003 3:19 PM
To: Lua list
Subject: Re: multiple lua states

Joel,
Thanks for the info!
> 'Actor.GetNamed( "WorldNode1", "Barrel1" )'
We do something like this for global variables now and we thought this
was slower.  Have you had any performance issues with using calls like
this?  If not, this is a pretty clean way to do what we want.
Brett

----- Original Message ----- 
From: "Joel Pritchett" <jpritchett@sammystudios.com>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Tuesday, November 04, 2003 1:55 AM
Subject: RE: multiple lua states


> We're using lua in our game and did the following:
>
> We have a single master lua state that stores all our common and
library
> functions as well as any constants in its global table.
>
> Each object runs a thread (lua_newthread) spun from this state. Each
> thread has a new global table and '__index' operator added to its
> metatable. In the new '__index' operator we first search the threads
new
> global table and if we cannot find what we are looking for we look for
> it in the master states global table. Also in each threads global
table
> we add a 'this' pointer and any other object specific data. All the
> explicitly named objects live in the global state table and when
> referred to are resolved properly.
>
> As for your solutions: I can't see any way to fix #1, not if you stick
> to name mangling.
>
> We found the adding of named objects extremely memory intensive, to
the
> order of 250 bytes per just for a pointer associated with a name. So
we
> pulled them out in favor of something like the following:
> 'Actor.GetNamed( "WorldNode1", "Barrel1" )' which fixed node (or
scene)
> specific naming collisions and an ass load of memory. We had several
> hundred objects per level being added though.
>
> If you want to keep the named objects I'd have to ask for more info
> about how you need to use a global polling script in relation to the
> local thread. I'm sure there is a good solution though using
metatables.
>
> Joel
>
> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Brett Bibby
> Sent: Friday, October 31, 2003 8:15 PM
> To: Lua List
> Subject: multiple lua states
>
> Hello,
> We're trying to decide whether to go with multiple lua states or a
> single
> state for our game.  Any advice appreciated.  Sorry for the length of
> the
> post but to give a good answer, understanding our usage is important.
>
> Our game editor allow you to define game objects using GUI property
> sheets
> which get compiled into lua tables (the level designer doesn't see or
> even
> know about the lua tables).  Our game editor does this by internally
> assigning an identifier that is a number such that it starts at
> hexidecimal
> "A".  On export, we generate the object tables using this number but
> converted to string, and starting with "A" makes sure we have a valid
> string
> beginning with A-F followed by a bunch of numbers.
>
> So now we have a bunch of lua tables holding the properties of a game
> object
> like health, hit points, whatever.  We then have an event system that
> basically creates a C object that holds the name of a handler script
for
> a
> given object.  When the event fires we call the lua script, converting
> the
> internal number back into a string and pass it to lua so the lua
script
> just
> sees it as a table access.  In other words, when a script gets called
it
> gets passed a variable which contains the numeric identifier, a "self"
> if
> you will.  In the script I can then do a function like:
>
> function UpdateLight(selfId)
>      LightColorSet(selfId, 255, 255, 255)
> end
>
> and the engine will look up the object back into it's scenegraph and
all
> is
> well.  We additionally need to sometimes refer to other objects
> explicitly,
> so in our tools when you create the game object there is a checkbox
that
> says "Scriptable" and a label name then becomes editable.  When this
> happens
> we then generate a lua variable and set it equal to the table name we
> also
> generated.  So an object labeled as "treasure" known as "B245"
> internally
> that is scriptable would then emit a lua variable below the table
> declaration like treasure = B245 so that any function requiring an
> identifier can use the variable instead.  Very nice system so far.
>
> The tricky part is that we can have multiple scenes running at the
same
> time
> and this leads to the problem.  So, if I have a tree swaying in the
> wind,
> known internally as A123, it has a table called A123.  If this tree
> appears
> in more than one scene though, I would have multiple tables with the
> same
> name which is no good.  The solutions are:
>
> 1.  Use a single, global lua state.  Prefix the id (e.g. A123) with a
> scene
> id so it becomes something like A1A123 where the first A1 is the scene
> concatenated with the object id.  I can then run the same script on
the
> "same" object that appears in multiple scenes and they each have their
> own
> private table.  The tree A123 in scene A1 is A1A123 and in scene A2 is
> A2A123 and a single script can work on all swaying trees no matter how
> many
> scenes it's in.  The problem with this is that then my label is
broken!
> I
> will have two tables, A1A123 and A2A123 but one label called "tree"
> which
> will be equal to the last uploaded one, either tree=A1A123 or
> tree=A2A123.
> So I lost explicit scriptability of objects.  Any ideas how I can
> resolve
> this?
>
> 2.  Use multiple lua states.  In this scheme I still prefix the object
> identifiers with a scene identifier, and everything works as before,
but
> now
> my label will also work because the variables of the same name are in
> different states so there is no namespace collision.  The problem with
> this
> approach is that I waste memory on functions that are essentially
> identical
> in each state and, more importantly, I don't know how to share data
> amoung
> scenes.  For instance how can Ihave global player health, score, etc.?
>
> I can't think of any solution to #1, but for the global variable
problem
> in
> #2 I could create a global scene, mark it as such, and include a
> variable
> auotmatically in all scenes with the global variable scene id,
something
> like global_scene=A0.  Then I would write a function to make an object
> id
> that concatenates the global scene id with an object id to make a
final
> correct id for the global scene.  Then my engine would need to call
into
> that global scene on behalf of the calling script so I change lua
states
>
> Am I missing something?  Is there an easy way to share _some_, but not
> all,
> variables amoung different lua states?  Any way to solve #1?
>
> Sorry for the long post!
> Brett
>