Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 07:35 PM

Topics I've Started

AngelScript 2.29.1

20 July 2014 - 11:32 AM

This is a quite small release compared to the previous ones. Still, it is an important one as it corrects a mistake in the last release regarding the syntax for named arguments.


In version 2.29.0 the support for naming the arguments when calling functions was implemented using the following syntax: func(arg1 = expr1, arg2 = expr2). The problem with this syntax was that it would not be obvious to the reader when an argument happened to have the same name as a variable.


So, I decided to change this syntax to use the following syntax instead: func(arg1: expr1, arg2: expr2). I'd like to think of it as labelling the arguments.


For those, who prefer the = token, or don't want break backwards compatibility I've added an engine property asEP_ALTER_SYNTAX_NAMED_ARGS that can be used to optionally support the previous syntax.


This release also brings a couple of other minor enhancement, such as the support for registering template types as value types, declaring script classes as abstract, and the inclusion of asGetTypeTraits() as part of the official SDK interface.




AngelScript 2.29.0 is here

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.




AngelScript 2.28.2 is out

18 March 2014 - 07:13 PM

My primary goal with this version was to implement the grid add-on, which basically a 2D array with rectangular dimension. Multi-dimensional were already supported in the script language as arrays-of-arrays, but this would often become cumbersome to work with when a rectangular area was wanted as each subarray had to be resized individually. Accessing elements in arrays-of-arrays is also not particularly efficient as there is a lot of overhead.


In order to properly support the grid add-on (and any other multi-dimensional array implementation that developers imagine) the library was enhanced to allow multiple arguments in the opIndex overload, and the list pattern declaration gained a new keyword 'repeat_same' to tell the compiler that all sub-lists should be of the same size.

The grid add-on itself is currently quite basic with very little functionality besides setting up a 2D area and allowing the script to access the elements, but it serves it's main purpose of showing developers how multi-dimensional arrays can be implemented. Ideas for how to make it a truly useful add-on are most welcome.


Other enhancements in this version that are worth mentioning include; added support for opCall operator to allow the implementation of functor objects in scripts, implemented support for anonymous objects initialized with lists, improved compiler rules for implicit casts in expressions, reduced size of saved bytecode, more efficient bytecode sequences.


Some other add-ons have also received improvements. The array add-on now supports custom memory routines (a side effect of this, is that when instantiated from C++ it is now necessary to use factory functions instead of allocating with new). The dictionary add-on has received enhancements to improve interaction from the C++ side with a method to retrieve the type id of a stored value, and an iterator with support for C++11 range-for loops. The math add-on also has a new function closeTo() that should be used to compare floats or doubles when one wants to do approximate comparisons to handle numerical impression in float and double calculations.




AngelScript 2.28.1

31 January 2014 - 06:51 PM

It's time for the first release of 2014.


This one brings quite a lot of under-the-hood improvements, such as reduced compilation times, less overhead in calling script interface methods, inline allocation of class members, reduced size of saved bytecode, improved error reporting for loading invalid bytecode, automatically resolve ambigiuous enum values, etc.


The script language has a new built-in math operator ** for calculating the exponent. Of course, this operator is overloadable just like the rest of the operators. This operator also added 7 new instructions for the VM to handle the primitive types.


Several of the add-ons have been tweaked and adjusted to make them easier to use.


Some of the improvements in this release were contributed by the community members GGLucas and Jason Goepel. So thanks should go out to them this time.




AngelScript 2.28.0 is out

02 November 2013 - 12:58 PM

With this version I've spent a lot of time to redesign how the initialization lists work. Previously they could only be used for arrays, but now the application can register a list factory, or list constructor for value types, and declare a pattern that should be used by the compiler. The compiler will also build a single buffer with all the value and pass a pointer to that buffer to the factory or the constructor. This makes it much more effective to copy the values into the object in comparison with the previous use of the index operator.


The new initialization lists are a lot more versatile, and I've used this to implement a list factory for the dictionary add-on that takes name-value pairs, and also a list constructor for the complex math type to show how it is done.


Hopefully this will make AngelScript much more useful as a data language, i.e. where the scripts are used to setup data besides just for logic.


There is of course a lot more than can still be improved with regards to the initialization lists, and I'll continue to work on this over the upcoming releases. Some examples of future improvements are the ability to use initialization lists in regular expressions, and more rules that can be given to declare the expected list pattern.


The release brings several other minor improvements too, so please verify the change list to get the details.