Well this is the post I didnt think was going to happen. I have been struggling for weeks with this little bit of tech, ill explain more about why it has been so difficult in another post. For now however, ill just talk about this sample.

So the idea was to build upon what I had been working with previously with my stateless particles systems with WebGL and HaXe. The intention from the start was to replicate some of my very early work (from 2007) on state preserving particle systems in WebGL.

Before I go any further, you can check it out in action here:
http://mikecann.co.uk/projects/HaxeWebGLParticles/ 

First a quick reminder. The difference between a stateless and state-preserving particle simulation is that in the latter we store and update the positions, velocities and other properties of each particle per frame, allowing us to interact and control the simulation. This differs from the stateless particle simulation (detailed in my previous post), where the position for each particle is calculated each frame based on a fixed algorithm.

A fairly reccent addition to WebGL made this possible, namely texture lookups in the vertex shader (aka Vertex Texture Fetch). I wont go over the exact details how this makes state preserving particle systems possible as I have already documented it in my earlier work. A brief explanation is that it allows you to use the fragment shader to perform the updates on particle state stored in textures then use the vertex shader to map those states to a point-sprite vertex buffer.

Basically what this means is that the entire particle simulation can be contained and updated on the GPU, which means no read-back. This allows us to achieve simulations of millions of particles without too much difficulty (depending on GPU ofcourse).

I have uploaded the source for people to perouse at their leisure:
https://github.com/mikecann/HaxeWebGLParticles

As usual it was written using the JS target of HaXe so it should be fairly easy to understand whats going on if you have written any Ecma-script-like-language. Im going to detail this in my next post, but the code isnt the best I have ever written as its a result of a mish-mash of various samples and examples I have found on the web. If anyone has any comments on things that are wrong or could be done better I would be very happy to hear about them.

Just a quick update this evening.

In an effort to to reduce some of the symptoms of eye strain I have been suffering from recently I decided to change the theme of FlashDevelop4 to something a little darker and easier on the eyes.

I took inspiration from the excellent Obsidian theme on the Eclipse Color Themes website.

Im still yet decided if it helps atall, tho I must admit I do like my IDE a little more colorful

I have uploaded the theme for download here: http://mikecann.co.uk/projects/FD4Theme/Obsidian-HaXe.fdz

Once downloaded just double click it to install, then restart FD, simples!

After posting the theme to the HaXe mailing list several people linked the themes they use, so if you are interested there’s more themes here.

Ive spent a little more time this weekend looking at some more  HTML5 with HaXe. Following on from my previous experiments with WebGL I decided to give HTML5′s Canvas a a look as it was supposed to be designed specifically for the purpose of doing 2D.

I had heard from the HaXe mailing list that the Jeash project was a common way of interacting with the canvas in HaXe. Jeash is a remapping of the Flash API into JS so in effect I should beable to take any of my usual flash code, Sprite’s,  BitmapData’s, etc and it should run on the canvas no problems. Nice!

So I coded up a quick blitting example to see what sort of performance I would get:

http://mikecann.co.uk/projects/HTML5SpeedTests/HaXeJeash/bin/

The results were okay (I get about 11FPS with 5,000 crawlers) however I was interested to know what sort of cost HaXe adds. So I decided to code up a second example, this time using pure JS:

http://mikecann.co.uk/projects/HTML5SpeedTests/JSCanvas/

The results this time were better (14FPS with 5,000 crawlers) so I now wondered what happens if I do without Jeash and just code up the example using pure HaXe. I was expecting to see the same sort of performance hit as Jeash:

http://mikecann.co.uk/projects/HTML5SpeedTests/HaXeCanvas/bin/

Surprisingly it actually runs faster (17FPS with 5,000 crawlers) ! This is quite a surprise and totally contradicts my notion that going from HaXe -> JS would incur a cost. I was expecting some cost, but a performance increase?! I can only speculate that behind the scenes the JS engine in the browser is able to JIT compile the HaXe JS much better than the hand-crafted JS and hence more speed.

If you are interested in the source then I have uploaded it here: http://mikecann.co.uk/projects/HTML5SpeedTests/HTML5SpeedTests_1.zip

P.S. All the test were run on Windows 7 x64 in Chrome 14 (dev)

Those who know me know I used to do quite abit of development in c# using Microsoft’s XNA platform.

Well I like to check back in every now and then with some of the big players in the community to see what’s going on.

One of those players is Catalin Zima, who is famous for producing many great shader and effect samples.

One of Catalin’s reccent project particularly caught my eye however as I had tried to tackle the same problem several years ago when I was in my final year of university. That is, Dynamic 2D Shadows Calculated on the GPU (http://mikecann.co.uk/university-projects/shadowshader-in-rendermonkey/)

Catalin’s approach to the problem is far more elegant that my brute force iterative approach. He uses a clever technique of distorting the desired casting image about the light in such a way as not to require iterative pixel lookups.

If you are interested in the more details in the technique I encourage you to check it out over on Catalin’s blog: http://www.catalinzima.com/2010/07/my-technique-for-the-shader-based-dynamic-2d-shadows/

The issue is that when you have a Spark Rect GraphicsElement within a Spark Group it seems that the rollover event of the group is triggered even though the mouse doesn’t roll over the Rect.

Here is a video I made to explain my issue on Twitter:

The code in the video is as follows:

Source code

<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/mx"> 
 
	<s:Group rollOver="trace('ya')">
		<s:Rect x="100" y="100" width="20" height="20">
			<s:fill>
				<s:SolidColor color="0x00ff00" />
			</s:fill>
		</s:Rect>
	</s:Group> 
 
</s:WindowedApplication>

It turns out (after posting the issue on the Adobe Forums) that I was simply missing the “mouseEnabledWhereTransparent” property on the Group. Setting it to false causes the mouse to perform a hit-test rather than a simple bounds check. Thank you Mr Shongrunden for pointing this out to me

So this now works:

Source code

<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/mx"> 
 
	<s:Group rollOver="trace('ya')" mouseEnabledWhereTransparent="false">
		<s:Rect x="100" y="100" width="20" height="20">
			<s:fill>
				<s:SolidColor color="0x00ff00" />
			</s:fill>
		</s:Rect>
	</s:Group> 
 
</s:WindowedApplication>

I hope this helps someone else out!

Twitter can be a funny beast, what makes it great can also make it poor. I use Twhirl which keeps me updated any time one of the people I follow tweets about something, the only problem is that so many people tweet that if I dont happen to see it within about and hour or so of the Tweet, ill miss it. This time however I was lucky enough to catch a tweet by @Joa about his new Inversion of Control and functional-programming-like library, Funk AS3.

As I have been getting well into RobotLegs (a Dependency Injection MVCS framework) recently I was extremely interested to hear about this new project by Joa who I respect very much as a brilliant coder not least because of his excellent work on low-level Flash byte-code optimisation (see Apparat).

Joa has taken a different approach to doing dependency injection. The approach most frequently used (and the one used in SwiftSuspenders / RobotLegs) is to use meta-data to declare to a number of variables for injection. You then map a class to be injected and instantiate it using the injector.

As an example, with Swift Suspenders you would define a class for injection with something like the following:

Source code

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}
 
var injector : Injector = new Injector();
injector.mapSingleton(MyInjectedClass);

Here we are telling the Injector to make a single instance of our class and hold it internally ready for when it is next requested, such as:

Source code

class MyDependantClass
{
	[Inject] public var myClass : MyInjectedClass;
 
	public function performAction()
	{
		myClass.sayHello("World");
	}
}

Here the [Inject] meta-data indicates that we want the framework to supply the class with an instance of type MyInjectedClass. The final part is to make an instance of the dendant class and inject into it:

Source code

var dependant : MyDependantClass = new MyDependantClass();
injector.injectInto(dependant);
dependant.performAction();

As you can see this is a nice way of handling inter-module dependencies in your code, when coupled with a MVC framework such as RobotLegs it becomes and extremely powerful yet elegant way of coding.

It however isnt perfect and Joa, on his google code page mentions three drawbacks of this method:

Your injected properties are publicly exposed and mutable.

describeType is very expensive.

Steep learning curve.

This is where he suggests his alternative method, which is quite ingenious. Using the same example as above you would see something like the following:

Source code

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}
 
bind(MyInjectedClass).asSingleton();

Then the dependant class would look like the following:

Source code

class MyInjectedClass
{
	protected var myClass : MyInjectedClass = inject(MyInjectedClass);
 
	public function performAction()
	{
		myClass.sayHello("World");
	}
}

And making an instance of it could be as simple as:

Source code

var dependant : MyDependantClass = new MyDependantClass();
dependant.performAction();

As can be seen there are some benefits to this method, the biggest one in my opinion is that injected properties dont have to be public as they are provided by the call from within the class scope rather than from outside.

So how does Joa perform this magic? By abusing a little used ability of the Actionscript programming language known as package-level-functions. These are throwbacks from the old AS1 & AS2 days of global functions. There are actually a couple of common examples in AS3 still such as getTimer() and getQualifiedClassName() still used. What Joa has done is to use these package level functions as a method of generating concise looking code reminiscent of functional programming.

Performance wise, im not entirely sure whether by using package-level functions instead of describeType() calls used in meta-data driven IoC frameworks is any faster as Till Schneidereit of Swift Suspenders suggests:

I don’t think that Funk’s approach is any faster than an optimized
metadata-based IoC container: describeType may be slow (as in “takes a
few dozen microseconds to run”), but is only ever called once for each
class an instance of which is injected into. After that, it’s just a
straight iteration over an array for all injection points instead of
Funk’s multiple method calls for each injection point.

So the next step for me is to run some tests to see how things pan out. Either way im very impressed with both approaches and cant wait to see what kind of exciting advances will be developed in the coming months.

For a while now (alot longer than I had hoped for) I have been working on a project that falls outside the realms of my usual kind of games-related projects. Im not ready do describe exactly what it is yet but im excited about it.

For months I have been struggling with the techinal challenges the project has entailed and I have dabbled with many new and highly diverse technologies including JavaFX (Java), Qt (C++) and Mono (C#).  I have been looking for a cross-platform technology that will get the job done that I need and doing it in an elegant manner.

I thought I had found it with a combination of JavaFX and straight Java using the PureMVC framework. I however was plagued with problems throughout with Bonjour, jGroups, JmDNS, JNI and JNA.

So after months of work, hardship and struggles I read a very interesting article on the up-and-coming Adobe AIR 2.0  that was opened for beta in December. With 2.0 Adobe are bringing NativeProcess  to Air. What this means is that you can you can execute native code (.dlls, .so, .jar etc) from Air. To me this was bloody brilliant as I had been playing with Air reccently and my day-job heavily involves Flex and I simply love the power and beauty of Flex.

So what this meant to me was that I could write the bulk of my project including its interface in my much preferred Adobe Flex (Air) and then use Native Process to communicate with a small kernel of Java that would do all the dirty work that Air itself cant do.

So after a little playing with Flerry for Air->Java bridge I started to think about the structure of the code and the framework I would use. For my initial few runs at this project I had been using the Java version of PureMVC. I really like some aspects of PureMVC but I think its can be so overly cumbersome in some circumstances (ill write another post on this in the future I think). So instead I looked at the alternatives.

I have been using Mate alot recently at work and on my own mini-project the Audio Book Organiser. However as this project is partly for my own learning and personal growth I decided to look at what else there was out there. From the videos by Jessie Warden I had heard about Robot Legs. Apparently this framework has been around for a while, but it was the first I had heard of it. Taking at look at it I immediately became very excited as it looks like it offers all the things that make PureMVC great but without the extra coding-baggage that goes with it.

To add to my interest it appears another very interesting, very new action-script technology has been introduced into Robot Legs called Signals by Robert Penner. Signals is an alternative to the standard events dispatching method found throughout flash (more on this in another post).

So why have I called this post “the bleeding edge?”. Well Adobe Air 2.0 is still in beta and has only been for a month or so. Its so new that some parts still havent been documented atall and the only way to find out how they work is to post a msg to the devs on the forums. Signals is also new and its integration into Robot Legs is very new indeed (last coupple of weeks). So at the moment I feel as if im at the forefront of some very new, very exciting technology, a stark contrast to my fiddlings with the ancient Java.

I realise this post is very text and tech-heavy but I needed to post about it before I forgot all the pain I have gone through with this project to get where I am at the moment. Future posts ill be delving a little deeper into some of my experiments with these new technologies

Well I was just doing some audio book organising and realised that it would be great if I could drag and drop a folder straight from my AIR into iTunes ready for upload to my iPhone.

Anyways after a little searching through the docs I came up with this little ditty:

var cp : Clipboard = new Clipboard();
cp.setData(ClipboardFormats.FILE_LIST_FORMAT, [new File(book.url)], false);
NativeDragManager.doDrag(null,cp);

<mx:DataGrid width="100%" height="100%" dataProvider="{books}" editable="true"
  itemEditEnd="{dispatchEvent(new BooksEvent(BooksEvent.PROPERTY_CHANGED));}"
  dragEnabled="true"
  dragStart="{dispatchEvent(new BooksEvent(BooksEvent.BOOK_BEGIN_DRAG, AudioBookModel(event.currentTarget.selectedItem)))}">

I have immense respect for some of the flash developers out there and Quasimondo is one of them. He has just released a little particle related experiment.

Whenever I see these kind of things it inspires me to bash out my own little experiments.

I wont talk too much about it but check it out on this lab page: http://incubator.quasimondo.com/flash/galactose.php

Just did a quick update to the audio book organiser. Added the ability to move the storage database file. This was so that I can put my storage file on Dropbox and it will then be backedup and synced between machines.

New version and sources:

Source: http://www.mikecann.co.uk/flash/AudioBookOrganiser/AudioBookOrganiser_v120_source.zip