Jump to content

  • Log In with Google      Sign In   
  • Create Account


Andreas Jonsson

Member Since 26 Mar 2000
Online Last Active Today, 07:04 PM
*****

#5167970 AngelScript 2.29.1

Posted by Andreas Jonsson on 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.

 

Regards,

Andreas




#5167019 assign Operator Issues

Posted by Andreas Jonsson on 15 July 2014 - 10:50 AM

Your VEC2_REF operator= is implemented to return the type by reference without incrementing the refcount, but you've registered this method as returning the type as a handle. Because of this AngelScript will release the returned reference when it is done with it, and this cause the VEC2_REF instance to be destroyed while you still have other pointers referring to it elsewhere. This is why you're getting the 'Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)' error.

 

 

Do you have a specific reason for implementing the vec2 type as a reference type? Unless you have a specific reason to have these instances allocated on the heap with reference counting, it is probably better to register the vec2 class directly as a value type (similar to the complex type in the scriptmath add-on).

 

 

Regards,

Andreas




#5166438 Forward declarations

Posted by Andreas Jonsson on 12 July 2014 - 12:23 PM

This is on my to-do list. But to be quite honest: It is very low on my priority.




#5164463 AngelScript 2.29.0 is here

Posted by Andreas Jonsson on 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?
}



#5162163 Bug: New Functions not accessibly by GetGlobalFunctionByIndex after removing...

Posted by Andreas Jonsson on 22 June 2014 - 02:05 PM

I've fixed this problem in revision 1965.

 

Regards,

Andreas




#5162144 tempVariables assertion with indexed unsafe reference

Posted by Andreas Jonsson on 22 June 2014 - 11:58 AM

I've fixed the bug in revision 1964.

 

Regards,

Andreas




#5160626 how can i parse Script functions, variables, etc

Posted by Andreas Jonsson on 15 June 2014 - 08:23 AM

This is what the parser is made for :)

 

You can see the implementation I have for AngelScript in the as_parser.cpp file.




#5160178 BMFont solution can't find standard include files in VS 2010

Posted by Andreas Jonsson on 12 June 2014 - 06:14 PM

BMFont is doesn't do anything differently with regards to the include directories. Perhaps the problem is because the project files from the SVN are for MSVC 2012, and not MSVC 2010.

 

Try creating a new project on your own and include the source files in it.

 

Or try upgrading MSVC. There is even a version 2013 now. 




#5160175 BMFont Demo (exe and source) don't work

Posted by Andreas Jonsson on 12 June 2014 - 06:06 PM

I've updated the demo now. Download the file again, and let me know if it is still causing any problems for you.

 

Regards,

Andreas




#5159924 AngelScript 2.29.0 is here

Posted by Andreas Jonsson on 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);
 
   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>




#5159420 AngelScript 2.29.0 is here

Posted by Andreas Jonsson on 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




#5159093 Unregister function?

Posted by Andreas Jonsson on 08 June 2014 - 09:57 AM

You can use configuration groups for this. When registering the functions that needs to be removed later, you should do so in a configuration group. The entire configuration group can then be removed dynamically.




#5156127 Registering an uninstanciable reference type: Identifier 'XXX' is not...

Posted by Andreas Jonsson on 26 May 2014 - 04:07 PM

The copy operator error is because you're doing a value assign in the constructor. You need to prefix the left hand expression with @ to indicate a handle assign (i.e. replacement of the reference).




#5151719 Compiler crash, r1777 -> r1778

Posted by Andreas Jonsson on 05 May 2014 - 04:49 PM

Hmm, actually there is a problem in your SCRIPTF_ExecuteAsync implementation.

 

The CScriptHandle type should be received by value, and not as a pointer. The call to AddRefScriptObject is also not needed (in fact, it doesn't do anything for the CScriptHandle type).

 

You see, the CScriptHandle is really a value type, and not a ref type. It represents an object handle, but it doesn't have a reference counter by itself (much as a handle itself doesn't have one).

 

The function should be like this:

 

static void SCRIPTF_ExecuteAsync(asIScriptFunction *pfunc, CScriptHandle ref, float t){
    //...
    pscript->Execute(pfunc,...,&ref); //basically finds a free context, prepares it and executes in a concurrent manner
}

 

No changes to how you register it with AngelScript.

 

 

Observe, you were able to use it the way you were before, because behind the scenes C++ will send the CScriptHandle as a reference since it is a complex type. C++ reference and pointers are equivalent in the native calling convention. But that was just luck on your part, and is most certainly not portable to rely on this. :)




#5150221 Value of variable set under ominous circumstances

Posted by Andreas Jonsson on 28 April 2014 - 07:27 PM

Ah, that definitely explains it. 

 

And, no it is not a bug. AngelScript doesn't initialize primitives with 0 (same as C++), so if you do not assign a specific value to the output parameter it will get whatever uninitialized value was in slot on the stack before the call. AngelScript also do not pass the a reference to the actual variable that will receive the value (since it cannot guarantee that this reference will stay alive throughout the call), so the reference will always point to a temporary uninitialized variable. This temporary unitialized variable will then be assigned to the final variable after the call.

 

I have had an entry on my to-do list for quite some time to have AngelScript initialize all variables to 0 by default. It's been there for quite sometime because it is not a trivial task (contrary to what can be imagined). The complications come from the fact that I do not want to add unnecessary overhead that would impact the performance.

 

I'll add a note on this situation to my to-do list and bump up the priority, but I can't promise it will be changed anytime soon. 






PARTNERS