[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: 2. Re: Interrupting lua execution
- From: "Chris" <jlsfjs@...>
- Date: Tue, 12 Nov 2002 12:35:31 +0100
Yes, I thought about this but it's an extra work needed because instead of
having lua call C++ code directly it involve building a push in pull out
mechanism that will translate the pull out datas in C++ method calls.
Other problem : when several events have been posted in the stack, it's
really hard to throw them later because they are becomed out of context (no
more usefull). At the oppositve, running code real time mean really adaptive
code that rely on a known game-world-context and action running with the
same principles. With events, time slicing is hard to handle because it mean
that we must have a way to associate a condition to an event (is that event
allways valid ? is that event allways valid as his ? If not what must be
done to adapt the event of the new world context ?).
These last points were my main headache and seems to far unnatural (at least
----- Original Message -----
Sent: Tuesday, November 12, 2002 12:16 PM
Subject: [lua-l] Digest Number 906
Date: Mon, 11 Nov 2002 13:40:59 +0100
From: Björn De Meyer <email@example.com>
Subject: Re: Interrupting lua execution
My "Classic non-threaded non-coroutine" solution for
the problem would be to use an "event pump",
much as is used in many different single-threaded GUI toolkits.
In essence, all input and all AI does not manipulate the
state of the program's objects directly. In stead, the
AI and input are translated to events that are stored on an
event list, and later processed in a controlled way in
the main loop of the program. You'll need to make sure then
that your lua scripts do not modify the objects directly but
only create events in your eventlist.
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com