Welcome to AngelCode.com. Here you'll find resources for game development and more.

The most popular visits here are to the following pages: AngelScript - a powerful and free scripting library, BMFont - a free bitmap font generator, or RefDB - a database of useful developer resources. But feel free to browse the site for more resources.

AngelCode.com is maintained by Andreas Jönsson since 2001. Please help the continued maintainance and further development of the resources here with a donation.

Latest updates

2017-12-16   AngelScript 2.32.0

A new version is out. The most significant changes in this version are:

Of course this release includes a long list of other smaller changes too. Please refer to the change list for the details.

2017-11-15   AngelScript WIP

I've changed how string literals are handled in the script engine. Now the compiler evaluates them at compile time and stores a pointer to the application native string type in the byte code. This avoids the need to create new instances of strings every time a script uses a string literal, which in turn translates to a performance improvement.

A new asIStringFactory interface is used to perform the compile time evaluation. This also allows the application to keep track of the used string literals, and store them in a common pool to reduce memory consumption for duplicate string literals. With the factory interface there is also no need for the script engine to keep an internal copy of the string literals thus reducing memory consumption even further.

Since the byte code now stores the pointer to the actual string object, the byte code instruction asBC_STR has no use anymore, and with that the restriction of a 2^16 maximum amount of string literals is eliminated.

Besides the above benefits I should also be able to take this a step further as the compiler now knows that the life time of a string literal is guaranteed, so it should take advantage of that and avoid making unnecessary copies when passing string literals to functions, etc. Though this improvement has not yet been implemented.

For existing scripts there shouldn't be any changes, except if the application currently registers the string factory to return a non-const string object instance. As the string literals are now evaluated at compile time it is no longer possible to have them treated as non-const, still I've made it so that the compiler can when needed implicitly convert to a non-const instance by making a local copy of the string literal at run-time.

As the changes have been quite extensive, I decided to make it possible to temporarily turn off these changes until all bugs have been rooted out. To turn off the changes look for the #define AS_NEWSTRING in angelscript.h and comment out that line. Before I make the official release (hopefully before the end of the year) I'll remove this option completely.

Let me know if you encounter any problems with this, so I can have it corrected before the official release.

New developer references

2017-08-06   Yobi3D

2017-06-21   AngelScript WIP

I've added support for type less anonymous initialization lists. Previously anonymous initialization lists could be used in expressions, but only by explicitly informing the type of the object that should be instantiated.

Now the compiler will determine the type based on what the initialization list is used for, e.g. if it is assigned to an array the compiler will initialize an array, if it is used as argument to a function expecting a dictionary the compiler will initialize a dictionary, etc.

Of course, if the compiler cannot determine the type, either because there are multiple possible options, or the destination is variable, then it is still necessary to explicitly inform the type.

void main()
  doSomethingWithADictionary({{'banana', 1}, {'apple', 2}, {'orange', 3}});

2017-05-09   AngelScript WIP

Development on AngelScript has not stopped, despite the long delay since last release. It is true that the amount of time that I have at my disposal to work on AngelScript has decreased a lot the last few years, but I am still continuing the work, just at a slower pace.

I'm not yet ready to release the next version, but I've just completed a new feature for the upcoming release: external shared entities.

External shared entities was a natural evolution of the existing feature. Before it was already possible to take advantage of previously build shared entities to avoid declaring the full entity again, but only by taking advantage of the knowledge that the compiler didn't actually validate the difference in the declaration.

With the new keyword 'external' a script that wants to use a shared entity that is known to have been built in another module, can now do this by simply adding the keyword 'external' before the declaration and skip the actual implementation of the entity.

This not only shortens the size of the script, but also reduces the compile time slightly. The saved bytecode is also reduced since it also takes advantage of the known existence of the shared entity.

Example syntax of external shared entities:

external shared class SomeClass;
external shared interface SomeInterface;
external shared enum SomeEnum;
external shared void SomeFunction();
external shared funcdef void SomeFuncdef();

I hope you like the update. I'll provide more updates as more features are completed. I'll abstain from telling what I'll work on next though, since I have a habit of changing my priorities based on user feedback.