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

Witchlord

Where do I start looking to be able to compile the library as 64bit?

A quick look shows some defines like i386 etc. Would it be a lot of work to make it 64bit friendly?

Thanks