Andreas Jonsson

Unfortunately not. The best that can be done at the moment is to provide a method to explicitly return the inner node.

I'll study the case and see what I can implement to support implicit cast operators in the script language.

Thanks for the report.

The identity operator is indeed not meant to be used with enums. It should only be available for reference types and handles.

I'll have this fixed.

I've released yet another update to the AngelScript library. The major enhancement with this release is the improvement to the way the bytecode is saved.

With the changes I made in this release to abstract the pointer size the bytecode is now almost 100% platform independent, and should cover all modern platforms including computers, consoles, and mobile devices. The only things that prevent me from saying the code is 100% platform independent are 2 things; 1) that bit representation for float values is left as-is, so a CPU that doesn't use IEEE 754 will get the wrong value when reading bytecode saved on a PC, 2) that the size and value of the boolean type is left as-is, e.g. older Mac's on PPC used 4 bytes for the boolean type.

With the saved bytecode being platform independent many applications will not need to compile any scripts, so with this I added the preprocessor define AS_NO_COMPILER that can be used to remove all the code related to the compiler from the library. This can reduce the size of the executable quite a bit, so if size is important to you this will hopefully be a welcome change.

Another change that many has asked for is a way to register reference types that doesn't use reference counting. It was possible before by registering dummy functions for the ADDREF and RELEASE behaviours, but now the new flag asOBJ_NOCOUNT can be used instead so the dummy functions won't be needed anymore.

As I do with every new *.0 release, I've done some changes to the library interface. For the most part it is just to add proper methods for using the namespace feature I implemented in the last release, but there may be a few methods that needs to be adapted when upgrading to this version, most notably the GetExceptionFunction() and NotifyGarbageCollectorOfNewObject() methods.

The add-ons have also received a few improvements. I've implemented string pooling for the string type, which should improve the performance for scripts that use a lot of strings. I also added the method getKeys() to the dictionary object.
SiCrane implemented a new autowrapper system that eliminates the separate declaration of the function wrapper and the registration of it with AngelScript. The new macros are almost identical to the asFUNCTION and asMETHOD macros used to get the address of functions and class methods, so it becomes just as easy to use the generic calling convention as the native calling convention.

On the script language front, very little changed in this version. The only change is that enums can now be declared as 'shared' too.

With 'whole program optimizations' I can imagine it would take longer because I believe in this mode the linker goes through the entire program to see if it can make further optimizations with inlining etc that couldn't be done by the compiler.

Without it I really don't see why the link time is increasing in Release mode.

I don't have MSVC10, but I never noticed any extraordinarily long link time in MSVC8 or earlier versions.


It is almost certainly some project settings that is causing the extra delay. Perhaps you can try recreating the AngelScript project from zero instead of using the ones from the SDK? It's very easy. Simply create a new library project and add all the cpp source files.

The game sample shows how to integrate the script engine similarly to how you want.

Let me try to clarify some of the doubts you have:

- You'll use a single script engine. It is possible to use multiple engines, but there are only disadvantages with that. (At least I can't think of any advantages at this moment)
- The application must register all functions and types that the scripts should be able to access in the application. If you wish to provide different functions and/or types to different script modules, for example if you have scripts controlling the GUI too. Then you can use access masks to control which module should be able to access which function.
- You'll have one module for each entity type, i.e. all zombie type entities will share a single module, and the player type will use another module, etc. The script code and global variables in the module will be shared between the entities (could be useful for collective behaviours).
- Each entity should have it's on script class which is instantiated from the entity type's module. The script class holds the class members with the information that only that specific entity has access to.
- The IController interface is registered by the application with RegisterInterface("IController"); The interface could be used to force the script class to implement specific methods, but in the game sample it is only used to facilitate identifying the script class that is supposed to control the entity. You don't have to use this if you don't want. Your XML file with the entity configuration could for example provide the name of the class directly instead.

I hope this clears up some of your doubts.

Regards,
Andreas

You must use the wrappers from the as_smart_ptr_wrapper.h when registering the functions. Otherwise you're registering the actual class methods, but AngelScript doesn't have the actual object pointer, so when the methods are called you're likely to have memory invasions, crashes, and other nasty problems.

Thanks for alerting me on the package I uploaded. I'll update it with the fixes. I also noticed I put the wrong code in the as_smart_ptr_wrapper.h so that needs to be fixed too.

The error message

Can't return type 'vec' by value unless the application type is informed in the registration

is because AngelScript doesn't have enough information about the type to know how it is treated in the native calling convention in order to return it by value.

Did you add the asOBJ_APP_CLASS_C flag that I mentioned in the last post? That is what AngelScript needs.

What platform are you using anyway? Is it 64bit Linux or Mac with gnuc/clang compiler? If it is then you'll also need to add the asOBJ_APP_CLASS_ALLFLOATS flag to let AngelScript know the vec type is composed of only floats. If you're not using 64bit Linux or Mac then you may still add the flag, but it is not needed as it doesn't make a difference what the class is composed of.

How to register a value type and what flags is described in the manual.

Manual: Registering a value type

Please let me know if the above article is not clear enough and I'll do my best to improve it.



Returning a reference to a local variable is not something you want to do. While it compiles it will most likely not give the result you want in all cases. If you need to return a reference to a new value, then store the value in a static variable and return the reference to that value. At least that way you're guaranteed the value will still be there when the caller uses the reference.

Regards,
Andreas

Thanks. I'll make this change in the SDK, though the as_config.h is not necessary and is only meant for internal use in the as core.

Instead

#if _XBOX_VER >= 200 

can be used.

The tricky part is when you say the script must not store the pointer where it might survive beyond the call.

The only way this can be prevented is to disallow the script to store the pointer at all. The easiest way of doing it is to use the NOHANDLE flag when registering the type, then the script will only be able to access a reference given by the app but not pass it to around.

Another option could be to register the type as ordinary REF, but then add extra validation on the compilation to deny the scripts from declaring global variables or class members of that type.

I could add a flag to have the compiler verify this automatically, but I'm not sure how useful it is. Even without the flag it can quite easily be validated from the application after the compilation by enumerating class members and global variables.

Does that help?

The gnuc makefile (/angelscript/projects/gnuc/) has been prepared for compiling the library for iphone. It's been a while though, so I'm not sure if it works as-is with the latest ios sdk. Please let me know if any adjustments are needed.

I'd very much like to have an updated xcode project prepared for ios target to include in the SDK too. So if anyone wants to send it to me I'd appreciate it.

Ah, thanks. I'll have this fixed.

That's correct. If you don't register the factory behaviour the script cannot instanciate the type. An by registering the type as NOHANDLE you tell the script engine that it shouldn't allow any extra handles to it either, thus only the references you supply to the object will be accessible.

It's not yet possible to call global functions (or static methods) as if they are in the name space of the class. Once I get to implement support for namespaces, this should be possible to support too.

You can trick AngelScript though, by registering the static method with CDECL_OBJLAST. AngelScript will pass the object pointer to the static method as the last argument, but as the calling convention is CDECL the function will simply ignore it. This would allow you to do something like this:

engine->RegisterObjectType("CGameMgr_t", 0, asOBJ_REF | asOBJ_HANDLE);
engine->RegisterObjectMethod("CGameMgr_t", "void StaticMethod()", asFUNCTION(CGameMgr::StaticMethod), asCALL_CDECL_OBJLAST);
engine->RegisterGlobalProperty("CGameMgr_t CGameMgr", (void*)gameMgr);

With this the static method can be called, almost as if it was a normal static method:

CGameMgr.StaticMethod();

I truly appreciate the initiative

However, I do see one problem with this. I have a full time job which I can't just quit, no matter how well this fund raising may work (unless maybe if the fund raising goes up to 6 figure amounts ;). Donations are good and very welcome, but they cannot substitute a monthly paycheck.

Without quitting the job I highly doubt I would be able to make up for any expectations that would come out of any fund raising like this. The people who make donations today do it as thanks for what I've already done, but the people who would donate to a fund raising initiative like this would expect something in return.

It is different for the guys at wikipedia and disapora, because they are already working full-time on their project, and the fund raising will allow them to continue doing so.


On the other hand, if someone would like to pay to have a specific feature implemented as top priority I'm more than willing to negotiate.

Regards,
Andreas

This version brings a long list of smaller enhancements, including:

• User data in asIObjectType and asIScriptModule, that can be used for holding function pointer caches
• The asIScriptContext::Prepare method can now take the asIScriptFunction pointer rather than the function id
• Added functions to make it slightly easier to get the asIScriptFunction pointers
• Application can now define the modules' access to individual registered entities through bitmasks, rather than on the configuration group level
• Added methods to the asIObjectType interface to make it easier to determine relationship between types
• AddRefScriptObject and ReleaseScriptObject can now take a pointer to the asIObjectType instead of the type id
• Made improvements to the interface to aid JIT compilation
• Implemented shared script classes, i.e. classes can now be declared as 'shared' which will allow multiple modules to share the same implementation thus simplifying how objects can be passed between modules

Most of the changes are just incremental improvements, the real exciting new feature is the shared script classes.

Previously it was a bit complicated to have two or more modules communicate with each other, due to the inability to share types. The modules could only use the types that had already been registered by the application when passing data back and forth. Now, with the shared classes, the modules can implement common classes with data and methods to simplify this. Shared classes is just the beginning, I plan to expand this feature to global functions and properties too.

Regards,
Andreas

If your application is managing the memory and you've registered the addref/release behaviours as dummy functions, then there is no need to call them.

The garbage collector won't be impacted by the fact that you've implemented the addref/release behaviours as dummies.


The fundamental difference betwen reference types and value types is: Reference types are allocated on the heap, and allow handles. Value types are allocated on the stack, and do not allow handles.

Value types can be passed by value to functions, though in the case of std::string it's a good idea to make the parameters as references in C++ to avoid unnecessary copies of the internal buffer.

References returned from a function refer to the actual object. No copies are made, so you can make a call or access members of the object correctly. However, you will not be able to forward or store that reference (unless the reference is to a reference type).


Regards,
Andreas