First of all I'd like to congratulate Andreas for this awesome scripting engine. Lack of support for object-based scripting and to a lesser extent, the need to write host-bridge functions in other engines is what has kept me from looking into embedded scripting. On to the main point (question) of this post: I have noticed that support for passing primitive types from the host to the scripting engine is only available for signed/unsigned longs, floats, and doubles. I am basically unable to use a script function like: int ScriptSum(int a, int b) { return a + b } from the host. I tried passing the parameters as signed longs but the library threw an error. I next tried registering "int" as an object type and used the setArgObject(..) and GetReturnObject() methods.. still no success. What do I need to do to turn (16-bit) integers, booleans and other native C++ types into passable entities between script and host?

First of all, thanks for the kind words about the library. I'm pleased to hear that you like it :D

AngelScript support all primitive types that C++ has (except 64bit integers), so your problem is likely just a misunderstanding (or possibly a bug in AS). The types in AngelScript are:

int8        = charuint8       = unsigned charint16       = short intuint16      = unsigned short intint/int32   = long intuint/uint32 = unsigned long intfloat       = floatdouble      = doublebool        = boolbits8       = unsigned charbits16      = unsigned short intbits/bits32 = unsigned long int

These last types, are special to AngelScript in that they allow bitwise operations. They also allow bitwise conversion between int and float, without the use of pointers as is needed in C/C++.

When passing primitives as parameters to script functions you should use the methods SetArgDWord(), SetArgFloat(), or SetArgDouble(). All primitives types that are not float or double should use SetArgDWord(). float and double should use SetArgFloat() and SetArgDouble() respectively.

Actually, no validation of the type of primitive is done for either of these, so you could use SetArgDWord() to pass float, and SetArgQWord() to pass double, however then you need to be careful to not accidentaly convert the float to int or __int64.

Let's say you have a script function:

bool ScriptFunc(int a, bool b, double c){   return ...;}

Then you should call it like so:

asIScriptContext *ctx;engine->CreateContext(&ctx);ctx->Prepare(engine->GetFunctionIDByDecl(0, "bool ScriptFunc(int,bool,double)"));ctx->SetArgDWord(0, intval);ctx->SetArgDWord(1, boolval);ctx->SetArgDouble(2, dblval);ctx->Execute();boolval = (bool)ctx->GetReturnDWord();

Of course, you need to add error verification.

Let me know if you need more help.

Regards,
Andreas

I had stopped short of finding the solution actually.. I was using the QWord version rather than Dword for int's.

Thanks for the help!

As for other types, I pretty much got hand of it.. figuring out which behaviours are operator-overloading specific and which where object specific took me a while :)

On a slightly different note: Are there any plans for having the script engine automatically support passing arrays of registered types between script and host, rather than having to register "type[]" style array types manually?

Keep up the good work! I am very much of the opinion that this is one of the best scripting engines I've ever seen. :)

Excellent.

Yes, I plan to expose an interface for the internal script array object so that applications can interact directly with those. However, since the internal script array object is not a template, but rather a generic implementation that checks types at run-time, it is definetely not as efficient as using std::vector for example.

Thanks for your moral support for AngelScript. It is really appreciated. :D

Regards,
Andreas

I don't think performance will be an issue in most cases; a non-templated container should still be reasonably fast. And in cases where performance really becomes an issue, registering a vector<type> for the type[] behaviour is still a possibility, am I correct? Speaking of templated containers, it's a pity that something like the container types STL cannot really be registered as types, as they can be quite handy.

On the subject of wish-lists, it would also be nice to see some pseudo multi-threading functionality, such as having functions for running a number of concurrent contexts for a given time-slice! I better stop here.. I'm letting enthusiasm getting the upper hand on me :)

Exactly, in most cases the performance of the built-in script array object will be sufficient, and where the application needs more performance it can register customized arrays objects.

Indeed, it would have been nice if the templated containers could have been registered as is, alas it is not possible. Also, for AngelScript the STL containers aren't 100% compatible as they don't have any reference counters.

You can already do semi-multithreading. There are two options, either you register a function that the scripts call to voluntarily suspend execution, or you register the LineCallback function and have it suspend the execution after a certain time period.

I have plans on making it easier to use though, by implementing something similar to Lua's co-routines.