• Create Account

## AngelScript 2.29.0 is here

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

10 replies to this topic

### #1Andreas Jonsson  Moderators

Posted 09 June 2014 - 09:45 PM

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, 09 June 2014 - 09:48 PM.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #2theoutfield  Members

Posted 11 June 2014 - 07:19 PM

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

### #3Andreas Jonsson  Moderators

Posted 11 June 2014 - 07:50 PM

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);

}



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>

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #4theoutfield  Members

Posted 13 June 2014 - 07:36 PM

Thanks.

### #5Andreas Jonsson  Moderators

Posted 02 July 2014 - 07:40 PM

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?
}


AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #6iraxef  Members

Posted 03 July 2014 - 10:31 AM

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, 03 July 2014 - 10:33 AM.

### #7Andreas Jonsson  Moderators

Posted 03 July 2014 - 12:13 PM

Yes, I suppose that would be possible.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #8iraxef  Members

Posted 03 July 2014 - 12:20 PM

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?

### #9Andreas Jonsson  Moderators

Posted 03 July 2014 - 01:32 PM

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.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #10Andreas Jonsson  Moderators

Posted 03 July 2014 - 06:48 PM

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.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #11iraxef  Members

Posted 04 July 2014 - 01:40 PM

Thank you!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.