Yeah, docs are not my strong point. The latest release has some examples in the source code on how to use the library with some comments and there is a function reference in the docs, but the docs aren't what i could call 'good'.

Calling C functions from scripts requires functions to be registered fist using the addNativeFunc

addNativeFunc("<function name>", <functionInC>, <argCount>);

the C function must have a special format:

long functionInC(pNBScript script)

and must "pop" the arguments from the argument list in reverse order using the popArgument(script) function.

Calling script functions from the host program is more difficult. The script is compiled to a virtual machine an the compiler can be removed from the library (using a #define) in order to save space (for embedded applications - say Gameboy - for example). There is a function called callScriptFunction which takes an address in the bytecode space. In order to know the address, it must be given somehow from the script, for example by registering a native function like "setEventHandler" that takes two arguments like:

function onTalk()
{
print("hi!");
}

setEventHandler("on talk", onTalk);

that passes the address of onTalk in bytecode space to the native function. Then the host program could save somewhere the address and use it for calling the "onTalk" function when required to handle the "on talk" event.

I could write a mechanism to "export" some functions like

export function onTalk() ...

and build a table with these but somehow i believe that it's better to use the previous approach since it brings bigger flexibility.


[edited by - badsector on May 23, 2004 3:46:15 PM]

Try looking at how Small does it. It has a really nice embedding system. Also, how do you pass strings and arrays in/from the script to C? By reference, or you just push/pop all the elements from the stack?

Even if you don''t include the full source, there will be walkthroughs of your game in a few weeks and in a few months there will be a script decompiler. Including the source in an adventure game or RPG just means those technically inclined can find the secrets a few days earlier and that they have MANY thoroughly tested(presumably you test the game) examples to draw from when trying to extend and improve your game.

@Raduprv:
Just like this: :-)

char *myString = (char*)popArgument(script);

strings in NerveBreak are simple pointers to memory just like in C. NB has a bit of string manipulations (f.e. adding strings with the $ operator and comparing strings with the $= operator). The garbage collector is responsible for keeping things low.

I find my implementation to be very easy to use (even if 1-2 helper functions would not harm), at least for me (i''m my primary target anyway :-). I''ll look how SMALL does it, but i don''t believe that it''ll make me change my embedding mechanism, except if it is extraordinary simple and easy :-).

Arrays are still not supported in NerveBreak (it''s a planning feature for 0.1.5), however as i''m planning it it will also be like:

long *myArray = (long*)popArgument(script);

Yes i''m working alot with pointers in NB - actually everything, except integer values, are pointers :-). This has pros and cons. One of the pros is that it''s fast and easy (at least i assume so). One of the cons is that it''s easy to GPF your program, like the script below:

notAString = 1;
print("notAString = " $ notAString $ "\n");

Can your VM access stuff outside the VM? Like giving it a pointer that is a memory in the host code, but outside the VM specific memory?

Somehow, but it happens only for strings (strings are actually pointers to host memory space) and for objects (objects are allocated to host memory space).

You can allocate memory in host''s side and return it using a native function. NerveBreak won''t know how to handle it, but it can use it for passing it to other native (and not-native) functions.

It can''t access host variables directly. You need to define "get" and "set" functions like:

health = getHealth("player");modifyHealth = false;if (hitPowerup("player")){        health = health+10;        modifyHealth = true;}if (hitMonster("player")){        health = health-5;        modifyHealth = true;}if (modifyHealth)        setHealth("player", health); 

quote:
Honda Civics are better cars than Ferrari Enzos, which is proved by the vast number of numbers that drive them. Popularity != Quality.

Civics are generally regarded as some of the most reliable cars around. Faulty logic. High Price != Quality.

PHP is a good language for making web applications. Is it a good general purpose scripting language? Not particularly, no, but compared to the competition (read: ASP), it''s a sound alternative.

There are reasons why things become popular: Because they make the most sense to use for the most people.

Why do most people use Windows? Because they know how to use it, and they don''t have to worry about trying to find out how to do something with it one day and can''t find anyone that knows how.

Why do most people drive economy cars? Because they''re cheap, efficient, reliable, and can easily be fixed by any mechanic.

Why do most people in the U.S. speak English? Because it would be extremely difficult to communicate in a language that nobody else understands.

Simple.

And it has *NOTHING* to do with the original post.

I think people misunderstand Python. IMHO, there are two problems with the language: first, the system comes "batteries included" with such powerful structures that you could write the dirtiest malware ever in it. Second - yes, its slow.

I think a stripped-down Python would be a very good language, as I find it syntactically the nicest language to work with - its like legible LISP! C-based languages I find very limiting, as they miss features that lisp-based languages have. Python gets a "best of both worlds, with new stuff" approach. It is legible and self-documenting, has full OOP, and Lisp-style closures. Unfortunately, it has the aforementioned catches.

My hope is that people will make a separate fork of Python for embedding. Rip out all the core libraries (including file access - file access is risky), optimize the interpreter for speed (for example, right now the string hashing that is used for _everything_ is optimized for sorting, not accessing). Module strings or bytecode objects would be fed in by the embedding program, rather than through unsafe file access. Then you''d have a properly insulated language. Then developers could code whatever modules or custom datatypes they need to set up a nice platform.

But as it stands, Python requires a painful amount of work to be a good embedding platform.

Keep in mind that the Python C bindings go beyond simple importing of code hooks for modules - Python''s C-based custom datatypes are spectacularly powerful.

I find it surprising that people don''t like Python''s syntax. The tab-based blocking is wonderful, the standard objects and aggregates are perfect, and the argument-passing syntax makes many others look very clunky. I do have my problems with it though, like C-style equality/assignment (I prefer Pascal := assignment) and an inability to define immediates and aggregates for custom object types - you have to use standard constructors like most languages. That and the globals seem flaky to me.

Tab based blocking might seem nice, but if you have code with loads of fors and ifs, you might have to horisontally scroll 3 pages, which is not nice..

I don''t think that''s ever likely to happen unless you use 8-space tabs or like to code at the 80x25 console.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]