Comments on: Selecting a scripting engine – Part 3.

By: susheel

susheel — Tue, 06 May 2008 06:05:32 +0000

@Marius
Squirrel is a good embeddable language and it will do a great job at exporting simple classes and functions. I am still experimenting it, quite a bit actually, and most of the times it does get the job done. However I am not so sure if embedding it in a full production project with large amount of classes having a lot of interdependencies is all that trivial. I can give you an example, our engine heavily depends on classes, class factories and interfaces/abstract classes. Relationships between existing classes must be preserved and carried over from the engine to anything that has to be built on top (eg. a game). By design the engine structure is abstracted to such a degree that any future game development via the engine will involve inheritance/aggregation/composition across the embeddable language and C++. It’s not to say that Squirrel can’t achieve that. I know it can, it’s just that there is a lot of hard work involved and at the end of the day it’s code; code that has to be maintained by someone. When I talk of Py++ and GCC-XML I am talking about offloading some of the work that a programmer would otherwise do to an automatic program, or at least a partially automatic one that will probably require only a fraction of effort needed to embed squirrel. To be fair though I have found Squirrel to be better and more intuitive than Python and I stand by my statement that had something like Py++ existed for Squirrel, it would have been my choice hands down!

By: Marius

Marius — Mon, 05 May 2008 21:28:43 +0000

I am a fun of Squirrel:. Contrary, I found Squirrel: easy to embed using SQPlus than any other, it might be ‘couse I spent some time on it.
Embedding goes something like;
/C++ code:/—————————————-
#include “sqplus.h”
#pragma comment(lib, “sqstdlib.lib”)
#pragma comment(lib, “squirrel.lib”)
#pragma comment(lib, “sqplus.lib”)

class Test
{
public:
void CalledFromScript(const char* s,long k){
print (s);
}
};

void main()
{
SQClassDef(“Test”).func(&Test::CalledFromScript,”
CalledFromScript”);
SquirrelVM::Init();
SquirrelObject test = SquirrelVM::CompileScript(_SC(“test.sq”));
SquirrelVM::RunScript(test);
SquirrelFunction ScriptFunction(“ScriptFunction”);
Test theT;
ScriptFunction(&theT, “pass_back”);
SquirrelVM::Shutdown();
}
/test.sq SQ code:/—————————————-
function ScriptFunction(t, str)
{
t.CalledFromScript(str, 100);
}

By: susheel

susheel — Wed, 21 Nov 2007 08:43:38 +0000

Working with Makefiles can be a nightmare. I used to work with them when I was in Geometric working on a cross-platform Qt related project, so I pretty much cringe when anyone mentions Makefiles. We worked with Visual Studio and had to be extra careful so as not the break the build. The project also had some Java and Python bindings done via SWIG, but I don’t exactly know how it was handled in the build script. The client had kept that information confidential. Too bad .

The engine and the game is currently being built on Windows platform using the express edition of Visual C++ and, no I don’t have a build system as yet. For now it’s click and build . I am however confident that the system can be ported across platforms without a lot of effort. I was thinking of SCons (http://www.scons.org/) for the job, but I haven’t used it as yet. MPC seems to be an interesting concept, hadn’t seen it before.

The idea of having a tool to generate bindings that can integrate with a build system seems almost too good to be true. I am not saying it’s not possible but I am a bit skeptical. Mind you I haven’t done enough research on Py++.

By: Sandeep K

Sandeep K — Wed, 21 Nov 2007 07:46:37 +0000

It wasn’t for bindings. I was experimenting with automatically injecting source code for function logging, easier debugging etc for an embedded systems project.

You should probably generate the python bindings as part of your build process – re-generate them every time the related files are modified.

For your game how do you maintain the build scripts for different platforms? Do they use the same tool chain? When using different tool chains one commonly violates the DRY principle. I came across http://www.ociweb.com/products/mpc which can generate build files for various tool chains, but haven’t been able to spend any time on it.

By: susheel

susheel — Tue, 20 Nov 2007 15:07:14 +0000

Was it for bindings or was the project something different? Py++ does depend on pygccxml.

I used the GCC-XML installer they have with the Py++ project downloads. It’s a little bit unconventional install script I agree but the main thing is you will have to do this once. Then maybe use a build script to just generate python bindings on a nightly build or something like that. Beats writing binding code every time, not to mention the bugs that may be introduced by the programmer.

I am not sure if it would as easy as that, but I kinda hope it will be. Need to do some more research on that.

By: Sandeep K

Sandeep K — Tue, 20 Nov 2007 06:34:09 +0000

I’ve used pygccxml for parsing c++ code, it was a lot of fun to use though installing GCC-XML was a bit painful.

Looking forward to the next in the series.