I have a method that looks like this:

CTexture* GetTexture()
{

..
}

so would I register the method as:

"CTexture@ GetTexture()"

by the way, how does AngelScript's performance compare? Would you recommend AngelScript to control frame-by-frame animation? I tried blitting a simple white square from AngelScript and I could see it flickering. Another question: In an initialization function, I prepared a function, executed that function, but it only worked for one frame. Subsequent calls of the function would not work. Is this deliberate or through a fault of my own? For some reason it doesn't seem to work.

You may register your function with "CTexture@ GetTexture()" as long as the CTexture has the asBEHAVE_ADDREF and asBEHAVE_RELEASE behaviours registered. Your function should also make sure to increase the reference count for the returned pointer.

CTexture *GetTexture(){  ...  // Increase the reference count for the returned pointer  texture->AddRef();  return texture;}

The performance of AngelScript is good. I have exact values, but I know it is comparable to other popular scripting languages such as Lua. In some situations it might be faster, in others it might be slower. Still, AngelScript will become even faster with the coming releases as I've identified several pieces of codes that I can optimize.

AngelScript is very well suited for frame-by-frame animation. BeatHarness uses AngelScript to script the visualization effects. I believe it calls AngelScript for each scanline which makes for at least 768 calls per frame. And the framerate is still very impressive. Raptor Entertainment uses AngelScript for controlling just about everything in their game, including AI, scripted events, GUI, etc.

The flickering is probably because you're not using double buffering, and not because you're using AngelScript. Still, I hope you are not implementing the actual pixel copy in the script. The blit function should be implemented in C++ (or even better, the hardware) and AngelScript should simply call that function.

If your function worked the first time, but not the subsequent times, then I believe you didn't prepare the context between each call. If you intend to call the same function repeatedly you could do it like this:

(pseudo code)

engine->CreateContext(&ctx);ctx->Prepare(engine->GetFunctionIDByDecl(...));for(;;){  ctx->Execute();  if( break-condition )    break;  // Prepare the same function again  ctx->Prepare(-1); }

Oh thanks.

As for the flickering, well I'm using DirectX so it's hardware. Basically I wanted to test out your AngelScript by registering a function from the host code that drew a simple white square, and called it repeatedly from AngelScript:

//C++ codevoid DrawWhiteSquare(){DrawQuad(...);}m_pEngine->RegisterGlobalFunction(...);//main loopfor ( ; ; )    ctx->Execute();

//angelscriptvoid DoSomething(){   DrawWhiteSquare();}

I'll look back into it though.

Thanks a lot WitchLord. I like your AngelScript better than Lua because it's more C [grin].

Cipher3D

Quote:Original post by WitchLord
AngelScript is very well suited for frame-by-frame animation. BeatHarness uses AngelScript to script the visualization effects. I believe it calls AngelScript for each scanline which makes for at least 768 calls per frame. And the framerate is still very impressive.

offtopic : not per scanline, but I call a scripted function for each vertex of a grid of 32x24 vertices - indeed 768 times per frame :)

And an update :
I'm in the process of making BH a standalone app instead of a winamp-plugin,
and I've switched to Visual Studio 2003.
Thus I am using all it's nifty new optimization features :)

Result :
Stuff that used to run at 90FPS now runs at 270FPS.

Hooray for AngelScript & compiler optimizations ! :)

Well, it sure makes more sense to call the script per grid square, than per scanline. My mistake. :)

You've got some impressive performance improvement there.

I just read the article "The implementation of Lua 5.0" and it gave me some ideas on how to optimize AngelScript even further, which should hopefully increase your performance even more. I'm talking about using a register based VM instead of a stack based VM, that AS currently uses. Though I will probably only start implementing these ideas closer to May/June.

Regards,
Andreas