Four ways to link a list (a performance test on linked list architectures)

In looking at entity systems for Flash games, and particularly the projects Ember and Xember, I was wondering what is the most efficient architecture for the linked lists used by these systems. So I ran some tests.

The code for these tests is all available on Github.

The lists in these frameworks are used to manage the component sets for the systems that run the game. These lists need to provide three functions – add an item, remove an item, and loop through all the items, and they need to do this as efficiently as possible.

So I created four different architectures for linked lists and ran a few performance tests. Continue reading

Bugs in Vector3D and Matrix3D

This is part 4 of a 4 part series comparing Coral, a derivative of the 3D math classes that used to be in the Flint Particles project, and Flash’s native 3D math classes.

In the first post I introduced Coral, explaining what it is and why I’m releasing it as an open source project. The next post looked at the key architectural differences between Coral and the native Vector3D and Matrix3D classes. The third post compared the performance of Coral and the native 3D math classes. This last post is about bugs. Continue reading

Performance of Coral vs Vector3D and Matrix3D

This is part 3 of a 4 part series comparing Coral, a derivative of the 3D math classes that used to be in the Flint Particles project, and Flash’s native 3D math classes.

In the first post I introduced Coral, explaining what it is and why I’m releasing it as an open source project. The next post looked at the key architectural differences between Coral and the native Vector3D and Matrix3D classes. In a later post I will show you the bugs I discovered in the native 3D math classes. This post is about performance. Continue reading

Architecture of Coral vs Vector3D and Matrix3D

This is part 2 of a 4 part series comparing Coral, a derivative of the 3D math classes that used to be in the Flint Particles project, and Flash’s native 3D math classes.

In the first post I introduced Coral, explaining what it is and why I’m releasing it as an open source project. In later posts I will compare the performance of Coral with the native Vector3D & Matrix3D classes and will discuss the bugs I discovered in the native 3D math classes.

In this post I will look at the key architectural differences between Coral and the native Vector3D and Matrix3D classes. Code architecture is an important area to me. I find well architected code is much easier to use, leading to more rapid development and fewer bugs. So good architecture in core classes like Vector3D and Matrix3D can make a lot of difference to developers. Continue reading

Introducing Coral, an Actionscript library for 3D Math

The experience of Flint

I started work on Flint Particles before Flash 10 was launched, so back then I created my own 3D mathematics classes for Flint. At the time this was not unusual – Away3D and Papervision3D had their own Number3D and Matrix3D classes, for example.

Since the release of Flash 10, open-source projects have gradually switched to use the native Vector3D and Matrix3D classes found in the flash.geom package and recently I decided it was time for Flint to also make this change, hence the release of Flint 3.0 a few weeks ago which uses those native 3D math classes.

Converting Flint to use the native classes was an interesting experience. For one thing, I think the architecture of Flint’s classes was better than the native classes. That wasn’t sufficient reason to stick with Flint’s own classes; using it’s own 3D math classes was a barrier to entry for users who were familiar with the native classes and resulted in many questions from confused new users. (For much the same reason, I don’t use the excellent As3-Signals library by Robert Penner in Flint, even though I use it in all my other work.)

So I set about converting Flint to use the native 3D classes. The initial conversion was mostly straightforward, only complicated by a lack of functionality in the native classes that sometimes meant one line of code using Flint’s classes had to be replaced with 3 or 4 lines of code using the native classes.

Having made the change, however, I was surprised to find two significant issues with the new code. The first was a couple of bugs in the native classes, which were not too serious since I could find a way to work around them. The second, and far more troubling issue, was a very large drop in performance – the code using the native 3D classes ran at about one quarter of the rate of the code using Flint’s own 3D classes. Continue reading

Signals from Robert Penner

Robert Penner has just released the source for his event system, called AS3 Signals. It’s an interesting read and the sort of project I like – a small feature set in need of good architectural design. And I like the design.

I like to think that Robert may have been inspired in part by my work with events in AS2, but I doubt it.

The conversation’s just kicked off on Twitter and Robert’s Blog. Josh McDonald in particular has already made some good suggestions. My comments on bubbling are awaiting moderation.

The I in Interface

I’m often asked why the interfaces in Flint don’t start with a letter I. The simple reason is that I think this practice, while common among Actionscript developers, is so seriously flawed that it’s better not to do it, even if it is common among other developers and may cause some initial confusion for some.

The argument for

The only argument I’ve heard in favour of this practice is that it enables a developer to know whether a type is a class or an interface just by looking at the name, but I’m not convinced.

It’s more confusing

Looking through the core Actionscript classes, I do a double-take at classes like ID3Info – (What’s a D3Info? Oh, it’s a class not an interface.)

Or, consider what might happen if you were creating an application that interacts with mobile phones. You are very likely to have a type called IPhone. But is that a standard phone interface that all phone classes should implement? Or is it a class for the iPhone implementation?

Same name, different type

And it’s not just confusion over whether something is an interface or not. What makes a class an EventDispatcher? Is it any type that extends EventDispatcher, or is it any type that implements IEventDispatcher. The I is just a prefix indicating that a type is an interface, so we have two EventDispatcher types. Without the I prefix this wouldn’t be possible.

But we copied it from Java, didn’t we?

Actionscript developers have adopted the I prefix because Adobe did so. But why did Adobe adopt this idea? Common thinking is that they adopted the idea from the Java community, which sounds plausible. Many of the ideas in Actionscript originated in other languages.

However, using an I prefix on interfaces isn’t a standard in Java. In fact, it’s just the opposite. Look at any of the Java core api, or any other code developed by Sun, and you’ll not see an I prefix on the interfaces. And it’s not just Sun, many other large Java development companies don’t use the I prefix (Google, for example). Far from being a Java standard, the I prefix is an aberration adopted in some corners of the Java world, possibly by ex-Microsoft developers.

Hungarian Notation

Why ex-Microsoft developers? Because Microsoft used to use Hungarian Notation in all their code (Charles Simonyi, who invented Hungarian Notation, became chief architect at Microsoft). The reason Hungarian Notation works is because it requires every name to have a prefix. So iPhone is the Phone interface (i prefix for interface) and cIPhone is the IPhone class (c prefix for class).

Mixing it

Problems occur when only some names have prefixes, as with the I prefix for interfaces and no prefix for classes. Unfortunately, this is the pattern that Adobe have adopted for Actionscript (and that Microsoft have adopted for C#, but even C# isn’t perfect).

So…

This is why I don’t use the I prefix on interfaces in any of my code, including Flint.

Object Pool class

Two of the slow operations in the flash player are object creation and garbage collection. If we pool objects – save objects when they’re no longer needed and reuse them later when another object of the same type is required – then object creation is kept to a minimum and garbage collection is reduced to zero.

Joa Ebert discussed this in his presentation at Flash on the Beach. I already use specific object pooling in Flint particles, but while Joa was talking I had an idea and wrote a class for generic object pooling of all object types. I finally had time to test the class, and it works as expected, so I’ve added it to my open code repository.

The object pool class manages pooling of all objects through two simple methods. You can obtain an object from it like this

var obj:SomeClass = ObjectPool.getObject( SomeClass );

If there are any such objects in the pool, one of them will be returned. If there are no such objects in the pool, a new one will be created and returned to you.

When you no longer need an object, you can add it to the pool for later reuse like this

ObjectPool.disposeObject( obj );

The object doesn’t have to have been created through the pool – any object can be dropped into the pool with the disposeObject method.

The source code is available in my GitHub code repository.