cocos2d LUA bindings sentiment---like CC. SPRITE,CC. Director, how are these identified?

In fact, since I opened the Gamescene.lua file, one of the things I've been trying to figure out is cc.sprite how these are identified. In fact, the first reaction must be: it must be a global variable, or how to call the Create method. I just want to know when this global variable is registered, how does the C + + class method of cocos bind to Lua?

Knowing a bit of LUA knowledge knows that the global variables in LUA will be saved to a global table _g, and the question is converted to when to register with _g? When using CC. Before the sprite was create, I didn't seem to have defined CC in LUA. A variable such as a sprite, so it is not possible to be the global variable defined by LUA, but rather cocos is registered when the LUA engine is initialized.

Let's take a look at what the LUA engine did when it was initialized. Sure enough, I found the trail of _g.

Lual_register (_state, "_g", global_functions);

This is the registration of global functions into LUA. (The key is that at this point the top of the stack is the global table!!!) This is important).

Let's keep looking and we'll see a variety of registrations:

REGISTER_ALL_COCOS2DX (_state);    Register_all_cocos2dx_extension (_state);    Register_cocos2dx_extension_ccbproxy (_state);    Tolua_opengl_open (_state);    REGISTER_ALL_COCOS2DX_UI (_state);    Register_all_cocos2dx_studio (_state);    Register_all_cocos2dx_manual (_state);    Register_all_cocos2dx_module_manual (_state);    Register_all_cocos2dx_extension_manual (_state);    Register_all_cocos2dx_coco_studio_manual (_state);    Register_all_cocos2dx_ui_manual (_state);    Register_all_cocos2dx_spine (_state);    Register_all_cocos2dx_spine_manual (_state);    Register_glnode_manual (_state);

After each registration is completed, the site will be restored, that is, keep the top of the stack is the _g table. Let's choose one to analyze it, take register_all_cocos2dx as an example.

Tolua_api int register_all_cocos2dx (lua_state* tolua_s) {tolua_open (tolua_s); Tolua_module (Tolua_S, "CC", 0); Tolua_ Beginmodule (tolua_s, "CC"); Lua_register_cocos2dx_ref (tolua_s); Lua_register_cocos2dx_console (Tolua_S); Omit a lot of code ...}

There seems to be a little bit of a hint here. CC and our CC. The sprite is very close.

Basic function Description:

Tolua_module: Try to register a module named name, each module is registered with the parent module, but CC does not have a parent module, so it will assume that _g is the place where it should register.

Tolua_api void Tolua_module (lua_state* L, const char* name, int hasvar) {if (name) {/* Tolua module */        Lua_pushstring (L,name); Lua_rawget (l,-2);//Whether the name is registered in the current module table if (!lua_istable (l,-1))/* Check if module already exists */{//No note            Book over, new one lua_pop (l,1);            Lua_newtable (L);            Lua_pushstring (L,name); Lua_pushvalue (l,-2);/* The following test indicates that the module is added to (global table) if (lua_istable (l,-4)) {<span style= "White-space:pre" ></span >lua_getfield (l,-4, "print"), <span style= "White-space:pre" ></span>if (Lua_isnil (L,-1)) {<span Style= "White-space:pre" ></span>char a= ' a '; <span style= "White-space:pre" ></span>}else{<  Span style= "White-space:pre" ></span>char b = ' B '; Come here la La la!!! <span style= "White-space:pre" ></span>}<span style= "White-space:pre" ></span>lua_pop (L,1);     <span style= "White-space:pre" ></span>}*///register to the current module table to Lua_rawset (l,-4);  /* assing module into module */}}} 

From the above test code can be found is to register the _g table. So our guess is exactly right. Why is the _g table? It has been previously indicated (when registering a global function, the _g is placed on top of the stack).

There is now a key-value pair in the global table: _gtable["CC"]=cc_table.

Then you can see how the sprite is registered. In the REGISTER_ALL_COCOS2DX register function, we find that:

Lua_register_cocos2dx_sprite (tolua_s);

int Lua_register_cocos2dx_sprite (lua_state* tolua_s) {    tolua_usertype (tolua_s, "CC. Sprite ");    Tolua_cclass (tolua_s, "Sprite", "CC.") Sprite "," CC. Node ", nullptr);    Tolua_beginmodule (tolua_s, "Sprite");    Tolua_function (tolua_s, "Setspriteframe", lua_cocos2dx_sprite_setspriteframe); A lot of code is omitted here ...}

Basic function Description:

Tolua_usertype: Registers the user type with the registry to create a table of that type. (table and type are bidirectional mappings in the registry).

Tolua_cclass: Set this class of metatable Ah, parent class, Tolua_super table registration, Tolua_ubox table registration,. and add the "Sprite" key to the current parent Template table.

Then, you register some functions with the table.

We know that the current parent Template table is cc_table, and the current Template table is: sprite_table. cc_table["Sprite"] = sprite_table. sprite_table["setspriteframe"] = lua_cocos2dx_sprite_setspriteframe.

Now you can access the sprite through the global table, and you can access the method inside.

So I think CC. Sprite.setspriteframe (...) The execution process is: to the _g table to get cc corresponding to the cc_table, and then see if there is a sprite in cc_table, if there is in sprite_table to find Setspriteframe method.

These are purely personal views. I am also in the study, welcome and exchange together.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

cocos2d LUA bindings sentiment---like CC. SPRITE,CC. Director, how are these identified?