report on the Lua in the Gaming Industry Roundtable at GDC 2004

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

report on the Lua in the Gaming Industry Roundtable at GDC 2004

Luiz Henrique de Figueiredo
The moderators have kindly shared with us their report. So here it is.
--lhf

            GDC 2004 - Lua in the Gaming Industry Roundtable Report

Moderators

   Jon Burns [1]
   David Eichorn [2]

   Microsoft Game Studios

Abstract

   The embedded programming language Lua is becoming more and more widely
   used  in  the  gaming  industry. The beauty of this language is in its
   simplicity  and  flexibility;  several  games  within  Microsoft  Game
   Studios employ the use of Lua for many aspects of their architectures,
   including  scripting,  game  balancing,  AI  decision  making, driving
   animations,  UI  layout,  and  level  building.  The  purpose  of this
   roundtable  discussion  is  to  bring  developers  from  the  industry
   together to share in their experiences integrating Lua into their game
   projects.  The goal is to spread awareness of the most popular uses of
   Lua  and  to also make any short-comings or pitfalls apparent to those
   developers evaluating the use of Lua in their games.

Session Format

   The  roundtable  was  broken into two sessions. Not knowing the actual
   experience  level of the participants, the discussion topics were wide
   open; anything related to Lua was fair game.

Attendance

   The  first  session  had approximately sixty attendants, primarily all
   developers.   The   second   session   had  approximately  forty  five
   attendants,  again,  primarily  all  developers. The first session had
   many  more active participants, approximately fifteen, as more of this
   group had some good experience working with Lua on their projects. The
   second   group   was   less   experienced;  only  approximately  seven
   participated  actively.  Some attended to share their experience while
   others  simply wanted to learn more about Lua's impact in the industry
   or evaluate it for possible use.

Key Discussion Points

  Lua 4.0 vs. Lua 5.0

   Users  of  both  stated  that  they  have  observed  as  high as a 20%
   performance  improvement when moving to Lua 5.0. It was concluded that
   it  would behoove any teams using older versions of Lua to switch over
   to Lua 5.0, the latest release version.

  Lua vs. Python

   The  comparison  of Lua and Python was a major theme of both sessions.
   The  general  consensus  here  is  that  Lua is much faster, uses less
   memory,  has  a smaller footprint, and is easier to get up and running
   and  hooked  into  a  game  than Python. Python, however, is much more
   scalable  than  Lua.  Python has a good set of modules for specialized
   tasks  which  makes  it  a  good  language  to  use for cross-platform
   development, while in Lua you'd have to write much of it yourself.

   Many  developers  use  both  languages for different purposes - Lua is
   most  often  used for small-scale while Python is used for large-scale
   tasks  (such  as tool development efforts). Lua is often used for game
   scripting,  Python  for  tools. One developer even said he had written
   his Lua debugger in Python!

  Lua vs. XML

   A  question  was posed regarding using Lua or XML for data definition.
   The  general  consensus was that Lua is much more compact and readable
   than  XML.  XML  is  good  for  describing  small  sets  of  data  and
   web-related  data, and it was suggested that a team could use XML as a
   meta-language  to express game data in binary, which would be good for
   cross-platform  development.  Most  agreed  it  is much easier to find
   XML-savvy editors than Lua editors.

  Lua's easy ramp-up time

   Most  developers  heavily  experienced with Lua said Lua is a language
   that developers can learn in about 10 minutes and that non-programmers
   can  pick  up  at  a fairly quick pace. Certain scripting applications
   using  Lua  could be a good way for junior programmers to get into the
   business.

   There  is  good  documentation  for  Lua,  which  aids  in the ramp-up
   process. There is now a Lua Programming book, reference manuals, and a
   good community support web site [3] [4].

  Non-programmers using Lua

   There  was  general  agreement  that  non-programmers - game and level
   designers, perhaps artists - can learn to understand the syntax of the
   language and write small bits of code with excellent results, but that
   learning  how to actually program in Lua is a challenge. The risk here
   is  the higher chance of subtle bugs being introduced into Lua scripts
   from these non-technical people.

   For  example,  some  devs  had problems with their artists not knowing
   good  naming  conventions and programming concepts well enough to do a
   good job in Lua. One suggestion was to use a tool named Ultraedit that
   color-codes  the Lua script - this developer claimed his artists found
   programming in Lua much easier in this editing program.

   It was also suggested that data-driven design support in Lua is better
   for  these  non-technical  people.  One developer suggested creating a
   multi-tiered system that added increasing levels of abstraction - each
   level  increasing  the  ease of use for the non-technical people using
   Lua. He claimed it has worked very effectively in his project.

  Binding Lua to C++

   Many less-experienced Lua users asked about binding Lua with C++. Some
   developers   are   using  the  Luabind  tool  which  does  this  quite
   effectively,  though  some  cautioned  that the compile times are much
   longer.  One  mentioned that the tool ToLua is no longer supported, so
   use  of  it  should  be  transitioned  to  another  automatic  binding
   generation tool. Other tools mentioned included LuaPlus and Swig. Some
   developers  found  it easier to write their own in-house tools to bind
   Lua and C++ because it is quite easy to do.

   The  discussion  produced  this word of caution: the easier it gets to
   bind  Lua to data objects in the game source, the easier it is to fall
   into the trap of binding *everything* to Lua, which is dangerous...

  Issues encountered when using Lua in game development

   The attendees had many suggestions on avoiding pitfalls:

   Avoid  using  Lua  in  "every  frame"  actions  as  performance  drops
   dramatically.  For example, don't use Lua to do animation updates; set
   up  parameters  for  the  animation in Lua and do the updates in C/C++
   code.

   Avoid  using  Lua  for large game development tasks; rather use Lua in
   quick small-scale actions.

   Avoid  using extremely large table sizes as performance drops in table
   access actions.

   Store  state information outside of Lua in C++ objects, only bind when
   necessary.

   Be  careful about what data is bound to Lua. Having careful control of
   this  data can result in a good, stable environment regarding security
   measures.

   Call garbage-collection routines explicitly only when free cycles come
   up.  Some  devs  found  that  Lua  was  doing  garbage  collection  at
   inopportune times.

   One  developer  cautioned against using incremental garbage collection
   as he observed noticeable slowdown. Because it is a new functionality,
   however, this claim wasn't discussed much.

  Good things about Lua

   The  attendees  had  the  following  to say about what appeals to them
   about using Lua:

   Lua  coroutines work "reasonably well" for cooperative multithreading.
   One  developer  said  they have about twice the overhead of a function
   call (negligible), and that having 3-4 works just fine.

   All of the developers love the fact that licensing Lua is so easy, and
   especially so free.

   In  event-based  and  polling  systems, many of the developers claimed
   they observe no noticeable bottlenecks caused by Lua.

   New  features/tools  coming into the Lua scene make it more attractive
   day by day: Lualint and the new standard debugging library provided in
   Lua 5.0.

   All devs unanimously agreed that the support for Lua is great, whether
   off of the Lua homepage or the community sites, etc.

  Experiences applying Lua

   The  group  shared  some  of  their own personal uses of Lua that were
   particularly memorable and successful:

   One  developer  created  a  cutscene  handler  in Lua that managed the
   triggering  of  cutscenes  in  his  game  project. He found it easy to
   manage in Lua.

   One  developer  was  able to setup a record / replay system for all UI
   actions.

   One developer was doing unit code testing in Lua.

   One  developer  was  able  to  derive  game objects in Lua, and assign
   functions  to  these  objects  in order to test their attributes, etc.
   more easily.

   One  developer  integrated Lua with their physics engine to allow more
   accessibility to tweak physics scripts dynamically.

Summary and Conclusions

   This  roundtable  focused  on the hands-on experiences of people using
   Lua  in  the gaming industry. Attendees were encouraged to share their
   personal  experiences  with  Lua  in  order to spread awareness of the
   benefits  and  pitfalls  of  this  embedded language. The two sessions
   accomplished  this goal quite successfully (we as moderators were very
   surprised  at  the interest in Lua in the gaming industry based on the
   number of attendees both days and in the discussion that came about) -
   there  was good conversation in both roundtable sessions that conveyed
   several  things,  most  notably:  1)  The diverse uses of Lua that are
   specific  to  games  development,  2) What not to use Lua for in games
   development,  3)  The  ease  of  ramp up time for users of Lua, and 4)
   Comparisons  against  other  languages and even older releases of Lua.
   This is where most interest lay for both days.

   There  are  definitely  a handful of very experienced Lua users in the
   gaming  industry  that  are  doing  some very impressive work in their
   projects with the language. Future roundtables on this topic can begin
   to  explore more of what the industry would like to see as features of
   the   language   itself  and  how  the  community  support  for  games
   development can expand more effectively...

References

   1. [hidden email] AT microsoft.com
   2. [hidden email] AT microsoft.com
   3. http://www.lua.org/
   4. http://lua-users.org/wiki/

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Ando Sonenblick
Excellent information within... thanks much for reporting on this.

A question:

In the suggestions for avoiding pitfalls, you mention: " Avoid using extremely large table sizes as performance drops in table access actions."

Can you tell use what you consider "extremely large"?

I have several core tables in my environment that hold all the api calls to my internal engine and am wondering if I'm knocking on the door of a serious slow down?

thx,
ando


On Apr 15, 2004, at 12:19 PM, Luiz Henrique de Figueiredo wrote:

The moderators have kindly shared with us their report. So here it is.
--lhf

            GDC 2004 - Lua in the Gaming Industry Roundtable Report

Moderators

   Jon Burns [1]
   David Eichorn [2]

   Microsoft Game Studios

Abstract

The embedded programming language Lua is becoming more and more widely used in the gaming industry. The beauty of this language is in its simplicity and flexibility; several games within Microsoft Game Studios employ the use of Lua for many aspects of their architectures, including scripting, game balancing, AI decision making, driving animations, UI layout, and level building. The purpose of this roundtable discussion is to bring developers from the industry together to share in their experiences integrating Lua into their game projects. The goal is to spread awareness of the most popular uses of Lua and to also make any short-comings or pitfalls apparent to those
   developers evaluating the use of Lua in their games.

Session Format

The roundtable was broken into two sessions. Not knowing the actual experience level of the participants, the discussion topics were wide
   open; anything related to Lua was fair game.

Attendance

The first session had approximately sixty attendants, primarily all developers. The second session had approximately forty five attendants, again, primarily all developers. The first session had many more active participants, approximately fifteen, as more of this group had some good experience working with Lua on their projects. The second group was less experienced; only approximately seven participated actively. Some attended to share their experience while others simply wanted to learn more about Lua's impact in the industry
   or evaluate it for possible use.

Key Discussion Points

  Lua 4.0 vs. Lua 5.0

Users of both stated that they have observed as high as a 20% performance improvement when moving to Lua 5.0. It was concluded that it would behoove any teams using older versions of Lua to switch over
   to Lua 5.0, the latest release version.

  Lua vs. Python

The comparison of Lua and Python was a major theme of both sessions. The general consensus here is that Lua is much faster, uses less memory, has a smaller footprint, and is easier to get up and running and hooked into a game than Python. Python, however, is much more scalable than Lua. Python has a good set of modules for specialized tasks which makes it a good language to use for cross-platform
   development, while in Lua you'd have to write much of it yourself.

Many developers use both languages for different purposes - Lua is most often used for small-scale while Python is used for large-scale tasks (such as tool development efforts). Lua is often used for game scripting, Python for tools. One developer even said he had written
   his Lua debugger in Python!

  Lua vs. XML

A question was posed regarding using Lua or XML for data definition. The general consensus was that Lua is much more compact and readable than XML. XML is good for describing small sets of data and web-related data, and it was suggested that a team could use XML as a meta-language to express game data in binary, which would be good for cross-platform development. Most agreed it is much easier to find
   XML-savvy editors than Lua editors.

  Lua's easy ramp-up time

Most developers heavily experienced with Lua said Lua is a language that developers can learn in about 10 minutes and that non-programmers can pick up at a fairly quick pace. Certain scripting applications using Lua could be a good way for junior programmers to get into the
   business.

There is good documentation for Lua, which aids in the ramp-up process. There is now a Lua Programming book, reference manuals, and a
   good community support web site [3] [4].

  Non-programmers using Lua

There was general agreement that non-programmers - game and level designers, perhaps artists - can learn to understand the syntax of the language and write small bits of code with excellent results, but that learning how to actually program in Lua is a challenge. The risk here is the higher chance of subtle bugs being introduced into Lua scripts
   from these non-technical people.

For example, some devs had problems with their artists not knowing good naming conventions and programming concepts well enough to do a good job in Lua. One suggestion was to use a tool named Ultraedit that color-codes the Lua script - this developer claimed his artists found
   programming in Lua much easier in this editing program.

It was also suggested that data-driven design support in Lua is better for these non-technical people. One developer suggested creating a multi-tiered system that added increasing levels of abstraction - each level increasing the ease of use for the non-technical people using
   Lua. He claimed it has worked very effectively in his project.

  Binding Lua to C++

Many less-experienced Lua users asked about binding Lua with C++. Some developers are using the Luabind tool which does this quite effectively, though some cautioned that the compile times are much longer. One mentioned that the tool ToLua is no longer supported, so use of it should be transitioned to another automatic binding generation tool. Other tools mentioned included LuaPlus and Swig. Some developers found it easier to write their own in-house tools to bind
   Lua and C++ because it is quite easy to do.

The discussion produced this word of caution: the easier it gets to bind Lua to data objects in the game source, the easier it is to fall
   into the trap of binding *everything* to Lua, which is dangerous...

  Issues encountered when using Lua in game development

   The attendees had many suggestions on avoiding pitfalls:

Avoid using Lua in "every frame" actions as performance drops dramatically. For example, don't use Lua to do animation updates; set up parameters for the animation in Lua and do the updates in C/C++
   code.

Avoid using Lua for large game development tasks; rather use Lua in
   quick small-scale actions.

Avoid using extremely large table sizes as performance drops in table
   access actions.

Store state information outside of Lua in C++ objects, only bind when
   necessary.

Be careful about what data is bound to Lua. Having careful control of this data can result in a good, stable environment regarding security
   measures.

Call garbage-collection routines explicitly only when free cycles come up. Some devs found that Lua was doing garbage collection at
   inopportune times.

One developer cautioned against using incremental garbage collection as he observed noticeable slowdown. Because it is a new functionality,
   however, this claim wasn't discussed much.

  Good things about Lua

The attendees had the following to say about what appeals to them
   about using Lua:

Lua coroutines work "reasonably well" for cooperative multithreading. One developer said they have about twice the overhead of a function
   call (negligible), and that having 3-4 works just fine.

All of the developers love the fact that licensing Lua is so easy, and
   especially so free.

In event-based and polling systems, many of the developers claimed
   they observe no noticeable bottlenecks caused by Lua.

New features/tools coming into the Lua scene make it more attractive day by day: Lualint and the new standard debugging library provided in
   Lua 5.0.

All devs unanimously agreed that the support for Lua is great, whether
   off of the Lua homepage or the community sites, etc.

  Experiences applying Lua

The group shared some of their own personal uses of Lua that were
   particularly memorable and successful:

One developer created a cutscene handler in Lua that managed the triggering of cutscenes in his game project. He found it easy to
   manage in Lua.

One developer was able to setup a record / replay system for all UI
   actions.

   One developer was doing unit code testing in Lua.

One developer was able to derive game objects in Lua, and assign functions to these objects in order to test their attributes, etc.
   more easily.

One developer integrated Lua with their physics engine to allow more
   accessibility to tweak physics scripts dynamically.

Summary and Conclusions

This roundtable focused on the hands-on experiences of people using Lua in the gaming industry. Attendees were encouraged to share their personal experiences with Lua in order to spread awareness of the benefits and pitfalls of this embedded language. The two sessions accomplished this goal quite successfully (we as moderators were very surprised at the interest in Lua in the gaming industry based on the number of attendees both days and in the discussion that came about) - there was good conversation in both roundtable sessions that conveyed several things, most notably: 1) The diverse uses of Lua that are specific to games development, 2) What not to use Lua for in games development, 3) The ease of ramp up time for users of Lua, and 4) Comparisons against other languages and even older releases of Lua.
   This is where most interest lay for both days.

There are definitely a handful of very experienced Lua users in the gaming industry that are doing some very impressive work in their projects with the language. Future roundtables on this topic can begin to explore more of what the industry would like to see as features of the language itself and how the community support for games
   development can expand more effectively...

References

   1. [hidden email] AT microsoft.com
   2. [hidden email] AT microsoft.com
   3. http://www.lua.org/
   4. http://lua-users.org/wiki/


-----------------------
Ando Sonenblick
SpriTec Software
www.spritec.com


Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>A question:
>
>In the suggestions for avoiding pitfalls, you mention: " Avoid  using 
>extremely large table sizes as performance drops in table access 
>actions."
>
>Can you tell use what you consider "extremely large"?

I wondered about this as well. I suppose they mean "enormous"...

Anyway, such questions should be addressed directly to the moderators of
the roundtable:
	jkburns AT microsoft.com
	deichorn AT microsoft.com

I don't think they're in lua-l...

Perhaps someone in the list did go to the roundtable and can comment?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Adam D. Moss
In reply to this post by Luiz Henrique de Figueiredo

   Avoid  using  Lua  in  "every  frame"  actions  as  performance  drops
   dramatically.  For example, don't use Lua to do animation updates; set
   up  parameters  for  the  animation in Lua and do the updates in C/C++
   code.

Yes!!  I wish I'd had someone warn me six months ago.  :)  I'm
still not sure why Lua seems to perform very respectably for
reactive tasks and even a lot of general-purpose crunching but
REALLY starts to drag when doing even a few rather simple
tasks /every/ frame.  Perhaps the setup of invoking Lua from C
is fairly heavy (I suspect not) or it's a more subtle issue
such as Lua thrashing the memory caches.

I love and use Lua, but I'm in the middle of some rearchitecting
at the moment because I discovered the above truism the hard
way pretty late. :)

--Adam
--
Adam D. Moss   . ,,^^   [hidden email]   http://www.foxbox.org/   co:3

Reply | Threaded
Open this post in threaded view
|

RE: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Jasmin Patry
In reply to this post by Luiz Henrique de Figueiredo
We do a fair amount of per-frame Lua processing, and have found significant speedups by grouping together as much Lua processing together as possible.  For example, on of our systems uses "Lua conditions" (boolean-valued functions) to determine if the system should change state.  Instead of calling each condition chunk separately from C++, we found it much faster to call one big Lua function that calls the condition functions (and returns the index of the first one to return true).  For one state with about 40 Lua conditions, this gave us roughly a 10x speedup.

My *guess* is that the one-big-Lua-function approach has much fewer cache misses, and that this is largely responsible for this performance improvement.  I should also note that this was on the PS2, where cache misses hurt dearly.

Jasmin


-----Original Message-----
From: Adam D. Moss [[hidden email]]
Sent: Thursday, April 15, 2004 12:56 PM
To: Lua list
Subject: Re: report on the Lua in the Gaming Industry Roundtable at GDC
2004



>    Avoid  using  Lua  in  "every  frame"  actions  as  performance  drops
>    dramatically.  For example, don't use Lua to do animation updates; set
>    up  parameters  for  the  animation in Lua and do the updates in C/C++
>    code.

Yes!!  I wish I'd had someone warn me six months ago.  :)  I'm
still not sure why Lua seems to perform very respectably for
reactive tasks and even a lot of general-purpose crunching but
REALLY starts to drag when doing even a few rather simple
tasks /every/ frame.  Perhaps the setup of invoking Lua from C
is fairly heavy (I suspect not) or it's a more subtle issue
such as Lua thrashing the memory caches.

I love and use Lua, but I'm in the middle of some rearchitecting
at the moment because I discovered the above truism the hard
way pretty late. :)

--Adam
-- 
Adam D. Moss   . ,,^^   [hidden email]   http://www.foxbox.org/   co:3

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Ashwin Hirschi-2

My *guess* is that the one-big-Lua-function approach has much fewer cache misses, and that this is largely responsible for this performance improvement.  I should also note that this was on the PS2, where cache misses hurt dearly.

I think another reason might be that a Lua-C/C++-Lua transition is relatively expensive. So reducing the number of Lua calls to a C++/C engine, like your calling everything in one go approach, will be cheaper. Though I'm not sure exactly how big the savings are in real-world examples...

Ashwin.
--
no signature is a signature

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Dario Accornero
On 16 Apr 2004, at 1:12, Ashwin Hirschi wrote:

I think another reason might be that a Lua-C/C++-Lua transition is relatively expensive. So reducing the number of Lua calls to a C++/C engine, like your calling everything in one go approach, will be cheaper. Though I'm not sure exactly how big the savings are in real-world examples...

I have a gdb window open right now, and here's what I see:

0. my C++ code				[breakpoint here]
1. Lunar<myclass>::thunk
2. luaD_precall
3. luaV_execute
4. luaD_call
5. f_call
6. luaD_rawrunprotected
7. luaD_pcall
8. lua_pcall
9. Lunar<myclass>::call

The Lunar calls represent the price I pay for using this particular interface, and I'm fine with that. On the other hand, the seven stack frames required in any case to reach my own code look quite expensive indeed. Obviously I'm not claiming that I could make it in any way faster -- I'm just saying that I completely understand the need for grouping multiple Lua invocations in a single one, and I'll try to implement said mechanism.

Dario


Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Edgar Toernig
Dario Accornero wrote:
>
> On 16 Apr 2004, at 1:12, Ashwin Hirschi wrote:
> 
> > I think another reason might be that a Lua-C/C++-Lua transition is 
> > relatively expensive. So reducing the number of Lua calls to a C++/C 
> > engine, like your calling everything in one go approach, will be 
> > cheaper. Though I'm not sure exactly how big the savings are in 
> > real-world examples...
> 
> I have a gdb window open right now, and here's what I see:
> 
> 0. my C++ code				[breakpoint here]
> 1. Lunar<myclass>::thunk
> 2. luaD_precall
> 3. luaV_execute
> 4. luaD_call
> 5. f_call
> 6. luaD_rawrunprotected
> 7. luaD_pcall
> 8. lua_pcall
> 9. Lunar<myclass>::call
> 
> The Lunar calls represent the price I pay for using this particular 
> interface, and I'm fine with that.  On the other hand, the seven stack 
> frames required in any case to reach my own code look quite expensive 
> indeed.

The C<->Lua transition is normally cheap.  Not very different from a
function call within Lua.  But what *could* be expensive is lua_pcall.
The problem with lua_pcall is that it uses setjmp/longjmp which
performs a system call on some systems (those which preserve signal
masks).  You could either try _setjmp/_longjmp instead or use lua_call
and catch errors elsewhere (may become difficult with C++).
Additionally, lua_call instead of lua_pcall would remove stack frames
5, 6, and 7 from the above trace.

Ciao, ET.

PS: The cache miss argument mentioned earlier is not to be discarded
lightly.  On current systems, a cache miss may cost from several 100
to some 1000 clock cycles.  The ratio between CPU speed and memory
bandwidth has become that big that nowadays execution speed is no
longer dominated by the number of instructions required to perform
a specific task.

Reply | Threaded
Open this post in threaded view
|

lua_yield and coroutine.yield

Dmitriy Iassenev
Hello,

is it correct to use coroutine.yield(...) inside LUA to yield a lua thread
which is started from C? Or have I to implement C closure which
returns lua_yield(...) as described in manual? Is there any difference?

-- 
Best regards,
 Dmitriy                            [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Mark Hamburg-4
In reply to this post by Edgar Toernig
on 4/16/04 6:22 AM, Edgar Toernig at [hidden email] wrote:

> The C<->Lua transition is normally cheap.  Not very different from a
> function call within Lua.  But what *could* be expensive is lua_pcall.
> The problem with lua_pcall is that it uses setjmp/longjmp which
> performs a system call on some systems (those which preserve signal
> masks).  You could either try _setjmp/_longjmp instead or use lua_call
> and catch errors elsewhere (may become difficult with C++).
> Additionally, lua_call instead of lua_pcall would remove stack frames
> 5, 6, and 7 from the above trace.

You could also revise luaD_rawrunprotected and luaD_throw to use C++
exceptions. (Covered previously on this list.) Then Lunar wouldn't need to
use pcall to catch any errors since they would be reported just like other
C++ errors.

Mark

P.S. lua_lock and lua_unlock for multithreaded execution become a noticeable
issue in Lua/C and C/Lua transitions.


Reply | Threaded
Open this post in threaded view
|

failing yield and stack

Dmitriy Iassenev
In reply to this post by Dmitriy Iassenev
Hello,

1. Why LUA doesn't failed immediately when yield is called not from the
LUA thread?!

2. Is there any way to find out count of the items in the LUA stack?
Or I just have to iterate on stack until nil value is found?

-- 
Best regards,
 Dmitriy                            [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: failing yield and stack

Ashwin Hirschi-2

2. Is there any way to find out count of the items in the LUA stack?
Or I just have to iterate on stack until nil value is found?

Try lua_gettop(), described in:

	http://www.lua.org/manual/5.0/manual.html#3.2

And remember that nil is a valid function parameter value!

Ashwin.
--
no signature is a signature

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Dario Accornero
In reply to this post by Mark Hamburg-4
On 16 Apr 2004, at 17:15, Mark Hamburg wrote:

on 4/16/04 6:22 AM, Edgar Toernig at [hidden email] wrote:

The C<->Lua transition is normally cheap.  Not very different from a
function call within Lua.  But what *could* be expensive is lua_pcall.
The problem with lua_pcall is that it uses setjmp/longjmp which
performs a system call on some systems (those which preserve signal
masks).  You could either try _setjmp/_longjmp instead or use lua_call
and catch errors elsewhere (may become difficult with C++).
Additionally, lua_call instead of lua_pcall would remove stack frames
5, 6, and 7 from the above trace.

You could also revise luaD_rawrunprotected and luaD_throw to use C++
exceptions. (Covered previously on this list.) Then Lunar wouldn't need to use pcall to catch any errors since they would be reported just like other
C++ errors.

Mark

P.S. lua_lock and lua_unlock for multithreaded execution become a noticeable
issue in Lua/C and C/Lua transitions.

Thanks to both of you for your suggestions, which I'll both try out -- currently Lua is always run from a single thread in my application, so I leave lua_lock/unlock empty by default.

Ciao,
Dario



Reply | Threaded
Open this post in threaded view
|

Re: lua_yield and coroutine.yield

Roberto Ierusalimschy
In reply to this post by Dmitriy Iassenev
> is it correct to use coroutine.yield(...) inside LUA to yield a lua
> thread which is started from C? Or have I to implement C closure
> which returns lua_yield(...) as described in manual? Is there any
> difference?

No. coroutine.yield simply calls lua_yield.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: report on the Lua in the Gaming Industry Roundtable at GDC 2004

Robert Anderberg
In reply to this post by Adam D. Moss
On Thursday 15 April 2004 7:55 pm, Adam D. Moss wrote:
> >    Avoid  using  Lua  in  "every  frame"  actions  as  performance  drops
> >    dramatically.  For example, don't use Lua to do animation updates; set
> >    up  parameters  for  the  animation in Lua and do the updates in C/C++
> >    code.
>
> Yes!!  I wish I'd had someone warn me six months ago.  :)  I'm
> still not sure why Lua seems to perform very respectably for
> reactive tasks and even a lot of general-purpose crunching but
> REALLY starts to drag when doing even a few rather simple
> tasks /every/ frame.  Perhaps the setup of invoking Lua from C
> is fairly heavy (I suspect not) or it's a more subtle issue
> such as Lua thrashing the memory caches.

Our last game (http://www.lua.org/uses.html#113) was writtern using renderware 
as a base witht he whole game being writtern in Lua. All iteration and 
processing was done from a Lua main function.

We found that the garbage collector would cause the game to pause every so 
often, so we called it every frame, that slowed us down quite a bit. I think 
that was due to more to lazy coding rather than a problem with Lua itself.

While the games were quite simple, we literally did everything in Lua, 
including vector and maths calculations.

The target machine was a P3 400Mhz PC

Rob