views:

226

answers:

1

I'm fairly new to Lua, I've been working on trying to implement Lua scripting for logic in a Game Engine I'm putting together. I've had no trouble so far getting Lua up and running through the engine, and I'm able to call Lua functions from C and C functions from Lua.

The way the engine works now, each Object class contains a set of variables that the engine can quickly iterate over to draw or process for physics. While game objects all need to access and manipulate these variables in order for the Game Engine itself to see any changes, they are free to create their own variables, a Lua is exceedingly flexible about this so I don't forsee any issues.

Anyway, currently the Game Engine side of things are sitting in C land, and I really want them to stay there for performance reasons. So in an ideal world, when spawning a new game object, I'd need to be able to give Lua read/write access to this standard set of variables as part of the Lua object's base class, which its game logic could then proceed to run wild with.

So far, I'm keeping two separate tables of objects in place-- Lua spawns a new game object which adds itself to a numerically indexed global table of objects, and then proceeds to call a C++ function, which creates a new GameObject class and registers the Lua index (an int) with the class. So far so good, C++ functions can now see the Lua object and easily perform operations or call functions in Lua land using dostring.

What I need to do now is take the C++ variables, part of the GameObject class, and expose them to Lua, and this is where google is failing me. I've encountered a very nice method here which details the process using tags, but I've read that this method is deprecated in favor of metatables.

What is the ideal way to accomplish this? Is it worth the hassle of learning how to pass class definitions around using libBind or some equivalent method, or is there a simple way I can just register each variable (once, at spawn time) with the global lua object? What's the "current" best way to do this, as of Lua 5.1.4?

+3  A: 

One approach is to use

  • a lightuserdata pointing to the C++ variable
  • a C function to access the C++ variable using the lightuserdata
  • keep the lightuserdata as an upvalue of the C function so one function suffices for all variables
  • use the number of arguments to the function to select between getting and setting the variable

For example:

int game_state_var_accessor (lua_State *L)
{
    int *p = lua_topointer(L, lua_upvalueindex(1));
    if (lua_gettop(L) == 0)
    {   // stack empty, so get
        lua_pushinteger(L, *p);
        return 1;
    }
    else
    {   // arg provided, so set
        *p = lua_tointeger(L,1);
        return 0;
    }
}

When you make a new game state you can create accessors for each variable using:

lua_pushlightuserdata(L, (int *)p); // where p points to your variable
lua_pushcclosure(L, game_state_var_accessor, 1);

The accessor is now on the stack and can be bound to a global name, or to the name of a method in a Lua class. If your Lua class table is on the stack at index t this would be:

lua_setfield(L, t, "name_of_accessor");
Doug Currie
Question: You cast the pointer, p, to (int *), but lua_pushlightuserdata accepts (void *) in the documentation. Is there any benefit, other than code readability, to casting it in this way? I figure I would need to create separate wrapper functions for different types of variables anyway, it just seems a bit odd.
Nicholas Flynt
The cast is only there to highlight the correspondence with the return type of game_state_var_accessor; in other words, for readability. If you are making wrappers for other types, you might rename it game_state_int_accessor for sanity.
Doug Currie
This solutions works beautifully. Thank you so much! And yes, I ended up using different binder functions, since each needed a different handler function to go with.I'm still learning here, but Lua's communications API is *pure genius* and I'm liking it a lot. ^_^
Nicholas Flynt
Ah. That's much cleaner than my solution. I'm not really used to using closures so I never thought of using them.
Tom Savage