YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

Squirrel (SqPlus) vs. LuaPlus in practice
John Schultz
#1 Posted : Monday, September 05, 2005 9:15:11 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/24/2005(UTC)
Posts: 241

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
I've moved all of my scripting for my game engine over to Squirrel from LuaPlus (currently very simple bindings):



LuaPlus:



    LPCD::Register_GlobalPropertySetFunction(state->GetGlobals(),"var1",&var1);

    LPCD::Register_GlobalPropertySetFunction(state->GetGlobals(),"var2",&var2);



    globalsObj.Register("func1",&func1);

    globalsObj.RegisterDirect("func2",*classPtr,&ClassType::memberFunc2);

    globalsObj.RegisterDirect("func3",*classPtr,&ClassType::memberFunc3);

    globalsObj.RegisterDirect("func4",*classPtr,&ClassType::memberFunc4);

    globalsObj.RegisterDirect("func5",*classPtr,&ClassType::memberFunc5);

    globalsObj.RegisterDirect("func6",*classPtr,&ClassType::memberFunc6);

    globalsObj.RegisterDirect("func7",*classPtr,&ClassType::memberFunc7);



LuaPlus creates all the necessary hooks/callback so that Lua script can access vars & call functions via the names in quotes. No other code is required: it's very fast/easy to bind objects (type checking is also automatically performed).



Squirrel (with SqPlus):



    bindVariable(root,var1,"var1");

    bindVariable(root,var2,"var2");



    SquirrelVM::CreateFunctionGlobal("func1",func1Stub,"t");

    SquirrelVM::CreateFunctionGlobal("func2",func2Stub,"s");

    SquirrelVM::CreateFunctionGlobal("func3",func3Stub,"si");

    SquirrelVM::CreateFunctionGlobal("func4",func4Stub,"ssbf");

    SquirrelVM::CreateFunctionGlobal("func5",func5Stub,"sssf");

    SquirrelVM::CreateFunctionGlobal("func6",func6Stub,"ssiff");

    SquirrelVM::CreateFunctionGlobal("func7",func7Stub);



In Squirrel (using sqPlus), the intial setup is about the same. Stub functions must be used along with type strings (no compiler/template auto-code generation).

However, the stub functions add ~50 more lines of code for this example case. Thus the initial ~10 lines of LuaPlus code becomes ~60 lines of Squirrel/SqPlus code (~6x more code).

Fortunately, my project does not currently require a great deal of script I/O (motion/behavior is mostly physics based). For a project using more complicated scripting, some form of lightweight

template/macro scripting layer would be extremely useful (could reduce script interface code ~6x). LuaPlus's Callback Dispatcher could probably be ported fairly quickly by someone with expert experience in Lua/Squirrel/template-metaprogramming.



After this integration (and low level Squirrel/VM/SqPlus coding), I really appreciate the Squirrel language design and syntax (preferred over Lua script): great job Alberto!



John
fagiano
#2 Posted : Wednesday, September 07, 2005 6:36:16 AM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 827

Thanks: 0 times
Was thanked: 36 time(s) in 29 post(s)
Thanks :).


I have to look into LuaPlus method dispatcher(I'm not sure what it is). About additional code added by proxy methods I peronally think is not a big deal. In a real situation in any case you don't want(I don't) to map you C++ interface 1:1 to the script one. There are some functions that just forward parameters but the majority of them(in my case) do a certain amount of validation or accept different signatures or even belog to different objects(most of the time the Subsystem::CreateThing becomes a constructor in script Thing()).


For instance my Vector3 contructor accept 3 floats or another vector or an array with 3 floats or a table xyz or rgb. My function SpawnEntity accepts a class name or a class id and optionally a table with default values.


So having some magic template that wraps everything isn't really that useful, probably just drives to bad practice. Mapping C++ 1:1 on script kind of defeats the pourpose of scripting.


This is just my personal opinion.


ciao


Alberto


 

John Schultz
#3 Posted : Wednesday, September 07, 2005 7:51:35 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/24/2005(UTC)
Posts: 241

Thanks: 0 times
Was thanked: 0 time(s) in 0 post(s)
I find that both methods are useful (arbitrary args with type checking and auto-type-checked 1:1 mapping)...



In LuaPlus, check out:



LuaPlusCD.h (especially the simple/elegant type matching method)

LuaObject.h (very similar to SquirrelObject), function registration functions (saves a great deal of typing, reduces possiblity of (C/C++ side) runtime errors (compile time error checking).

Perhaps see the remote debugger implementation.



Probably many other good ideas for inspiration (lightweight templates, clean code).



Be sure to get 1084 build from Joshua's SVN repo (you may have to email him to start the server).



Some doc info for LuaPlus:



[link]http://wwhiz.com/LuaPlus/LuaPlusCallDispatcher.html[/link]



Quote:


This all sounds heavyweight.  Amazingly enough, the Visual C++ 7 compiler, in an optimized build, optimizes it by completely removing step 3 (described above) from the equation.  Further, step 4 is translated into a simple assembly jmp instruction.


All said, the use of the functor techniques is slightly more expensive than a simple C function pointer, both in performance and memory.  The final cost, though, is probably not of consequence, since the straight C function being called will more than likely do an operation that is heavier weight than the function call.  The end result will likely not show up in a profiler (and if it does, you are doing a whole lot of Lua->C function calls).






It's pretty cool...



John


Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.140 seconds.