Sign in to follow this  
WitchLord

AngelScript 2.29.0 is here

Recommended Posts

WitchLord    4677

After an unusually long period a new version is finally out. This version comes with a number of smaller enhancements. Too many to list here, so if you want details, please check the change list.

 

The most important improvements are the following:

 

A new flag to support C++ array types: asOBJ_APP_ARRAY. This flag introduced for C++ types like the following: 'typedef float vec3f[3]', as this kind of types didn't follow the ordinary calling convention for classes nor primitives.

 

Thanks to GGLucas the script language now supports named arguments when calling functions. This means that you can now call a function using the following syntax: 'func(arg1 = expr, arg2 = expr2)' and so on. When this is done, the compiler will rearrange the arguments by their names so that the order matches the declaration. This works especially well together with default arguments, as you will be able to provide only a few of the arguments, leaving the rest with the default value.

 

Also thanks to GGLucas the script language now supports auto types in variable declarations with initialization expressions. Just like in C++ the compiler will deduce the type of the variable from whatever type the expression evaluates too.

 

I've implemented a new operator overload 'opHndlAssign'. Types registered with asOBJ_ASHANDLE should use this operator overload instead of the ordinary 'opAssign' to implement the handle assign operation. This together with an enhancement to asBEHAVE_VALUE_CAST to allow the generic form 'void f(?&out)' has allowed me to implement a nicer syntax for managing the values in the dictionary add-on:

int val = int(dict['value']);
dict['value'] = val + 1;
obj @handle = cast<obj>(dict['handle']);
if( handle is null )
  @dict['handle'] = object;

This should lend itself well for implementing a true 'variant' type. Perhaps that's even something I'll try for an upcoming release.

The engine has a couple of new callbacks calls RequestContext and ReturnContext. These callbacks can be used to implement context pooling for better performance, and they can also be used to pre-configure contexts that will be used internally by the engine, e.g. to debug script class destructors called from the garbage collector.

 

Jordi Oliveras Rovira has taken the time to implement support for functor calling conventions asCALL_THISCALL_OBJFIRST and asCALL_THISCALL_OBJLAST. These work similarly to the existing asCALL_THISCALL_ASGLOBAL where the application supplies the a pointer to the functor object that emulates the function/method that the script calls. With this it is now perfectly possible to use for example std::function to implement proxy/wrapper functions if so desired.

 

Regards,

Andreas

Edited by Andreas Jonsson

Share this post


Link to post
Share on other sites
theoutfield    291

Andreas,

 

Can you elaborate a little bit more about the registration of arrays.  Maybe even give a little example.  Does this change anything with the array addon?  Do you still need to register the addon to use arrays?

 

Thanks,

Tony

Share this post


Link to post
Share on other sites
WitchLord    4677

I presume you're referring to the new asOBJ_APP_ARRAY flag.

 

This doesn't affect the array add-on. It is only used when registering value types, i.e. together with asOBJ_VALUE. Here's an example:

 

typedef float vec3f[3]; 
 
vec3f AddVec3(vec3f a, vec3f b) {
  vec3f r = {a[0]+b[0], a[1]+b[1], a[2]+b[2]};
  return r;
}
 
void RegisterVec3(asIScriptEngine *engine)
{
   engine->RegisterObjectType("vec3", sizeof(vec3f), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_ARRAY);
   engine->RegisterObjectProperty("vec3", "float x", 0);
   engine->RegisterObjectProperty("vec3", "float y", 4);
   engine->RegisterObjectProperty("vec3", "float y", 8);
 
   engine->RegisterGlobalFunction("vec3 add(vec3, vec3)", asFUNCTION(AddVec3), asCALL_CDECL);
}
 
 

 

Without the asOBJ_APP_ARRAY AngelScript wouldn't know exactly how to handle this type when passing it by value to an application registered function, or receiving it by value, so the application developer had to resort to wrappers when dealing with this kind of types.

 

How these flags should be used and why are also described in the manual here: <a href="http://www.angelcode.com/angelscript/sdk/docs/manual/doc_register_val_type.html#doc_reg_val_2">

Value types and native calling conventions</a>

Share this post


Link to post
Share on other sites
WitchLord    4677

I've decided to change the syntax for named arguments to use : instead of =. This is done in revision 1973.

 

Why did I make this decision? Well, because of the following situation:

 

void func(int val)
 
void main()
{
  int val;
  func(val = 1); // What would this really do?
}

Share this post


Link to post
Share on other sites
iraxef    451

I need to maintain the old syntax for existing script-files which I cannot change. (That is, at runtime I know whether the file is 'old' and should support the = syntax, or 'new' and should support the : syntax instead).

 

Since the = syntax 'shipped' with a (non-WIP) version of AngelScript, would you consider a patch, if I provided one, which implemented an asEEngineProp option (that I could toggle every time I'm about to build a file)?

 

Thank you very much.

Edited by iraxef

Share this post


Link to post
Share on other sites
iraxef    451

Thanks, I'll work on that.

 

To clarify, if I had saved already-compiled bytecode for my 'old' files and loaded/ran that against this updated version of the AngelScript library.. that'd work fine because the code was already parsed (obviously), right?

Share this post


Link to post
Share on other sites
WitchLord    4677

Correct. The bytecode is not affected by this.

 

However you should never rely on pre-compiled bytecodes to be compatible between differents versions of AngelScript. There is no defined file format for the pre-compiled bytecode that is being maintained between SDK versions.

Share this post


Link to post
Share on other sites
WitchLord    4677

I've implemented the engine property asEP_ALTER_SYNTAX_NAMED_ARGS to optionally support the previous syntax for named arguments. It has 3 values:

 

0 = no support for old syntax (default)

1 = support old syntax but warn if detected

2 = support old syntax without warnings

 

This is available in revision 1974.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this