Version 2.1.0 of the script library is now available in it's finished version. It fixes a few critical issues with the last stable version and adds a few new features that will make it more portable. It's now possible to use const with object again, thus making it possible to protect object members from changes. With this it is also possible do method overloading based on object constness. A new calling convention has been implemented asCALL_GENERIC. With this calling convention the application functions receives an interface to allow the application to retrieve function parameters and set return value directly on the context stack. While this convention requires more work by the application writer, it is also 100% compatible between platforms and compilers. A new feature SetLineCallback() replaces the ExecuteNext() method. With the SetLineCallback() the application can more clearly control how the scripts are executed, and can for example set breakpoints by line number, or suspend execution based on timeouts. It is possible to set the memory management routines for each object type, which is especially useful when using dynamic types registered from dynamic modules that may use a different application heap than the main application. And finally a pure C interface has been added, that will make it easier for non-C++ applications to use the library. This should make it possible to use AngelScript with languages such as Pascal and D as well as ANSI C. In this version I also added a new add_on: asCScriptString. This add on shows how to register a class that allows the use of object handles, and also shows how the std::string and potentially other objects can be wrapped in a light container while still allowing the use of functions that take the normal std::string as reference parameters. Regards, Andreas [edit]AngelScript 2.1.0c was released - 2005/05/26[/edit] [Edited by - WitchLord on May 26, 2005 2:00:44 PM]

Does this release also fix the problem with objects in a constructor?

Yes. At least it should :)

I just wanted to say that I integrated the new version into my project (a casual game that uses scripts for configuration and implementation of different play modes), without any problems.

I am now using the LIB version rather than the DLL. I am also using the ASM VM version.. Witchlord, care to shed some light on this? I presume it is a faster version with a VM core written in assembler.. or is it a JIT VM? Also, the name of the static library in release mode is angelscriptd.lib. Is the "d" intentional?

You are doing a brilliant job with this project, well done!! :)

the d i think was the debug release of whatever engine build you are using.


The ASM engine is just an ASM implementation of the VM.

I was in fact presuming that the "d" stands for debug mode.. the problem is I compiled in Release mode yet still got angelscriptd.lib.

'd' does indeed stand for debug. I'll verify the project settings in the SDK.

The ASM VM is just an optimized version of the C++ VM, by writing the VM in assembly I'm able to shave of a few assembler instructions per bytecode, leading to 10-25% performance increase. With newer CPUs less performance increase is noticed (which shows that soon it will be pretty useless to write anything in assembly [wink]).

Regards,
Andreas

*Round of applause for Andreas* [smile] I had tried it once a while back, but never got into it because there was no need. Now there is a need, so I will give it a good evaluation, nice to see how well you're progressing with this!

which is the performance compared to "other" scripting language?
I know that this is a bore question, but I think this is the key question in order to choose one script language or other

davidinho:

I haven't personally compared the performance of AngelScript with other script libraries, but I've heard that it is good. AngelScript should at least be comparable to other script libraries, if not faster. I have also identified several locations that can be optimized which should bring up the performance of AS greatly. One such optimization involves changing the VM from stack based to register based. Lua did this with version 5 and their performance doubled because of this, I believe AS will show similar results.

In my opinion the performance of a scripting library is not the principal factor to look at when choosing, instead you should look at the features the library offers and how easy it is to use. I still intend to make all the optimizations I can to make AngelScript as fast as possible, but compared to native code there is no way any scripting language can become good enough, thus if performance worries you, you should be implementing your stuff in native code instead.

If you should do some performance comparisons with other libraries I would be interested in knowing the results. It's always good to know how your competition does, so that you get inspired to work even harder. :)

Anonymous Poster:

I'll take your question to a new thread, since I believe this will be an interesting discussion.

AngelScript on 64bit x86

[Edited by - WitchLord on April 6, 2005 9:33:23 AM]