Fio:LuaBinder
From Fio
(→Construct An Object) |
|||
| (9 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | <font color=blue>''"Like a bridge over troubled water..."''</font> - Simon | + | <font color=blue>''"Like a bridge over troubled water..."''</font> - Simon and Garfunkel |
| + | |||
| + | <font color=red>still in ctoring</font> | ||
==Lua Binder== | ==Lua Binder== | ||
| + | Fio use [http://www.lua.org Lua] as scripting language to implement the game logic which include(in a broad sense): | ||
| + | * UI design and switching | ||
| + | * event handler | ||
| + | * combat scheduler | ||
| + | * npc behavior | ||
| + | |||
| + | All the logics/policies are build on the mechanisms carried out by c++ classes which will do the real work of rendering, timing, event dispatching etc. This separation is to make the game fully data driven - thru scripting the logic itself is taken as data which can be easily modified without the re-compile-link of the mechanism part(or the engine). | ||
| + | |||
| + | Lua has provided a bunch of [http://www.lua.org/manual/5.1/manual.html API]s for "the host program to communicate with Lua". To call function from lua into c++, we have to: | ||
| + | * extract the arguments from lua stack; | ||
| + | * check the argument/return value type; | ||
| + | * call c++ function; | ||
| + | * push the return value onto lua stack; | ||
| + | * take care the return value's lifetime. | ||
| + | |||
| + | thru Lua APIs. | ||
| + | |||
| + | As the number of classes needs to be embedded into lua increases, these routine work will be a burden to write and maintain for each function call. There're quite a few [http://lua-users.org/wiki/LuaAddons binders] out there to make the embedding easier. In Fio we implement a home brew binder - LuaUtil as a bridge between the c++ and lua world.(Not-Invented-Here Syndrome? no, it's just for better understanding of the scripting and faster compiling speed) | ||
===Quick Tour=== | ===Quick Tour=== | ||
| + | Thru the lua API, we can create a metatable and register our c++ class' member functions there. Then we associate that metatable with the according c++ object(lurk in lua as a userdata/lightuserdata). Later when trying to call one of the member function on an object in lua, the binder'll check the calling stack of lua to find the '''this''' object('''self''' in lua) and all arguments passed in, do some type checking then finally invoke the registered member function and push the returned value onto lua stack(if necessary). | ||
| + | |||
| + | The [http://www.lua.org/pil/28.3.html Object-Oriented Access] chapter of [http://www.lua.org/pil Programming in Lua] describes this process in detail. | ||
===The Lua Application Program Interface=== | ===The Lua Application Program Interface=== | ||
===Construct An Object=== | ===Construct An Object=== | ||
| - | * | + | C++ objects live in lua in two types of data: |
| - | *lightweight | + | *userdata |
| + | *lightweight userdata | ||
| + | |||
| + | Userdata can be garbage collected(gced) when it's no longer needed while lightweight userdata will not be collected. | ||
| + | |||
| + | *why userdata is not enough? | ||
===Method Invoking=== | ===Method Invoking=== | ||
Current revision as of 14:51, 23 September 2006
"Like a bridge over troubled water..." - Simon and Garfunkel
still in ctoring
Contents |
[edit] Lua Binder
Fio use Lua as scripting language to implement the game logic which include(in a broad sense):
- UI design and switching
- event handler
- combat scheduler
- npc behavior
All the logics/policies are build on the mechanisms carried out by c++ classes which will do the real work of rendering, timing, event dispatching etc. This separation is to make the game fully data driven - thru scripting the logic itself is taken as data which can be easily modified without the re-compile-link of the mechanism part(or the engine).
Lua has provided a bunch of APIs for "the host program to communicate with Lua". To call function from lua into c++, we have to:
- extract the arguments from lua stack;
- check the argument/return value type;
- call c++ function;
- push the return value onto lua stack;
- take care the return value's lifetime.
thru Lua APIs.
As the number of classes needs to be embedded into lua increases, these routine work will be a burden to write and maintain for each function call. There're quite a few binders out there to make the embedding easier. In Fio we implement a home brew binder - LuaUtil as a bridge between the c++ and lua world.(Not-Invented-Here Syndrome? no, it's just for better understanding of the scripting and faster compiling speed)
[edit] Quick Tour
Thru the lua API, we can create a metatable and register our c++ class' member functions there. Then we associate that metatable with the according c++ object(lurk in lua as a userdata/lightuserdata). Later when trying to call one of the member function on an object in lua, the binder'll check the calling stack of lua to find the this object(self in lua) and all arguments passed in, do some type checking then finally invoke the registered member function and push the returned value onto lua stack(if necessary).
The Object-Oriented Access chapter of Programming in Lua describes this process in detail.
[edit] The Lua Application Program Interface
[edit] Construct An Object
C++ objects live in lua in two types of data:
- userdata
- lightweight userdata
Userdata can be garbage collected(gced) when it's no longer needed while lightweight userdata will not be collected.
- why userdata is not enough?
[edit] Method Invoking
- method wrap
[edit] from lua into c++
- traits
- Overload
[edit] from c++ into lua
callback?
[edit] Type Checking
[edit] LSP
[edit] Destruct & Object Lifetime in the 2 Worlds
[edit] Misc
- const
- panic
- utility functions
