I've heard a lot of people wax rhapsodic about LuaBind. LuaPlus may also be worth looking into. On the Python side, check out Boost::Python.

"Sneftel is correct, if rather vulgar." --Flarelocke

[edited by - sneftel on June 7, 2004 6:05:51 PM]

Others in this forum are saying that Small is very easy to embed.

Javascript || AngelScript

Embedding is generally down to creating interface functions/classes to sit between the script and the host application. It's not a trivial matter and requires a huge amount of design consideration early on in the project. You may benefit from writing your own base-class interface for your given script language.

[edited by - downgraded on June 8, 2004 12:35:41 PM]

Hi!, I know this is kinda offtopic...

I noticed that a big issue in choosing a scripting languaje is the embedding of native funcions inside the scripting languaje...

I''m currently developing a scripting library... I was not planning to release it... but reading the problems people is having, maybe I''ll change my mind.

Currently it is in a alpha state... quite experimental, a little buggy and totally undocumented... but without noticing, I''ve bumped in a embedding system I like a lot... it works pretty much like this:

- - - in the script:

extern int embeddedfunction (174) (int,int,int);

// after this, the funcion can be used normally

- - - in the C code:

external_callback(int func,stack* funcparams)
{
switch(func)
{
case 174: { do whatever you have to do here }
case 205: { another function }
case 666: { and another one... }
}
}

after having this funcion, you only have to do a single
call to register the callback with the script

- - - -

I don''t have too much experience with other scripting languajes (LUA, barely)... and I would like to know if this embedding method looks good... or there are other better methods...

Generally variables are get/set with a numbered callback function like yours - I've never seems functions registered like that. Whilst it seems ok, you will still need the proxy functions to turn your parameters into something usable by the 'real' function.

eg:

// native funcvoid player_trigger(int x, int y, int trigger){  // player triggers an event at pos x, y}external_callback(int func,stack* funcparams){switch(func){  case 100:    // need to get x, y and trigger from the params passed    // you may actually go funcparams[0]->toInt(), but you wouldn't want to put this in your game code, hence a proxy function is needed    proxy_player_jump(funcparams);  break;}}void proxy_player_jump(stack *funcparams){ // get x, y and trigger from funcparams // eg: - or however you'd get the variables yourself int x, y , trigger; x = (int)funcparams[0]; y = (int)funcparams[1]; trigger = (int)funcparams[2]; // then call the player_trigger function - you could have put this in your switch in the call back, but this makes it more understandable player_trigger(x, y, trigger);}

The problem is still actually getting the variables from the machine in the first place to be usable to your native code. With one or two functions this is fine, but when you get to huge portions of your code you start having to deal with maintaining both your code AND the proxy interface functions. It;'s these proxies that start becoming a pain in the ass, hence the auto-creation tools around

What I'm looking at now is using the inheritance of C++ classes and things such as Quake's CVar / Gaz Iqball (sp?) (on Flipcode) console tutorial to create a CVar style handler for any variable/class that is declared in code or in script.

[edited by - downgraded on June 8, 2004 1:56:51 PM]

you're right that passing the parameters is an issue... but, somewhat, I solved that too:

in my callback funcion, the *stack parameters is actually an array of arguments, the ones pushed by the virtual machine. Actually, these parameters are pased as an UNION, so, to call a funcion I don't need a proxy funcion, I simply do:

case 174:
{
return ( funcion(stack[0].ivalue,stack[1].ivalue,stack[2].fvalue) );

}

in this call, the funcion asks for two INTs and one FLOAT, I only need to pass the parameters directly, because the virtual machine pushes the values in the type requested by the funcion in the script definition.

quote: Original post by downgraded
Generally variables are get/set with a numbered callback function like yours - I've never seems functions registered like that. Whilst it seems ok, you will still need the proxy functions to turn your parameters into something usable by the 'real' function.


The problem is still actually getting the variables from the machine in the first place to be usable to your native code. With one or two functions this is fine, but when you get to huge portions of your code you start having to deal with maintaining both your code AND the proxy interface functions. It;'s these proxies that start becoming a pain in the ass, hence the auto-creation tools around

What I'm looking at now is using the inheritance of C++ classes and things such as Quake's CVar / Gaz Iqball (sp?) (on Flipcode) console tutorial to create a CVar style handler for any variable/class that is declared in code or in script.

[edited by - downgraded on June 8, 2004 1:56:51 PM]

[edited by - vicviper on June 8, 2004 4:04:32 PM]