Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Today, 12:58 PM

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

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




#5185872 BitmapFont - looking for atlas-packing-function

Posted by Andreas Jonsson on 08 October 2014 - 04:58 PM

I'm not sure if the algorithm that I use in BMFont is suitable for uv map packing. It works well for bitmap fonts since there is little variation between the sizes of each glyph, but when the sizes vary a lot the algorithm tend to leave a lot of unused space in the texture.


Anyway, the starting point for the packing algorithm I use is in the method CFontPage::AddCharsToPage that you'll find here: http://svn.code.sf.net/p/bmfont/code/trunk/source/fontpage.cpp.




#5185126 Array trailing comma

Posted by Andreas Jonsson on 05 October 2014 - 09:09 AM

I'll add an engine property to allow the application developer to decide how empty elements in initialization lists should be treated by the compiler. 




#5184200 ActiveContext for Context and Module Cleanup

Posted by Andreas Jonsson on 30 September 2014 - 08:02 PM

There is no use in providing a context to the asCModule::Discard or asCContext::Unprepare to do what you want, since there may still be objects that are not destroyed directly by these calls. If the objects are garbage collected they will only be destroyed when the garbage collector is certain that they are dead, which may not be immediately upon Discard or Unprepare.


However, with the release of 2.29.0 I implemented support for exactly what you need with the addition of SetContextCallbacks to the engine interface. Through these callbacks the application has the means to provide user data and initial settings even for script contexts used internally by the engine (for example to call the destructor during garbage collection). 


Not only will these callbacks be used when the engine internally needs a context, but the add-ons also request their contexts through the same callback by calling RequestContext on the engine and then return it with ReturnContext. Thus, by using these callbacks you can easily provide a single source of contexts with correct configuration for all executions.




#5183518 'is_trivially_default_constructible' is not a member of 'std'

Posted by Andreas Jonsson on 28 September 2014 - 12:55 PM

Try revision 2015. I've added a special case for gnuc 4.8 and later.




#5180090 Variable parameter type "?" to accept only handles during compile -...

Posted by Andreas Jonsson on 13 September 2014 - 11:26 AM

I've been thinking in similar lines. ?@ would be a nice way telling the compiler only to accept handles. Another option that I've thought about would be to have some callback so the application can decide at compile time whether the passed in type should be allowed or not. The latter would require more work by the application developer, but would provide exact control.




The problem with the constructor sounds like a bug in the library. I'll investigate it.

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