A new version of AngelScript has been released. Since this is an x.0 release, a lot of changes to the interface has been made. Especially the way object types and their behaviour have suffered quite a few changes. First, it is no longer required to define the application type (asOBJ_APP_) when registering value types, only if the value type is passed by value to or from registered functions that use native calling conventions. Since these flags are not always easy to grasp I hope this will decrease the number of doubts for new comers. Secondly, most of the object type behaviours should now be registered as class methods with specific names, rather than as behaviours. This is a unification with how the script classes implement the same behaviours. With this I have also been able to eliminate the RegisterGlobalBehaviour method, though the RegisterObjectBehaviour method is still there for those behaviours that need special treatment, such as constructors, factories, addref, release, etc. As mentioned in a previous post, a JIT compiler interface was being developed by Fredrik Ehnbom. Now it has been completed and ready for use. There are no JIT compilers available yet, but hopefully they will start arriving soon. A couple of new add-ons have been made as well. A templated array type has been implemented. Currently it is almost identical to the built-in array type, and it will eventually replace it completely. By having the array type as an externally registered type, the application developers will be able to customize it much easier. Another add-on is the new context manager. This add-on adds support for co-routines and concurrent script threads, so that the applications that want that no longer have to implement it themselves. For the upcoming versions I plan on making further improvements to the template type, e.g. support for multiple subtypes, support for initialization lists, and support for compile time callbacks for verifying allowed subtypes. I also plan on implementing support for getters/setters for properties, both for registered types and script classes. Another improvement I'm working on is the internal structure for how functions and global variables are stored. I plan on making it much more flexible so that the applications that want it can dynamically modify modules at run time, without having to recompile the entire thing. This will add support for hot-loading scripts, dynamically built scripts, and even self-modifying code.

• Change list
• Manual

Awesome stuff. I am particularly excited about hot loading since we have removed that support (due to difficulties in 'getting it right') in the higher level.

I'm also excited about the JIT support.

...and reflection.

With AngelScript's new features going in, I almost feel like our scripting system will need a redesign so I can take advantage of them and provide more power.

I am not looking forward to making all the interface changes that were made this release though :) I'm sure once I dig in and start it should go easy.

Thanks Andreas and crew!

The interface changes that were made really shouldn't have too much impact on the applications. It's mostly a matter of changing the method used to register the types. For example:

engine->RegisterObjectBehaviour("type", asBEHAVE_ASSIGNMENT, "type &f(const type ∈)", asMETHOD(type, operator=), asCALL_THISCALL);

becomes:

engine->RegisterObjectMethod("type", "type &opAssign(const type ∈)", asMETHOD(type, operator=), asCALL_THISCALL);

and:

engine->RegisterGlobalBehaviour("type", asBEHAVE_ADD, "type f(const type ∈, const type ∈)", asFUNCTION(typeAdd), asCALL_CDECL);

becomes:

engine->RegisterObjectMethod("type", "type opAdd(const type ∈)", asFUNCTION(typeAdd), asCALL_CDECL_OBJFIRST);

There are of course a few other changes. But I think that once you look into it you'll see that there shouldn't bee too much that needs to be done.



Yeah, I really hope my upcoming changes will help you implement the hot loading you want. Hot loading won't be built-in to the engine, because the applications needs to make a lot of decisions on what to do with active objects, references, and so on. But with the ability to dynamically exchange functions, variables, and hopefully even types, in the modules it will hopefully be a lot easier to do.

Hm. I'm a little confused. How does operator overloading work now?
In 2.16.0 I used to do something like this:

Is this still possible? Do I need to add a Vector3::add() method now?

As far as I know you don't have to change your application-side functions and methods*. What has changed is the way how you should register these functions and methods. In 2.16.x you could register them as global behaviours. However, now you should declare them as regular object methods with a predefined name (Operator overloads).

So, this:


Becomes this:


To use the same function we change the calling convention type from asCALL_CDECL to asCALL_CDECL_OBJFIRST. That way the current object is passed to the appropriate function/method as the first parameter, and the AngelScript parameter is passed as the second parameter.

* If you're going to use comparison operators (>, >=, <=, <), you'll need to define a small wrapper function. See this post by WitchLord for more information.

ZCCdark203: Well explained. You're absolutely correct. :)

Thanks for the help.
There is one case left which I don't get.
I used to have

RegisterGlobalBehavior(asBEHAVE_MULTIPLY, "Vector3 f(float, const Vector3 ∈)", asFUNCTIONPR(operator*, (float, const Vector3 &), Vector3, asCALL_CDECL);

which I tried to replace whith

RegisterObjectMethod("Vector3", "Vector3 opMul(float)", asFUNCTIONPR(operator*, (float, const Vector3 &), Vector3), asCALL_CDECL_OBJLAST);

This doesn't do the intended thing, though.

Vector3 v(1,2,3); 0.5 * v; //No conversion from "Vector3&" to math type available.//Must be used like v * 0.5

Any ideas on this one?

EDIT:
Ah, nevermind. No I know what the opFunc_r variety does. Everything ported over now. Thanks!