Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 08:05 PM

#5212836 Virtual property compound assignment on temporary object handle (v2.30.0)

Posted by on 24 February 2015 - 09:06 PM

I've fixed this bug in revision 2137. 

#5212279 AngelScript 2.30.0 is here

Posted by on 22 February 2015 - 09:58 AM

It's been almost exactly 4 months since the last release. This is longest period I've gone without making a new release since this project started back in 2003. This does not mean that development has slowed down though, I merely restrained myself from releasing the code so I could fit more improvements into it. If you take a peek at the change log you'll see that this is by far the largest update too.


As always, when I change the middle version number there are some changes in the interface. The changes are not dramatic, but might require some minor code changes. The most dramatic change in the interface is the removal of the behaviours asBEHAVE_REF_CAST and asBEHAVE_VALUE_CAST (+implicit versions). These behaviours should now be registered as object methods with the names opCast and opConv, respectively. The implementation of the functions in the application doesn't change, just how they are registered with the engine.


I've improved the internal memory management so that less objects will be placed in the garbage collector. This translates into improved performance as less CPU will be required to clean up the dead objects in the GC. The change will perhaps not be too noticeable at runtime, but during recompilation of scripts and engine shutdown you should definitely see a significant improvement.


The script language has gotten some improvements too. The ternary condition operator can now be used as lvalue (as long as both options are lvalues of the same type). Script classes can implement the opCast and opConv operator overloads. Compound assignments can now be used with virtual properties too. Class members can be declared as protected, with the same meaning as in other languages.


There are of course enhancements in the add-ons too, but I'll leave the discovery of those to the reader.




#5211555 @ with handle properies doesn't work

Posted by on 18 February 2015 - 04:18 PM

The bug was still present in 2.30.0 WIP. I've fixed it now in revision 2132.




#5204717 How to get public member variables from script class in AngelScript

Posted by on 16 January 2015 - 09:10 AM

If you need to know which of the members were inherited from a base class, then you need to check if the same member is declared in the parent class too. You can get the parent class with the method asIObjectType::GetBaseType.


If you want to know if the member was declared as public you'll need to check the indicator isPrivate returned from asIObjectType::GetProperty. (Note, in 2.30.0 WIP I've added support for protected members too, so a second indicator isProtected is also available. If neither is true, then the member is public).



You may also want to look into using meta data in the script classes to for example allow the script to inform the editor what values are allowed. The CScriptBuilder add-on shows one way of how meta data can be implemented and collected from scripts, if you wish to use that.

#5204037 inheritance problem in AngelScript

Posted by on 13 January 2015 - 03:26 PM

Yes, it's correct. It works the same way as in C++ and other languages that support polymorphism.

#5198775 Serializing C++ objects with references

Posted by on 17 December 2014 - 09:34 AM

The serializer logic must keep track of which object instances have already been serialized, so that when a reference to the same object is seen from somewhere else it just stores some identifier to that first serialized instance instead of serializing it again.



Using your example, you could serialize it to the following text buffer:


object 0001 type "Foo" value "Yay"

variable "foo" type "Foo@" value ref to 0001

variable "foo2" type "Foo@" value null

object 0002 type "Bar" value ref to 0001

variable "bar" type "Bar@" value ref to 0002

object 0003 type "Bar value ref to 0001

variable "bar2" type "Bar@" value ref to 0003


It's obviously invented syntax, but hopefully you can easily understand that there are 3 object instances (1 Foo, and 2 Bar). Each are identifier with a sequence number. The 4 variables from the original script are serialized by the name and refer to the serialized objects by the sequence number.



De-serializing this into the hot-loaded script would work as following:


1. Create an instance of "Foo" and store in a map with key 0001

2. Skip the variable "foo" since it is no longer present in the script module

3. Skip the variable "foo2" since it is no longer present in the script module

4. Create an instance of "Bar", and populate its member to refer to the instance of "Foo" found in the map with key 0001. The instance is stored in the map with key 0002

5. Set the variable "bar" to refer to the instance of "Bar" stored in the map with key 0002

6. Create an instance of "Bar", and populate its member to refer to the instance of "Foo" found in the map with key 0001. The instance is stored in the map with key 0003

7. Set the variable "bar2" to refer to the instance of "Bar" stored in the map with key 0003



The above shows how it might work if you serialize Foo by storing its content. If instead you only serialize the reference to Foo, then the serializer need to increment the refCount so the object is not destroyed too early, and then release it after you've hot-loaded the script.

#5198171 Casting value objects.

Posted by on 14 December 2014 - 01:27 PM

Polymorphic value types is tricky in a "safe" language like AngelScript. In order to be able to send a value type by reference to a function AngelScript sometimes has to make a copy of the value type in order to guarantee that the reference will stay safe throughout the function call. When this is done on the base type, the data from the derived type is lost in the copy, which is probably why you see the object as empty.


With reference types AngelScript does not have to make the copy of the object, since the lifetime is guaranteed by the existing references, so here it is perfectly OK to use polymorphic types.


asOBJ_REF | asOBJ_NOCOUNT with no factory behaviour is a valid combination. asOBJ_NOCOUNT tells AngelScript that it is not necessary to count the references to the object, since the lifetime of the object is managed by the application. no factory behaviour tells AngelScript that no instances of the type can be created by the scripts, any instances that should be created has to be created by the application.




#5193033 Compiler warnings with latest stable version

Posted by on 15 November 2014 - 05:09 PM

I've fixed the compiler warnings you mentioned in revision 2059. 

#5191978 Array trailing comma

Posted by on 09 November 2014 - 08:30 PM

I've added the engine property asEP_DISALLOW_EMPTY_LIST_ELEMENTS in revision 2050. Set it to true to tell the compiler to give an error on empty elements (but ignore the last comma in lists with variable length).




#5190999 Unexpected behavior when registering a global property

Posted by on 03 November 2014 - 03:26 PM

If your declaration is "Schedule @slIdleStand", i.e. you want the script to be able to reassign the handle to point to a different object, then the second argument must be a pointer to a pointer to a Schedule object, e.g. 


static Schedule *g_slIdleStandHandle = &slidleStand[0];  // Declared globally so the address of the variable is valid while the engine is valid
pEngine->RegisterGlobalProperty( "Schedule@ slIdleStand", &g_slIdleStandHandle );


Unfortunately there is no way for AngelScript to see the difference between one pointer to another, otherwise I would make AngelScript return an error if the property is registered incorrectly.

#5189006 Issue with implicit const qualifier on member handle vs object

Posted by on 24 October 2014 - 06:29 PM

I've fixed this in revision 2026. Thanks.

#5188977 Issue with implicit const qualifier on member handle vs object

Posted by on 24 October 2014 - 02:50 PM

This is clearly a bug in the AngelScript compiler. I'll have it fixed a.s.a.p.


Thanks for taking the time to create a small test for reproducing the problem. It will make it much faster to find and fix the cause.

#5188921 Relaxing script section is empty warning

Posted by on 24 October 2014 - 09:37 AM

I'll look into this. Perhaps only warning about empty sections if all are empty might be better as you suggested.

The warning was added because there were a couple of developers that accidentally tried to compile empty sections and obviously the result wasn't what they expected. So rather than giving an error when the application couldn't find the expected function or class, which may not be too clear about why the function or class is missing, I felt it better to give a warning when the section was empty. smile.png

#5188658 odd behavior with globally declared scoped reference types, is this normal?

Posted by on 22 October 2014 - 07:50 PM

It was indeed a bug in the library. I've fixed this in revision 2023.



Observe, that the new operator is not guaranteed to allocate the memory with the necessary alignment. I assume you're using a __m128 type in your vec class, thus you would need an alignment of 16 bytes. To get the proper alignment you need to use _aligned_malloc to allocate the memory and then the placement new operator to initialize it. The memory must then be freed with _aligned_free.

// Allocate memory with proper alignment then initialize it
r = engine->RegisterObjectBehaviour("vec", asBEHAVE_FACTORY, "vec @f()",  WRAPEXPR(vec*, (), new(_aligned_malloc(sizeof(vec), std::alignment_of<vec>().value)) vec()), asCALL_CDECL); assert(r >= 0);
// Manually call destructor then free the memory
r = engine->RegisterObjectBehaviour("vec", asBEHAVE_RELEASE, "void f()",  WRAPFUNC(void, (vec* t), {if(t) { t->~vec(); _aligned_free(t); }}), asCALL_CDECL_OBJLAST); assert(r >= 0);



#5188431 AngelScript 2.29.2 is out

Posted by on 21 October 2014 - 07:17 PM

This incremental release brings a few minor improvements along with the usual batch of bug fixes.


Perhaps the most exciting new feature is the ability for script classes to implement type conversions, by including methods named opConv for explicit conversions or opImplConv implicit conversions. The compiler will find the correct overload to call by examining the return type, so even though these methods do not take any arguments it is still possible to allow classes to be converted to multiple different types.


The rest of the improvements are quite minor and should be transparent to the application developers.


I'd also like to take the opportunity to advertise the recently released AngelScript Add-on Template Library by Sami Vuorela. This library complements the standard add-ons in the SDK with 6 new templated container classes. If you feel the standard add-ons are a bit limited, then you should definitely take a look at these.