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]

Cannot compile it using vc7.1 + stlport :

All Debug Mode (with _STLP_DEBUG):

angelscript\add_on\std_string\stdstring.cpp(162) : error C2440: 'type cast' : no way to convert from 'overloaded-function' to 'bool (__cdecl *)(const _STL::string &,const _STL::string &)'

(same on each line 'til 167.)

Release Mode

angelscript\add_on\std_string\stdstring.cpp
STLport\stlport\stl\_alloc.h(257) : error C2059: syntax error : 'extern'
...
nearly all stl header listed here with same error
...

Only Release with ASM VM Win32 does compile.

It seems that STLPort may have defined the comparison operators differently than MSVC++ and GNUC. Maybe you could try to find another way for taking the pointer of the operator functions?

The other error with extern seems to be an incompatibility problem between STLPort and MSVC 7.1+. I'm not sure how to fix that.

In either case, the AngelScript library itself doesn't use any STL functionality because I was afraid something like this would happen. The STL isn't all that portable as the compiler writers would like us to think.

You should be able to replace the std::string in the test application with another similar class and have it work just fine.

Quote: Original post by WitchLord
'd' does indeed stand for debug. I'll verify the project settings in the SDK.

Slightly OT I guess but I think a quick post is in order: I was still compiling in Debug mode although I thought I had set it to Release (my bad).. hence why I got angelscriptd.lib instead of angelscript.lib.

I use STLPort with no problems.

Just ensure that your build configuration is proper.

I've uploaded 2.1.0a with a few minor bug fixes.

This version also includes the first sample application written by me. It shows how an in-game console, ala Quake, could benefit from AngelScript.

I hope to write more samples for future versions.

Regards,
Andreas

I've uploaded version 2.1.0b with new minor bug fixes.

I've released 2.1.0c with more bug fixes.

Thanks to Andrey Kraynov, a.k.a _Dreamer, for discovering those bugs.