Steamboy

1. A beautiful girl with bad, dry hair dressed in a purple coat and purple top reads her boyfriends book over his shoulder while he ignores her.
2. A fat middle aged woman in a garish pink t-shirt and no bra rests her saggy breasts on her belly while she reads a thick badly written thriller. Her husband has a lump on his head the size of an egg.
3. A well off couple, he with his stripy shirt opened to the 3rd button and she with a tight, pinched mouth, laugh over story in the paper about a body found in a wheelie bin. They both have 70s tans.
4. A bald man dozes, waking up at each stop looking confused.
5. An extremely masculine woman with a mouth like a carp sits next to a dumpy asian man with a long, curly beard who is counting his prayer beads.
6. A man in his mid fourties texts on his phone, looking awkward and uncomfortable with the technology like someone who is pretending that they smoke.
7. A Canadian lady talks about someone wanting to get the cathedral involved. She has a nice voice but seems a little anxious.
8. A old man with extremely blue eyes and a smiley face coughs into his fist and tries to sleep. He is perched in an uncomfortable position, looking like a drunkard holding onto the table for support.
9. A woman in a stripy t-shirt and a pink cardigan has a suitcase, some duty free and a face full of regrets.
10. A young black man reads Hi-Fi Magazine.

In this insalubrious space they are not any less big, but much more tiny, more detailed. There is a petitness, a skinnyness to the refrain. A breaking wave scatters the silence of the band, falling down into a clutter of sound. The drums champ, scattered cymbals chink amongst the battering of a tom-tom. The voice a soothing chant, repeating words not of this world, a lullaby for worldless children. The sound is soft and round and scared, a late mother of a toothful dog-child. There are strings skittering around the bowed double bass, wilful imps amongst a stirruped back beat. A piano tramp corrals a buffoonery of darting horns against pitch deep grumbling accordion. The bright new brass chimes in delirious arpeggios, scaling and spiralling around the droning chord walls. The tale of the song is pitiful sweet and alluring, recants of sonabulent doll-fiends and dredging drug slaves. The scantity of light lives against black back stories. Whilst it could be mere precious starling chirrups, the grissly ribs of the song poke through, revealing meat and cartilage that brays of the bravura adventures and callous endeavours of youth untethered. It is at once gaseous and graceful, yet equally stumbling, sod laden, wall-eyed and arrogant.
It is as elemental as any sound given rude form, punchy and rueful in a recumbent back room, belying its paunchy surrounds to bruise the sensibilities of the audience with its delicate and divisive incantations. Once over, the taste of the melody hums in the belly of the ear like the virginal stealing of a straying uber-mensch. The band stagger off, drained and bloodless, spent. We splinter home to wonder at the world made unreal by these strains of eloquent guttery, too revived to fear the workful grey dawn, happy and dirty and whole.

It is the music that makes us.

Well, the Bennett family's annual trip to the land of the rising sun is over again. Coming back to Brighton on the bus always reminds me how vibrantly green England is, pretty much all year round. This lead me on to think about other things I miss about England. It pretty much comes down to sausages and cheese. Those and the ability to communicate with people with a better vocabulary than my 2 year old daughter. However, sausages can be imported and my Japanese is 5x better than when I left. I think I could do with the lush rolling hills of England if I get out into the mountains, bamboo groves and moss gardens every once in a while.

As you may know from if you read my last post, we've been thinking about a move over there and this trip was, in part, to suss out the viability of doing that. We took a trip over to Kyoto, where we'd ideally like to live, for that reason and also to check out the cherry blossoms, which at this time of year are full on gorgeousness. Whilst there I picked up a property paper and with the help of my good lady wife perused what was on offer.

What I mostly learnt was this:
Renting in Japan is ridiculously expensive. Not (necessarily) because of the actual rent, but because deposits seem to be at least 3 months rent, a month goes to the estate agent and then there is 'key money' which is essentially a gift to the landlord. In some cases this was about ¥500,000 - roughly £3000 in today's money. Seems like an awfully big gift to me!

So, a little disheartened I decided to check out the properties to buy. I was pretty surprised by what I found. I'd heard tales that the building standards in Japan were very low, with the average age of properties being ~15 years and anything about 30 years old falling apart(compared to the UK, where the average is 120-150 years!) but I didn't realise how much this affected property prices. New houses were comparable to the UK, at about ¥30,000,000 or roughly £200,000. However, looking at older buildings showed how quickly house prices depreciated. 1 property I found, built in 1961, cost just ¥4,000,000 - that works out at just under £27,000, even with the weak pound! Admittedly it was tiny and had no outdoor space (except the toilet!) but even then, the land itself would surely be worth more than that?

From speaking to a few people, it seems that the housing market is very different to that in the UK, with very little upkeep of buildings. There is definitely not the DIY minded approach that there is here in the UK. The Japanese would rather demolish and rebuild than repair or modify. How much of this is due to the constant threat of earthquakes, the wooden construction of most small houses or the constant need of the Japanese to have the latest and best, I don't know. We worked out that if we lived in a house of less than ¥10,000,000 (£67,000) for about 5 years, it would be cheaper than renting and would offer at least some return on investment. Add to that the possibility of getting a fixer upper at a bargain price it would seem to be the way forward. Of course, even that amount of money is still a considerable chunk, so I'm going to investigate further but it's good to know there is a way forward!

Over the last 2 years, I've focussed all of my efforts on learning Actionscript. More recently I've begun to learn how to use Flex. I think I'm now at the point where I'm comfortable enough using Actionscript to be able to do pretty much whatever I want. Flex still stumps me with some of its code juju, but I now feel confident in tackling its arcane magic head on now. This blog is, in a way, a chart of my progress in these things. Well, from now, I've decided to take a slightly different direction.

Along with the rest of the Flash speaking world it seems, I have decided to move into game development (yeah I know Flashers have always made games, but games on other platforms) - and I'm not just taking about games for a certain fruit based brandwagon. In order to do this I'm going to need to learn another programming language. After some thought I've plumped for C++. Why? Well, I wanted to cover as much ground as possible mainly. C++ is a language that will give me a good base for developing for the Nintendo DS, the Wii (via the rather excellent Unity3D), the iPhone and others. As far as I can tell, all of the above will require specific graphics and controller code, for example using Objective C for the iPhone graphics. However, I didn't want to limit myself to an Apple specific language which, by all accounts, has been hit with the ugly stick a few times.

I also want to post more on my blog. There is a lot that goes on in my life besides writing code (but sometimes the code does rather take over) and I'd quite like to put that out somewhere. As I get older, I'm pretty sure my memory is going, so it'd be nice to be able to look back and realise that I did more than program 24/7! Someone also mentioned that they thought my blog didn't have enough pictures on it, so more of that too.

I'm setting up a new blog over at my company Steamshift's website which is here: my other blog which I'm going to reserve for posts about the day job, while this one is going to be more esoteric in its content

The last thing, which is pretty big, is that my family and I have decided to move to Japan. For those that don't know me, my wife is Japanese and we've always thought it'd be nice to spend a few years in Japan while the kids are young. We planned to go in May, but the global money bunglers have managed to make sterling so weak I might as well use cheese as a currency. Since I planned to carry on freelance work for my UK clients and to rent our house out to cover our Japanese living expenses, this has obviously impacted my earning potential. We are still going to go, but it'll just take a while longer.

So onwards and upwards, as they say.

I've been meaning for a while to have a look at Flint and so here are my first steps with it.

First off, I like the way it is arranged. It is incredibly modular. Whilst this probably has implications as far as optimisation (although it seems to handle a whole load of particles pretty nicely), it does mean that any kind of particle system can be plugged together easily.

There are 2 basic objects that need to be instantiated - an emitter and a renderer. There are a few different types of renderer, for different types - Bitmap, DisplayObject and Pixel.

Once you have your emitter created, then the behaviour is adjusted by adding 4 things.

Initialisers.
These are used when a particle is created, so things like colour, mass, size, image to use etc.

Actions.
These are applied to the particle every frame. Things like gravity, collisions etc.

Zones
This an area of the screen, commonly a point, line, rectangle or circle. Zones can be used for some initialisers, for example position and velocity. A Zone used for position will be used to randomly place a particle in that area. The velocity zone creates the velocity based on the time taken for the particle to travel from [0,0] to the randomly selected point. Zones can also be used as actions. For example, a DeathZone is an area that removes particles that enter (or leave) it, and a Jet zone is one that adds a velocity to the particle if it is inside.

Activities
These modify the behaviour of the emitter every frame, for example making it follow the mouse or rotating.

Most of these have a 2D and 3D counterpart.

Right. Enough explanation. Here's the first experiment:
(Please note there is a bug (in my code) that occasionally comes up where the particles are duplicated endlessly. You have been warned!) This has now been fixed
Read the rest of this entry »

AS you might know, the only way to add Sprite based classes into a Flex project is by adding them to a UIComponent or a subclass of UIComponent. This adds some extra complications. One of these is that UIComponent does not report width and height correctly. If provided with an explicit width and height, the UIComponent's size will be set to whatever it was when initialised and will not change if, for example, the contents of the component are scaled. This means that whatever contains the component will not respond appropriately. Dynamic sizing doesn't seem to work at all. (As an aside, I do think that this is rather a poor implementation, since it breaks the existing functionality of DisplayObject)

In order to correctly set the size we need to recreate the DisplayObject functionality in order that from outside the component we can see the changes in size. In order to do that, it's necessary to understand how UIComponent (and by extension, most of the other Flex components) is set up and handles sizing.
Read the rest of this entry »

You wan freelance? We got freelance. (If you're in Brighton (or London (or anywhere, it is nearly 2009 (where did that go?) now) ) which, let's face it, you wanna be).

Presuming I haven't lost you with all the nested brackets, I've been kindly linked to by a few people now on the list of the top Brighton Flash Developers. Clearly it would be rude not to do likewise...

Here's my list in alphabetical order:

Designers/Animators

Charis Mystakidou (wiredportfolio.com)
Kristan Akerman (sting.co.uk)
Luke Hornsby (flamingpixels.co.uk)
Tim Frost (bullandgate.com)

Developers

Me (here and also my company steamshift)
Matt Pearson (actionscripter.co.uk)
Matt Sayers (soplausable.co.uk)
Neil Manuell (revisual.co.uk)
Nikos Chagialas (devgallery.com)
Richard Willis (richtextformat.co.uk)

There were some more, but I think they've all been employed by plugin-media

Seems I was right (well, let's see shall we...) in my hypothesis regarding swcs in the same folder as the fla. In order to test this, I started up a new Actionscript project in FlexBuilder and created an assets folder. In Flash I opened a new fla, which I saved into the folder and then began to load it up with assets. At 32.4MB and 130 odd symbols (including videos, vector symbols, images and sounds) my swc finally broke and wouldn't import into Flex properly. I then created a swc folder in Flex Builder and set the fla to import into that folder. Importantly, I also deleted the swc + swf from the assets folder. After recompiling the fla and rebuilding my Flex project, everything magically worked again.

I hope this helps someone out!

Since my unbridled enthusiasm for swcs a few posts ago, I've been sharply brought down to earth about just how unreliable they are. I've come across a couple of different problems that just defy all logic. While I still think they are by far the best solution for projects where you want to have your assets compiled into the swf, there are some things that will make you want to stop doing Flash development and go take up pig farming instead.

1) Sometimes your swc will just fail. This seems to be in some way related to the number of assets in the fla, but not neccessarily. You'll know you've got this one when the previously fine references to the swc classes suddenly break, as though it can't find them. Richtextformat has got a full explanation of the "solution" to this problem over on his blog.

2) Your swf can't find the document class anymore. I have an fla that held all the assets for my Flex based project. I'm compiling this to a swc and then using that as a library. All fine. However, the designer doesn't have Flex, so he wants to compile directly from the Flash IDE. So, I set up the document class for him. However, when the fla is compiled, nothing appears. No errors, no traces from either the document class or the timeline. Nada. The problem was that I had left Export SWC on in the publish preferences. Unticking Export SWC did nothing however, it required the swc to be deleted. Then, it worked. All I can assume is that Export SWC was generating a duff swc, which in turn was breaking the swf.

The solution workaround hack I'm using is to have 2 flas. One is set up for compilation from the Flash IDE, the other a blank, unsaved fla (as per Mr TextFormat's instructions) to generate my swc. This is a pain in the arse, let's be honest. Every time the fla is updated, I have to refresh the swc fla assets and recompile. I guess I could write some kind of jsfl script to do it for me, but I've wasted enough time on this already

Anyway. It seems that the Export SWC command in CS3 is really broken. I'm going to try on CS4 and see if it's been fixed. Fingers, toes, tentacles and any other prehensile appendages crossed.

[Update - It seems like this issue only occurs if you are building the swf/swc into the same directory as the fla. I've tried it with a couple of builds to outside the directory, and it seems to be ok - there might also be an issue if the fla is inside the Flex directory structure but I haven't confirmed this. More testing is needed...]

One thing that I've started using in most of my projects where the processor could get hit heavily is a dynamic rendering system. This seems to be working really well, so I thought I'd share it.

I came across the idea from this post over at 8 bit rocket. The idea is pretty simple. A timer is set to run as fast as possible. Every time the timer executes, it runs a render cycle and a code cycle. It then checks how long the total cycle took and does 1 of 2 things. Either it sleeps for a certain amount of time, so that the swf doesn't run too fast, or the next render cycle is dropped so the player can catch up. It's a little more involved than that so if you want to know the finer details, head on over there.

I made some crucial adjustments to the code that's presented there however. The biggest one was to make the code into a class, so that I could use it more easily. I've set up a system for registering renderers and updaters so they can be added and removed from the timer, and also added some events that get dispatched on render and update cycles. It works really well if you have an MVC setup, since the model and the view are already separate.

The source code is available here. Documentation after the jump.
Read the rest of this entry »