Advertisement

AngelScript 2.22.2 is released

Started by January 29, 2012 06:15 PM
5 comments, last by 3kimr 12 years, 10 months ago
[color=#000000][font=Arial]


This new version brings a couple of enhancements to the script language: shared global functions and namespaces. The shared global functions is a continuation on the shared feature from version 2.22.0.[/font]
[color=#000000][font=Arial]


The namespaces is a new feature in the language, which is based on the C++ namespace feature. It is still in its initial stages, so some things you can do in C++ is still not available in AngelScript, e.g. 'using namespace'. Also, the application interface has not yet been changed, so the application doesn't really have all the methods necessary to interact with namespaces.[/font]
[color=#000000][font=Arial]


I've also made some internal improvements in the library. Mainly with the goal of finally making the pre-compiled bytecode fully platform independent. I've implemented some new bytecode instructions that are exclusively for manipulating pointers, and with this some older bytecode instructions have also been removed as they ended up no longer being used.[/font]
[color=#000000][font=Arial]


For the next version I plan on implementing the interface changes necessary for interacting with namespaces. I also plan to continue working on making the pre-compiled bytecode platform independent. I specifically want to focus on removing the dependency on the CPU pointer size, which is one of the few last obstacles to gaining full independence.[/font]
[color=#000000][font=Arial]


Another thing I'll implement for the next version is the option to compile the library without the script compiler. By not including the compiler the applications that only rely on pre-compiled bytecode should be able to reduce the executable size quite a bit.[/font]
[color=#000000][font=Arial]


Regards,[/font][color=#000000][font=Arial]


Andreas[/font]

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

When will we be hopefully seeing the ability to just let the scripting engine hold a reference to an object, but not refcount it? Such as a smart pointer.
Advertisement
You can register a smart pointer as a value type. Alternately, you can register a type with empty addref and release behaviors and without a factory function if you want to have a reference type that will be created and managed outside the script engine. See also single reference types in the documentation.
Duh! I never thought to leave addref/release empty. Single reference types won't work as it is for our entities. Passing by value would be large memory copy (potentially), so I figured a smart pointer would be best then just get the handle to it inside angelscript. Would you recommend the value type smart pointer, or the empty addref/release?
So happy to see namespaces implemented. Now I can cut it out with the crazy hacks to organize global script objects.

As for the interface, what is it you had in mind? Because a change like this could potentially break alot of existing code. However, something like a modal interface could work.

engine->SetNamespace( "Herp" );
engine->RegisterGlobalProperty( "Derp@ FooDerp",fooderp_pointer ); // Becomes Herp::FooDerp
engine->SetNamespace(); // Leave blank to go back to the global namespace.
Rantings, ravings, and occasional insight from your typical code-monkey: http://angryprogrammingprimate.blogspot.com/
adam4813:

I plan on adding an option for application managed references in the next release. virious already contributed an implementation towards this and I'll integrate and test it.

Personally I cannot really recommend this as I see it as a potential memory leak issue, or worse, adding risks for dangling pointer problems. Still, I won't let my personal opinions get in the way here, as I know a lot of people want to simply allow the script to access a pointer with no extra fuzz.

Between using smartpointers and empty addref/release behaviours, I'd use the latter as it is much, much easier to implement, and they will behave pretty much identically to the application managed references.

ekimr:

My intention for the interface changes is similar to what you suggested. I definitely do not want the introduction of namespaces to break current implementations.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement
W00t, nested namespaces work as well!!!

namespace R {
namespace Images {
Resource_Image@ MainMenu = Resource_Image( "Resources/Images/MainMenu.png","MainMenu",512,512);
Resource_Image@ Groucho = Resource_Image( "Resources/Images/groucho-fire.jpg","Groucho",500,340);
} // namespace Images
namespace Spritesheets {
Resource_Spritesheet@ Character = Resource_Spritesheet( "Resources/Spritesheets/Character.json","Character");
} // namespace Spritesheets
namespace Fonts {
Resource_Font@ Console = Resource_Font( "Resources/Fonts/Inconsolata.otf","Console");
} // namespace Fonts
} // Namespace R


I love code generation. =)
Rantings, ravings, and occasional insight from your typical code-monkey: http://angryprogrammingprimate.blogspot.com/

This topic is closed to new replies.

Advertisement