Embedding LUA/Multithread

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

Embedding LUA/Multithread

David Diaz
First of all thanx a lot to Sebby and Luiz Henrique for the
help and guidelines provided.

I've been trying a LUA 3.1 version with multithread support
that I found at LUA's main page as non official resource.
The fact is that it hangs when doing a simple 'repeat' loop
with a concatenation and a 'print' inside:

function test()
  local i

  i = 1
  repeat
    print("I'm iteration #"..i)
    i=i+1
  until i>100
end

It will never work, am I wrong ? Is this version functional ?

I've been taking a look to messages that talk about co-routines
but I still don't understand what they are. I've seen some
examples but I don't understand them. It seemed like routines
call themselves in such a recursive way but I need multithred
to be transparent to the script designers.

Last question... by now ;)  Is there any way to download ALL
list messages in a single file or something like that so that
I can read them offline ?


Reply | Threaded
Open this post in threaded view
|

Re: Embedding LUA/Multithread

Adolf Mathias
David Diaz wrote:

> 
> I've been taking a look to messages that talk about co-routines
> but I still don't understand what they are. I've seen some
> examples but I don't understand them. It seemed like routines
> call themselves in such a recursive way but I need multithred
> to be transparent to the script designers.

I assume that script designers write scripts that direct the behavior of
game characters. But doesn't multithreading make the issue of
communication between the actors much more difficult than necessary?
Also, who guarantees you that each character handler thread gets invoked
once per video frame? I would suggest the following approach: each
character has (at least) an update and a draw routine, e.g.
(please forgive the militaristic example)

function update_enemy(self, dt)
  -- simulate hostility

  self.xpos = dt*self.xspeed
  self.xpos = dt*self.yspeed

  self.firing_counter = self.firing_counter+1
  if self.firing and self.firing_counter>=self.firing_rate then
    create_missile(self.xpos, self.ypos, self.firing_xdir,
self.firing_ydir)
    self.firing_counter = self.firing_counter-self.firing_rate
  end
end

function draw_enemy(self)
  ...
end

function update_missile(self, dt) ... end

function draw_missile(self) ... end

function check_collisions(living_enemies, active_missiles)

function main_update
  local dt = 0.02

  -- deal with input...
  
  for i, v in living_enemies do update_enemy(v, dt) end
  for i, v in active_missiles do update_missile(v, dt) end
  check_collisions(living_enemies, active_missiles)
  for i, v in living_enemies do draw_enemy(v, dt) end
  for i, v in active_missiles do draw_missile(v, dt) end
end

With update_enemy I've tried to point out the programming style your
character scripters would have to adopt, which in my eyes is
significantly less complex than the multithreaded variety. They would
have to deal with some sort of synchronization among each other and the
redraw cycle (mutexes or semaphores)

Please forgive if I haven't got the right idea about how your style of
game -- but the real-time games that come into my mind would fit into
the above structure. Just replace enemy and missile with whatever entity
you have in the game, be it monsters, a pacman, asteroids, hideous quake
creatures, racing cars, skiers...

Dolfi

-- 
Adolf Mathias              EMail: dolfi at zkm dot de  Web: www.zkm.de
|||| / |< ||| ZKM Institute for Visual Media - Institut für Bildmedien
P.B. 6919 D-76049 Karlsruhe, Germany; fon +49 721-8100-1544, fax -1509

Reply | Threaded
Open this post in threaded view
|

Re: Embedding LUA/Multithread

John Belmonte-2
Hi,

As Dolfi kept his example simple there isn't much state in the characters (firing and
firing_counter in enemy).  But in a real game there is a lot of state and complicated timing.
Implementation and interaction of state machines is what I've always found frustrating about
program design as opposed to hardware design, where everything is running in parallel.

I haven't had experience with coroutines yet, but they promise to be a nice way to implement
state machines and complicating timings without resorting to real threads.

Looking forward to giving them a try in Lua...

-John


----- Original Message -----
From: "Adolf Mathias" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, January 15, 2001 6:47 PM
Subject: Re: Embedding LUA/Multithread


> I assume that script designers write scripts that direct the behavior of
> game characters. But doesn't multithreading make the issue of
> communication between the actors much more difficult than necessary?
> Also, who guarantees you that each character handler thread gets invoked
> once per video frame? I would suggest the following approach: each
> character has (at least) an update and a draw routine, e.g.
> (please forgive the militaristic example)
>
> ...



Reply | Threaded
Open this post in threaded view
|

Re: Embedding LUA/Multithread

Luiz Henrique de Figueiredo
In reply to this post by David Diaz
>Last question... by now ;)  Is there any way to download ALL
>list messages in a single file or something like that so that
>I can read them offline ?

See the file "lua-l-archive.gz" at our ftp site and its mirrors.
It contains *all* lua-l messages since it started.

The file "lua-l-recent" contains only messages posted in 2001.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Embedding LUA/Multithread

Adolf Mathias
In reply to this post by John Belmonte-2
John Belmonte wrote:
> 
> Hi,
> 
> As Dolfi kept his example simple there isn't much state in the characters (firing and
> firing_counter in enemy).  But in a real game there is a lot of state and complicated timing.
> Implementation and interaction of state machines is what I've always found frustrating about
> program design as opposed to hardware design, where everything is running in parallel.

Yeah, state machines: That's where my approach really kicks in:

State transitions are triggered by events or by logic decisions inside
"state code". State code is either executed when a state gets activated
(Moore automaton), or when a transition occurs (Mealy automaton). Mealy
automata are simpler for a given task, but the most practical are hybrid
automata where code is executed in all of the above occasions. In Lua,
state machines are a breeze, because you have anonymous functions and
beautiful table facilities:

my_fsm =
{ currentstate = "start",
  start  = { action = function ... end, mouseclick =  },
  state2 = { action = function ... end, crash = { cond = function() ...
end, action = function() ... end, to = "final" } }
  -- But one might as well use add_transition to add transitions; a
little 
  state3 = { }
  ...
  final = { action = shutdown } -- hypothetic shutdown function
}

function my_fsm:add_transition(from, _to, event, _cond, _action)
  -- state existence and multiplicity check omitted!!!
  self[from][event] = { action = _action, cond = _cond, to = _to }
end

-- just a sample: look up a transition with label event; do the
transition, but only when its condition 
-- is satisfied; execute state and transition actions
function my_fsm:send_event(event)
  local state = self[self.currentstate]
  local trans = state[event]

  if state==nil then print("FSM has no state " .. self.currentstate)

  -- decide yourself what arguments you pass to cond() and action()
  if trans==nil then 
    print("No transition for event " .. event)
  elseif trans.cond==nil or trans.cond( ) then
    if trans.action~=nil then trans.action( ) end
    self.currentstate = trans.to
    state = self[self.currentstate]
    if state.action~=nil then state.action( ) end
  end  
end

my_fsm:send_event("mouseclick")
my_fsm:send_event("crash")

OK, now you mix this stuff with the stuff I sent before, and there goes
your game engine, without coroutines and multithreading ;) (I know, I
know, it's not that simple...)

Dolfi