Jump to content
  • Advertisement
Sign in to follow this  

Passing primitive types

This topic is 4948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post

Link to post
Share on other sites
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 = char
uint8 = unsigned char
int16 = short int
uint16 = unsigned short int
int/int32 = long int
uint/uint32 = unsigned long int
float = float
double = double
bool = bool
bits8 = unsigned char
bits16 = unsigned short int
bits/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;
ctx->Prepare(engine->GetFunctionIDByDecl(0, "bool ScriptFunc(int,bool,double)"));
ctx->SetArgDWord(0, intval);
ctx->SetArgDWord(1, boolval);
ctx->SetArgDouble(2, dblval);
boolval = (bool)ctx->GetReturnDWord();

Of course, you need to add error verification.

Let me know if you need more help.


Share this post

Link to post
Share on other sites
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. :)

Share this post

Link to post
Share on other sites

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


Share this post

Link to post
Share on other sites
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 :)

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!