I tested the code and it seems to work properly. I also think I understand why the global variables could be a problem. The following code won't work:

int* num = new num;engine->RegisterGlobalProperty("int num", num);

The only way I see this to be currently possible is the following:

int ptoi(int* num) return *num;...int* num = new num;engine->RegisterObjectType("intp", sizeof(int*), 0);engine->RegisterGlobalProperty("intp num", #);engine->RegisterGlobalFunction("int valueof(intp)", asFUNCTION(ptoi), asCALL_CDECL);

This isn't the cleanest approach, but it should work. There's probably some way to automate this, but I can't currently think of any. Maybe using a special function to register the pointer of a pointer?

Here's the code for my modifications, simply extract to the angelscript root dir: http://users.pandora.be/gyrbo-be/AS/AngelScript-bytecode.tar.bz2

You don't have to register a new type for int *, you can use it directly.

int *num = new int;
engine->RegisterGlobalProperty("int *num", #);


When I get the time I will make the necessary changes to make global properties to work with saved byte code. It should only be necessary to create a new bytecode with similar functionality as BC_PGA, and changed the compiler to output this one instead of BC_SET4 with the absolute address. This change will most likely work directly with your code changes.

I downloaded your file, but for some reason I couldn't unpack it.

Would it be possible for you to pack it as a normal .zip?

By the way, what's your full name? I would like to put your name as the author of modifications.

I also had some problems unpacking the file using powerarchiver, but 7-zip worked OK. I'm not sure what the problem was, but here's the zip: http://users.pandora.be/gyrbo-be/AS/AngelScript-bytecode.zip

Now I can also open it. Thanks. I took a quick look at the code and it looks good. It shouldn't be hard to maintain this code, so I'll probably include it with version 1.9.0. Until then I will upload it to the site for those that are interested in this functionality already.

Thanks for a great contribution to the library.

You didn't tell me your name. How would you like me to refer to you in the credits? Just Gyrbo?

Sorry forgot that (you can look up my name in the copyright of the files I added though ;)). My full name is on Dennis Bollyn.

Thanks, Dennis.

I've sent an e-mail to you about the copyright. There's something we need to clear up before I can put up the files on my site.

Yay!! to both of you, let's hope i can get it running on my code, Gybro thanks a lot for your additions to Angelscript.

I wonder if my earlier doubts are appropriate here, i was trying to create a script compiler which can run along side VC and compile the scripts before the host App has to actually run, just probably as a syntax checker. we can scout through the whole App project for RegisterGlobalFunction and get stuff out of them to see if the syntaxes are alriught before we can start the Host APP. could we build this up to a discussion?

Cheers!!!

A seperate compiler is a lot harder to make than a simply bytecode saver.

The only way I see this to be possible is if you have a sort of header file which the script compiler reads and uses to known which system functions and variables are available.
For functions, this is fairly trivial because an index is used. Variables are a bit harder. You would have to also use an index for them because I don't see any way how you could know the address beforehand.

I will change the way global properties are handled so that they also use indices. This should make it easier to use the feature Dennis added, and also to write a separate compiler. AngelScriptBind that Thomas Suter wrote might help you in writing the compiler.

There might be a problem in the way function IDs are handled as well. The function ID holds two components, the module index and function index in the module. When loading the bytecode into a module the function ID (for each of the BC_CALL) must be updated to reflect the true index of the module. I'll have to think about how to solve this in a good way. Of course if you always load the modules in the same order the indices will always be the same.