Andreas Jonsson

The latter description is the correct one. asUnprepareMultithread should be called after the last engine has been released.

 

It is not absolutely necessary that the calls are made from the main thread, but it is easier to guarantee the correct order of execution if it is done that way.

 

I'll update the manual to correct this. Thanks for bringing it to my attention.

 

Regards,

Andreas

The CScriptHandle is meant to be used as a value type, so you should preferably store the CScriptHandle member by value rather than by pointer. Like this:

 

class Obj{
  private:
    CScriptHandle m_Handle;
  public
    void SetScriptHandle(CScriptHandle &Handle){
      m_Handle = Handle;
    }

    CScriptHandle &GetScriptHandle(void){
      return m_Handle;
    }
};

//Registered like so:
ScriptEngine->RegisterObjectMethod("Obj", "void SetScriptHandle(const ref &in)", asMETHOD(Obj, SetScriptHandle), asCALL_THISCALL);
ScriptEngine->RegisterObjectMethod("Obj", "ref &GetScriptHandle()", asMETHOD(Obj, GetScriptHandle), asCALL_THISCALL);

 

 

In fact, you can expose the m_handle member directly as an object property, without the need for the Setter and Getter methods if you'd like:

 

ScriptEngine->RegistetObjectProperty("Obj", "ref @m_handle", asOFFSET(Obj, m_handle));

 

That would allow the script to manipulate it directly:

 

// AngelScript
class Data{
  int x;
};

void Func(Obj @A){
  Data @x = Data();
  x.x = 0;
  @A.m_handle = x;
  @x = cast<Data>(A.m_handle);
};

 

Regards,

Andreas

You can use the GetAddressOfGlobalVar() to inspect and modify the global variables like you found out. Just make sure you update the reference counters of the objects correctly.

 

int index = mod->GetGlobalVarIndexByName("topCloth");
GraphicsObject** adr = ((GraphicsObject**)mod->GetAddressOfGlobalVar(index));
if( *adr )
 (*adr)->Release();
*adr = (GraphicsObject*)(topClothObject);
if( *adr )
 (*adr)->AddRef();

 

Regards,

Andreas

I definitely plan to allow arbitrary objects to be initialized through initialization lists. It's not a trivial thing to implement though, and I currently have no estimate when I'll get to this.

I want to allow the application to register the different patterns that the initialization list must follow, so that the compiler can do most of the validation rather than the object doing it at run-time. E.g the Matrix class could be registered as taking only initialization lists with 4 float values, and the dictionary class can be registered to take lists with even number of values, and all even values must be of string type.

There are a lot of more things to think about. For example, the matrix type should preferably receive a pointer to the memory buffer rather than the index operator being called 4 times to set each element. The dictionary class on the other hand should receive each key/value pair together in the same call.

I'll think about this suggestion of having a version alongside the access mask.

 

With the current implementation I believe I would solve your dilemma the following way:

 

1. Set up a main script engine with the full interface, i.e. with the latest version. This will be the script engine used for all script execution, but it will not be used for compiling scripts. Instead the scripts will be loaded from pre-compiled bytecode into this engine.

 

2. When compiling a script for a specific version, set up a separate engine with only the interface available for that particular version. Compile the script, then save the bytecode to memory, and finally load the bytecode into the main script engine where it will be executed.

 

Assuming each version only adds to the interface and never removes anything this will work well. You shouldn't see a noticeable delay with the saving and loading of the bytecode either as this is much much faster than the actual compilation.

 

The separate engine doesn't need to have access to the actual interface methods as it will never call them, so you'll be able to register this interface with dummy functions. You can even perform the compilation to bytecode in an offline compiler that can be completely separate from the rest of the game engine.

 

I suggest you take a look at the sample asbuild. It implements a generic offline compiler that can compile scripts for any application, assuming the interface is known in the form of a configuration file. (The configuration file can be created automatically from the application with a call to the helper function WriteConfigToFile)

You'll want to turn off the initialization of the global variables upon build, and then supply your own context when manually initalizing them.

 

engine->SetEngineProperty(asEP_INIT_GLOBAL_VARS_AFTER_BUILD, false);
....
module->Build(); // now the global variables won't be initialized
 
// Manually initialize the variables after the script has successfully completed the build
asIScriptContext *ctx = engine->CreateContext();
ctx->SetUserData(myUserData);
module->ResetGlobalVars(ctx); // now the global variables will be initialized using the supplied context that has the desired user data
ctx->Release();

 

Regards,

Andreas

In this release I've implemented support for delegates, which is an extension of the previously available function handles. With delegates it is now possible to pass class methods as callbacks where an ordinary function handle is expected.

 

I've also finally taken the time to implement recursive search for symbols in parent namespaces. This should make the namespace feature much easier to use as you'll no longer have to prefix all the global symbols when compiling a function in a namespace.

 

The engine has a new property to allow an application to disable support for value assignments for reference types. While this may sound like a something bad, it is actually making the language less ambiguous when dealing with reference types. Too often do script writers make a value assignment when they actually intended to make a handle assignment.

 

The script builder add-on now also have methods to enumerate the script sections that were included in a module. This is an useful feature when caching the compiled bytecode, as you'll now know which files to check for updates in.

 

And finally I added a couple of add-on functions for doing a direct conversion from float to int, called fpToIEEE and fpFromIEEE. These are meant to be platform agnostic so they'll work even if the CPU where the script is running isn't using the IEEE standard natively to represent floating point values.

 

Regards,

Andreas

asSFuncPtr and asMethodPtr are implemented in angelscript.h. The asMETHOD method instanciates the asMethodPtr template structure, and then call the method Convert() to return an asSFuncPtr.

 

I can understand you want to wrap the AngelScript library, but there is really no need to reimplement the code. Just take the code from angelscript.h and rename it to your liking rather than trying to implement it from zero. 

Actually, it is not so strange. The types declared in the script modules are in a different scope than the engine registered functions and classes. That is why even though you have compiled a script the types from that script cannot be used when registering engine functions. 

 

The reason for this is that multiple modules can declare the types with the same names without conflict. Modules can also be recompiled or removed dynamically. So if a registered function refer to any of those types, what would happen then?

Reference types are those that are allocated on the memory heap rather than on the stack. Basically you'll want to use reference types for any type that should be able to outlive the scope in which it is created. On the other hand value types are those that will be allocated on the stack (or as local members of other objects). As these types can't outlive the scope in which they are created they should be used for those types that are used for quick calculations and can then be discarded. Also, for value types you'll want to keep the size and complexity down to a minimum. If the type is large or complex it is an indicator that the type should probably be a reference type.

 

C++ pointer arrays unfortunately have no match in AngelScript, so the recommended way of handling them is by wrapping the function to copy the content to a CScriptArray (see the add-ons).

 

C++ templated types are determined at compile type. You'll need to register the template function for each combination of return type and parameter types you expect the scripts to use.

 

Regards,

Andreas

I've implemented this in revision 1617.

 

Regards,

Andreas

I've checked in the fix in revision 1614.

 

I'm glad you like the new features. I'm always trying to improve the library. 

 

By the way, it's now officially 10 years since the first public release of AngelScript  Back then the script language only supported 32bit int and float types 

 

Regards,

Andreas

The fix is simple. The if condition on line 8122 needs to check if bestMethod is not null before checking if the constness is correct. I'll have the check-in done as soon as I get home.

I've just checked in the last changes to get delegates fully working in the AngelScript library. 

 

If you're interested in trying it out, then you'll need to download revision 1613 from the SVN. 

 

The solution builds upon the existing function pointers in AngelScript, and the syntax for creating delegates is similar to C#'s delegates.

 

 

class Foo
{
  void Bar() { counter++; }
  void counter = 0;
}
 
 
// Declare a funcdef, which is basically the desired signature for the delegates
funcdef void CALLBACK();
 
void main()
{
  Foo f;
 
  // Create the delegate as a construct call for the funcdef
  // Observe that the single argument gives the object reference and the name of the method
  CALLBACK @callback = CALLBACK(f.Bar);
 
  // Invoke the callback like a normal function
  callback();
}

 

The delegate is an actual object instance, which is slightly different from function pointers to global functions that doesn't create any new object instances. Even so delegates and function pointers are interchangeable as long as the function signature is identical.

 

Delegates cannot be created for value types as the delegate need to be able to hold on to a reference to the object. Currently it is not possible to create delegates for global functions either, but I'll probably have that implemented in the near future.

 

 

 

I hope you like the new enhancement. And please let me know if you find any problems with the implementation, so I can preferably have them fixed before the next release.

 

 

Regards,

Andreas

This is a rather small release. I have been a bit wary about making bigger changes in the library the last few weeks because of the many bug reports that I had been receiving. While it's true that no software is never free of bugs, it's also not very pleasant when the number of reports coming in seems to be more than you can handle.

Luckily, it seems I've managed to get passed this phase as it's been quite a while since I've received any new valid bug reports and all the known bugs have been fixed. So I'm now ready to get started on new features again.

 

As a result of this phase this new release should be one of the best releases ever, with the least amount of bugs to trouble the users.

 

Even though the most of my time was spent on bug fixes, some new changes made it in. Probably the most notable addition is the new GetTypeTraits helper function. This is an add-on function that takes advantage of C++11 features to automatically determine the correct flags to use when registering a value type with the application. Thanks goes to Heuristics for contributing the initial implementation.

 

Another minor change is the ability to turn off compiler warnings by setting the engine property asEP_COMPILER_WARNINGS to false. It also possible to make the compiler treat warnings as errors, if so should be desired.

 

Regards,

Andreas