Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!

Andreas Jonsson

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

#5178142 Integer Division

Posted by Andreas Jonsson on 04 September 2014 - 02:18 PM

I think the use of an engine property to treat the result of / and /= as float/double would be acceptable, as long as the impact in the code is relatively isolated (which ought to be possible).


I don't see the need for an additional operator to force integer division in this case, as the user can explicitly convert the result to integer with int(expr) if desired. Explicit conversions would be more readable than have a backslash or double-slash as integer division in my opinion.

#5169375 Callback function within a function?

Posted by Andreas Jonsson on 26 July 2014 - 03:28 PM

Most likely they are doing something like this:


// C++ implementation
void AddTimer(const string &asName, float time, const string &asFunction)
   // Find the function that should be called
   asIScriptModule *mod = engine->GetModule("game", asGM_ONLY_IF_EXISTS);
   asIScriptFunction *func = mod->GetFunctionByName(asFunction.c_str());
   // Store the function and argument for when it is time to call it
void CallTimerCallback()
   // Retrieve the function to call and argument from the storage
   // Prepare a context and call the function
   asIScriptContext *ctx = engine->RequestContext();
   ctx->SetArgObject(0, asName);


You can get more information on how to use callbacks from the manual.

#5169158 Outputting to Editor's console with AngelScript 2.28.1

Posted by Andreas Jonsson on 25 July 2014 - 12:24 PM

AngelScript (or any embedded scripting solution) is often used as event handlers.


You would compile the scripts once, e.g. when loading the level data, and then the compiled script functions are called as the game engine detects that a specific event occurred (e.g. the user pressed a button). This way you allow script writer to decide what should happen when the button is pressed, for example, write a message to the console, or fire the player's gun, etc.


You do not want to recompile the script every time you need to call a script. If you're planning on allowing the user to change the script dynamically during the game's execution, then recompile only when the script has actually changed.

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




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





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




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