Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Today, 03:04 PM

#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.




#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.




#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. 

#5146765 [EXPERIMENTAL PATCHES] Named arguments and auto declarations.

Posted by Andreas Jonsson on 13 April 2014 - 02:33 PM

I've included the 'auto declarations' patch in revision 1893.

#5144652 Changing the content of global variables from C++

Posted by Andreas Jonsson on 05 April 2014 - 07:10 PM

If you wish to change values of global variables in the script from the application side, then using the GetAddressOfGlobalVar() is the way to do it. For object handles you'll need to remember to release the previous object, and add a reference for the new object. For objects stored by value you can use the engine's AssignScriptObject() method to call the assignment operator.

#5144344 compiling AngelScript - error!

Posted by Andreas Jonsson on 04 April 2014 - 07:38 AM

Yes, 4.8.2 has the same STL implementation as 4.7 so you'll definitely need the update in scriptstdstring.cpp that I mentioned above.


Note, this is not a bug in g++. It's just that with 4.7 they changed their STL implementation, previously the operator== was a global function as it is on other compilers, but with 4.7 they changed it to be an member operator, which is why the asFUNCTIONPR macro stopped working.


Talk to the OpenDungeons managers to update the scriptstdstring.cpp with the above fix (or even update the entire angelscript library), and you should be good to go.

#5144092 compiling AngelScript - error!

Posted by Andreas Jonsson on 03 April 2014 - 07:52 AM

Ah, it looks like the OpenDungeons managers haven't upgraded the AngelScript version they are using for a while.


This compilation error is specific to the g++ 4.7+ compiler and version. In a more recent version of AngelScript I've solved it by implementing a wrapper for the std::string::operator==. Like this:


// String equality comparison.
// Returns true iff lhs is equal to rhs.
// For some reason gcc 4.7 has difficulties resolving the
// asFUNCTIONPR(operator==, (const string &, const string &)
// makro, so this wrapper was introduced as work around.
static bool StringEquals(const std::string& lhs, const std::string& rhs)
    return lhs == rhs;
void RegisterStdString_Native(asIScriptEngine *engine)
   // Need to use a wrapper for operator== otherwise gcc 4.7 fails to compile
   r = engine->RegisterObjectMethod("string", "bool opEquals(const string &in) const", asFUNCTIONPR(StringEquals, (const string &, const string &), bool), asCALL_CDECL_OBJFIRST); assert( r >= 0 );

#5143596 Garbage Collection Bug

Posted by Andreas Jonsson on 31 March 2014 - 07:11 PM

I've fixed this problem in revision 1889.




#5143533 Read from a file

Posted by Andreas Jonsson on 31 March 2014 - 01:04 PM

Is the file in binary format or text format?


readLine is meant to be used for files in text format, and readInt for files in binary format. You most likely don't want to use both for the same file, unless the file is mixing text and binary formats.


readInt(8) will read an integer number stored in 8 bytes from the file and return it as an int64.


You may also want to check the byte-order of the file, you can tell the file object which order to use with the member mostSignificantByteFirst.

#5140173 AngelScript 2.28.2 is out

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




#5137358 Compiling error

Posted by Andreas Jonsson on 08 March 2014 - 11:43 AM

You haven't implemented the void print(const std::string &)' function that you declare on line 83.