Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Andreas Jonsson

Member Since 26 Mar 2000
Online Last Active Today, 08:12 AM

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




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




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