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
Offline Last Active Yesterday, 02:53 PM

#5120786 No AS binary packages

Posted by Andreas Jonsson on 02 January 2014 - 04:53 PM

If your definition of 'mature' means that the libraries interface cannot evolve anymore, then I guess AngelScript isn't mature yet (even after 10+ years of development). But if your definition of 'mature' is how many successful projects use AngelScript and how long it's been available then AngelScript is really quite mature. Guess, which definition of 'mature' I use. ;)


Most developers that use AngelScript keep a copy of the version they integrate, they even check-in the source code in their own repository. This removes any dependency on my repository and avoids confusion when other users download your project (as it will include the exact version of AngelScript you're using). The developer is then also in full control when he wants to upgrade to the latest version of AngelScript, or if he'd rather continue using an older version. Some developers upgrade with every new release (usually it is just a couple of tweaks to the existing code), others only upgrade every couple of years (and usually have a little more work).



On the topic of version numbering. The 1st digit is the major version. I'll only change this to 3 when I'm ready to take the step to remove old functionality (and breaking script compatibility). The 2nd digit is the interface version. I change this everytime there is a change to the interface (though usually it is just an additional parameter, or method, or similar). The 3rd digit is for releases that doesn't change the interface, but implement something new. On some occasions I've also used a final letter, without changing the numbers. This is when releasing only bug fixes, without any other changes.



I try to avoid changing the interface all the time. Normally I hold off on features that change the interface until I have a couple of different ones that I can release together, but I cannot stop it all together as then I'll soon run out of options to evolve the library. I also definitely will not maintain 2 parallel versions. That would only lead to even more confusion and would take away from my already too few available hours to work on the library.

#5118108 variable persistence and does it make sense to have an 'idle loop'

Posted by Andreas Jonsson on 19 December 2013 - 07:43 AM

Think of your first alternative as a parallel thread in your application. The application will allow the context to execute for a while, then the context will wait (suspend) until it is time to execute again.


The other option is more like to event handling. Anytime there is an event in the application, the context is executed to handle that even and may use global variables (or properties registered by the application) to keep state information between executions.



Both options are perfectly viable with AngelScript, and it will only depend on your preference.


In my opinion the second option is easier to implement and manage, for the same reason that a singlethreaded application is easier to implement and manage compared to a multithreaded application.

#5115666 When to use asOBJ_APP_CLASS_ALLINTS

Posted by Andreas Jonsson on 09 December 2013 - 09:37 AM

The flags asOBJ_APP_CLASS_ALLINTS/FLOATS are used to tell AngelScript what the type of content the object has, so AngelScript can decide how the object should be passed to registered functions in native calling conventions. The only ABI so far that needs these flags is the AMD/Intel 64bit ABI that the g++ compiler uses. This specific ABI can decide to put the object in the CPU float registers or general registers depending on the type of the members of the class.


On any other platform or compiler the flags will have no effect.


The documentation that describes when/how to use these flags is here:


Manual: Value types and native calling convention




#5113915 Update script function argument on resume from suspend

Posted by Andreas Jonsson on 02 December 2013 - 07:15 PM

You can only set arguments on the context after Prepare() and before the first Execute(). The SetArg methods returns an error if not in this state. I bet you didn't check the return code, am I right? ;)


When a context is suspended and then resumed with another call to Execute() it will continue at the exact same position where it was suspended, which means that any function arguments that were passed into the function in the first call will already have been read and used. Even if the context would allow you to set the arguments while the context was suspended there would be no guarantee that the script would actually re-read the arguments when resuming.


If you mean to change the argument, why not allow the script to run to it end and then simply call the script again with the new argument? I.e. remove the while loop and the SuspendMe() call. 


void main(float frameDelta)
  if( something )

#5113559 Default constructors vs default arguments

Posted by Andreas Jonsson on 01 December 2013 - 03:26 PM

I've implemented this in revision 1792.




#5112862 Alignment requirements

Posted by Andreas Jonsson on 28 November 2013 - 06:01 PM

I don't think it is because of anything malloc does. More likely the debug build uses different instructions to load the SIMD registers so the __m128 types doesn't require alignment. This is however something that would be in your application, and not in AngelScript. 


You can set custom memory functions with asSetGlobalMemoryFunctions(). With this the application can use memory routines that is guaranteed to always return 16byte aligned memory to the script library. You probably don't want to use 16byte aligned allocations for everything though, as it will waste a lot of memory when the allocations are smaller than 16bytes. 


This gave me an idea. The code in as_memory.h can perhaps be enhanced to have a new macro for allocating 16byte aligned memory, e.g. asNEW16 and asNEWARRAY16. This macro can then call a new userAlloc16 global function. The pieces of code I mentioned above that need to guarantee 16byte aligned memory would then only have to call these macros instead of the existing ones to allocate the memory. 

#5111449 Problem with array of handles

Posted by Andreas Jonsson on 23 November 2013 - 09:50 AM

I've implemented the findByRef in revision 1785

#5111105 Global Variables

Posted by Andreas Jonsson on 21 November 2013 - 04:00 PM

With the current version of AngelScript I can think of two ways of solving this.



1. By having some function for retrieving the existing object from the application, through a lookup. You can then have your 'secret' global variables call this function as part of their initializations.

// Secret Global Section
const MyLinkedType@ v1 = __GetExistingObject('whatever');

// User section
const MyLinkedType@ u1 = v1

int main()
    const MyLinkedType@ u2 = v1

    if (u1 is v1)
        return 1;
    else if (u2 is v1)
        return 2;  // This is what returns.
        return 0;

2. Register the 'secret' global variables from the application, instead of declaring them as part of the script. You can use dynamic configuration groups to unregister the global variables in case they change.








As a future enhancement to better support what you want I can think of 2 solutions:


1. Allow resetting global variables selectively. The application could then manually initialize some of the global variables like you currently do, and mark them as finished. Then call ResetGlobalVars to have the script engine initialize the remaining variables.


2. Implement the already planned export-import feature. With this you could compile the secret global variables in a separate module and mark them for export. The user written module will then import the global variables already pre-initialized.

#5109927 [PATCH] Compiler performance improvements

Posted by Andreas Jonsson on 17 November 2013 - 08:44 AM

I've finished incorporating these improvements into the WIP version. (revision 1779).


With the improvements I see an average improvement of around 30% in the compilation times. 


I didn't include the changes as-is, so when you pick up the new version you'll will not see exactly the code you provided, but you should see that all the improvements you made has made it into the code, and in some cases I made further improvements on top of them.




#5109635 Problem with array of handles

Posted by Andreas Jonsson on 15 November 2013 - 09:05 PM

Yes, you're right. Two different functions with appropriate names is better.

#5108504 Feature chat: Type/member annotations

Posted by Andreas Jonsson on 11 November 2013 - 12:24 PM

Currently you would need to keep the CScriptBuilder around. Or extract the metadata to store it in some other form. With the change I proposed, the metadata could for example be stored as user data in the script code (actually, it can already be done that way, unless you're already using the user data for something else). 


The metadata for classes should preferably be stored with the asIObjectType, and not the asIScriptObject. After all, the metadata is part of the code, and not the instances.

#5107304 ValidateNoUsage

Posted by Andreas Jonsson on 05 November 2013 - 06:10 PM

Try revision 1768. It should have fixed the warning for good. :)

#5107299 ValidateNoUsage

Posted by Andreas Jonsson on 05 November 2013 - 05:46 PM

I've fixed the memory leak in revision 1767.


I'll see if I can figure out why you're seeing the warning still. 

#5107052 ValidateNoUsage

Posted by Andreas Jonsson on 04 November 2013 - 07:58 PM

The memory leak is because you're registering the default copy operator twice for the AddressList type:


objmthd "AddressList" "AddressList& opAssign(const AddressList&in)"

objmthd "AddressList" "AddressList& opAssign(const AddressList&inout)"


Of course, AngelScript shouldn't silently accept this, but I'll add the verification for this tomorrow.

#5107044 ValidateNoUsage

Posted by Andreas Jonsson on 04 November 2013 - 07:33 PM

I've fixed the warning in revision 1766. 


It doesn't appear to be related to the memory leak, so I'm going to try to reproduce that now.