Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 06:39 PM

#5069638 [AngelScript 2.26.3] Global property issues [Solved]

Posted by Andreas Jonsson on 13 June 2013 - 09:43 PM

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 = (GraphicsObject*)(topClothObject);
if( *adr )




#5064617 Initialization List

Posted by Andreas Jonsson on 24 May 2013 - 03:32 PM

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.

#5063999 AccessVersion

Posted by Andreas Jonsson on 22 May 2013 - 07:35 PM

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)

#5062710 Global Variable Initialization Context

Posted by Andreas Jonsson on 17 May 2013 - 07:35 PM

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();
module->ResetGlobalVars(ctx); // now the global variables will be initialized using the supplied context that has the desired user data




#5060456 AngelScript 2.26.3 is out

Posted by Andreas Jonsson on 08 May 2013 - 07:29 PM

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.




#5057502 passing class/function to asMETHOD

Posted by Andreas Jonsson on 28 April 2013 - 12:03 PM

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. 

#5057478 Why I can't register a method which recieved a script class sucessfully?

Posted by Andreas Jonsson on 28 April 2013 - 10:03 AM

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?

#5054750 Understanding some basics

Posted by Andreas Jonsson on 18 April 2013 - 06:51 PM

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.




#5052940 Idea for modification AS

Posted by Andreas Jonsson on 13 April 2013 - 04:00 PM

I've implemented this in revision 1617.




#5051357 Delegates are fully working now

Posted by Andreas Jonsson on 08 April 2013 - 06:21 PM

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 biggrin.png Back then the script language only supported 32bit int and float types ph34r.png




#5051313 Delegates are fully working now

Posted by Andreas Jonsson on 08 April 2013 - 04:02 PM

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.

#5050967 Delegates are fully working now

Posted by Andreas Jonsson on 07 April 2013 - 02:52 PM

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


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.





#5048658 AngelScript 2.26.2

Posted by Andreas Jonsson on 31 March 2013 - 01:28 PM

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.




#5045107 "Behaviour already registered" - troubles after upgrading

Posted by Andreas Jonsson on 20 March 2013 - 08:32 PM

This is a validation that was added recently. It is not a problem in AngelScript, unless you really aren't registering the same behaviour multiple times with the same signature like error says.

#5042425 asWRONG_CALLING_CONV when compiling on Ubuntu (written on Windows)

Posted by Andreas Jonsson on 12 March 2013 - 01:32 PM

Does your Script_engine::Calling_conventions::C_decl_obj_last actually match the value of asCALL_CDECL_OBJLAST?


Observe, the value of asCALL_CDECL_OBJLAST has changed in release 2.26.0 with the introduction of the new enum asCALL_THISCALL_ASGLOBAL.