Game Development Reference
In-Depth Information
m_self
table. This keeps the
constructionData
parameter sent to the
Create-
FromScript()
function acting like the constructor of the
Create()
function on
Lua classes generated with the
class()
function. Consistency is important to ensure
that the calling code never has to care whether this is a C++ or Lua object.
The overridden virtual methods from
Process
call the functions found by
BuildCppDataFromScript()
. They all behave essentially the same way. They
check to see if the appropriate Lua variable was defined and call the function if it
was. Here
'
s the
OnInit()
function as an example:
void ScriptProcess::VOnInit(void)
{
Process::VOnInit();
if (!m_scriptInitFunction.IsNil())
{
LuaPlus::LuaFunction<void> func(m_scriptInitFunction);
func(m_self);
}
}
OnSuccess()
,
OnFail()
, and
OnAbort()
behave the same way. The only function
that behaves a bit differently is
OnUpdate()
.
void ScriptProcess::VOnUpdate(unsigned long deltaMs)
{
m_time += deltaMs;
if (m_time >= m_frequency)
{
LuaPlus::LuaFunction<void> func(m_scriptUpdateFunction);
func(m_self, m_time);
m_time = 0;
}
}
This function updates the
m_time
variable with the current delta and doesn
tcallthe
Lua
OnUpdate()
function until the appropriate amount of time has passed. As I said
earlier, this is important to keep from constantly crossing over the C++ / Lua boundary
if it
'
s not necessary. Of course, if no frequency was provided, the Lua
OnUpdate()
function will happily call every frame. This isn
'
s just an extra perfor-
mance cost that may or may not be necessary, depending on the process.
That
'
t a huge deal, it
'
s everything you need to define a process in Lua, but what about the Process
Manager? We still need a way to attach processes to the Process Manager. Instead
of trying to expose the
ProcessManager
class, the best thing to do in this case to
write a global wrapper function and export it through the
ScriptExports
interface
'
