I have studied AngelScript by reading the test of AS,But there are some unresolved questions for me: 1.How to bind static member function to AS? 2.How to make a namespace in AS? 3.If I want to bind some class in 3rd party dll,like "class NxPhysicsSDK" in PhysX,I can't Add "AddRef" and "Release" method to it,So can I bind it as a reference or just have to use "asOBJ_VALUE"?

To bind something like NxPhysicsSDK, I assume the best method would be to use
r = engine->RegisterObjectType("NxPhysicsSDK", 0, asOBJ_REF | asOBJ_NOHANDLE);
However, your scripts would only be able to use that object if it is given a reference to one. Since your getting to the dirty point of binding even the sdk, I assume you would want to bind other physics classes like NxActor.
For that you could always bind addref and release methods as global dummy functions which do nothing... but then there is always the risk the NxActor is freed while a script still holds a reference to it. Unsafe indeed!

1. Static member functions are really just global functions declared in the namespace of the class. They should be registered as global functions.

2. I've yet to implement support for namespaces in AngelScript. It is on my to-do list though, and it has a rather high priority (though not the highest).

3. Assuming NxPhysicsSDK is meant to be used as a singleton, then IndependentHat's response is the recommended way. You may also want to take a look at Patrick Bowie's code for registering the PhysX math library with AngelScript (available on the wiki)

Thank you two for replying!:)

1. For example "static NxF32 NxMath::floor(NxF32)",Can I bind it to the namespace of the class NxMath?I really want to write "NxMath.floor(x);" instead of "NxMathfloor(x)".

3.I have downloaded the code of "NxMathAS_h",but the types binded to AS are all "asOBJ_VALUE|asOBJ_POD...",So what about types like "NxActor"?Should I bind dummy functions as said above and do the gc myself?

1. You can register it as an object method for the NxMath type. Example:

r = engine->RegisterObjectMethod("NxMath", "float floor(float)", asCALL_CDECL_OBJLAST); assert( r >= 0 );

You're then tricking AngelScript into treating it as a non-static class method, allowing you to call it with NxMath.floor(x). Given that NxMath is the name of the variable, and not the type.

However, do you really need the namespace for these functions? Why not just register it a global function with the name 'floor'? Are there really any risk for confusion if you do not use the namespace?



3. Since NxActor isn't using reference counting to perform the memory management, and instead relies on the application to perform the proper management, you'll have to decide on how you want to do that in your application.

The way I solve this in my own application is that I write a light wrapper for the objects I want to use in the scripts. The wrapper is reference counted, and holds a pointer to the real object (the NxActor in your case). If the wrapper's reference count reaches zero it will also release the real object. By keeping track of the wrapper for each true object, the application can also release the real object before all references to the wrapper has been released. The application must then tell the wrapper that the real object has been destroyed, so the wrapper can throw an error if any script tries to access it after that. The drawback to this is that you'll have to implement all the wrapper functions that you want to register.

Another possibility is to write the AddRef/Release behaviours to store the reference counter of the real object in a global map. This will allow you to register the NxActor methods directly with AngelScript without the need for wrappers, but one the other hand you have a performance hit with lookup in the map for each AddRef/Release calls.

You can also register the NxActor with asOBJ_REF | asOBJ_NOHANDLE, which will allow the scripts to interact with the object, but not declare any variables of the type. The application must then supply the reference to the object through a function or some property. This is probably the easiest way of doing it safely, but puts some restrictions on how the scripts can be written.

You should also evaluate if you really need to register the NxActor with AngelScript at all. Will the scripts really work directly with the PhysX API? Usually scripting is much higher level than that. This of course depends completely on your application and the intended skill set for the script writers.

1.thanks,sounds good to me.
3.thanks,I think I will choose "asOBJ_REF|asOBJ_NOHANDLE".

btw:I think it will be better if there is a FAQ for newcomers,for now most information I can get is from the Unit Test of AS.

something like
1.binding static member func
2.binding global func as member func
3.call back func
4.binding class as value
............... as reference
............... as singleton
....and so on

The manual is supposed to provide these answers.

However, I do recognize that it still needs to be improved quite a bit. I try to add more to the manual with each release, in time it will have all the info you might need.

I've made my basic part of project run by now.But I am confused by something :
1.In the test project I see this "engine->RegisterObjectBehaviour("Chars", asBEHAVE_ADDREF, "void f()", asFUNCTION(0), asCALL_GENERIC);"
So I thought "asFUNCTION(0)" is another way to tell AS to do nothing when AddRef.But when I copy this to my cpp,It reports "access memory 0x000000" at runtime,It spend me sometime to debug this;

2.Every time I bind a class as "asOBJ_REF",I have to add "AddRef","Release" method and a variable "int refcount" to the class.So I'm wondering why not use smart pointer to do this in AS?To automately handle the refcount?

Don't use the test project as a base for learning. What I do there is not always the correct way to do it, as I'm testing very specific things. When a function is registered with a null pointer, it is because the script will never be executed.

You can use smart pointers when registering your types if you wish. AngelScript however, cannot automatically do this because it would only take care of the objects that the script engine allocates, not the objects that the application allocates and then passes to the script engine, or vice versa.