The hard part was to get this thing to work. So I just wanted to share my settings here. This might become useful, if you’re starting to develop your first ANE. I had strange crashes when I packaged the app with my ANE and I couldn’t figure out what was wrong. The app just crashed everytime I launched it on the device. The crashlog wasn’t very helpful. After quite a search, I found out, that I didn’t set an apparently important compiler flag for the LLVM compiler in my XCode project. So, be sure to set:

Enable Linking With Shared Libraries: No

And if you want to get rid of the warnings:

Warnings: Missing Function Prototypes: No

The second part was packaging the ANE correctly. The working command for my case is:

adt -package -target ane MyExtension.ane extension.xml -swc MyExtension.swc -platform iPhone-ARM library.swf libMyNativeExtensionIOS.a

The annoying thing about packaging the ANE is, that after you have built your swc, you have to extract the library.swf out of it (By renaming it to .zip and extracting the swf). So you need both, the swc AND the swf. I didn’t write an ANT task to do automate the process until now and I don’t know the reason for this strange step, since the ADT compiler has everything it needs within the swc. Only Adobe knows ;)

Obviously you can not test on the device everytime, because the deployment process to iOS is more or less manual and just takes too long at the moment. I found out, that I could link the ANE as a regular library (SWC) in my Flash Builder project and launch the app on my desktop machine. When the native extension tries to create the context on the desktop machine, it fails and returns null, because it was just built for the iOS platform:

context = ExtensionContext.createExtensionContext(EXTENSION_ID, null);

So I could implement a fallback for the extention when running on the desktop that mocked the behaviour in AS3. To package the application for iOS, I wrote a small ANT task. This way we can easily test on the device and have a fallback, when testing 0n the desktop without writing desktop extensions as well.

So, maybe someone will find this useful…

The particle system is based on a CCNode and works similar to the existing Cocos2D particle systems. The main difference is, that you can control the position and velocity of each particle. Please note that this system is not very optimized and lacks in flexibility since I just built it for FluidToy 2 and it was never meant to be more general. In other words: The code is a bit dirty! But feel free to play around with it, modify it and make use of it (and let me know what you’re making out of it).

There are two different systems: The SimpleParticleSystem, which draws points of any size or a point sprite using a texture. The second one is a LineParticleSystem, which will draw line particles. If you initialize the system with a size of 1000, you’ll have 500 lines, because a line consists out of 2 points (Wow, you never imagined that, did you? ;)). So if you loop through the particles, be sure to move only every second particle, the other one will follow with a small delay.

Download: Cocos2DSimpleParticleSystem

It works like every other CCNode:

particles = [SimpleParticleSystem node];
[particles initialize: 1000 width: size.width height: size.height];
[particles setTextureByString: @"particle_small.png"];
[self addChild: particles];
 
Loop through particles:
 
while(count < particles.particleCount)
{
   p = &particleAr[count];
   p->dir.x += CCRANDOM_MINUS1_1();
   p->dir.y += CCRANDOM_MINUS1_1();
   ++count;
   ...
}

Have fun!