Fixed!

After that complete balls up I've re-written the code and tests, now finally it does indeed look like blitting is faster (as expected!).  Hurray!

I just saw that you can set up downloads on google code so I'll probably set up swf's for each test to be downloaded from there.  I'll write a proper post about it all over the next couple of days.

I *might* also set up some ANT stuff to automate some compiling tasks.  Joy!

Blithering Idiot

Gosh, I've just realised I've got this blitting thing all wrong.  You're suppose to have a canvas bitmap which is essentially the stage, each time an object changes you need to draw the stage again!

Oh dear oh dear!  I was running some tests and realised that the method I was using was a LOT slower!

Back to the drawing board!

EDIT:  I should probably add that these two links really made me think "You plonker" : Adobe Link, Iain Lobb.

At least I'm learning something new for once :)

New Asset Class

Right I've drummed up a really basic class which will automatically generate a playable sprite based on the sheet and xml its passed.

I have to figure out somewhere to post the demos although it is particularly dull :)  And probably some nice way of displaying code within a post

It's all available at Google Code.

Up Next : SpriteSheets

Right so I whacked in that asset class and uploaded everything to a google code project.  Here's the link: Google Code


The Asset Manager for now does what I need it to do (I'm sure I've said that before).  Right now I'm doing a bit of research into blitting / spritesheets.


First off, there seems to be two types of sprite sheet; one which appears to be for animation and another which seems to be a characters entire collection of visible states.  The main difference between the two is the spacing, one is uniform and the other isn't.

Character Sheet

Uniform : Animation

To manage the spritesheets I'll have to use some sort of data sheet to go with it. I'm thinking the best thing to do is create an XML sheet to handle all the details for the spritesheet.  To what extent I guess I'll find out when I get to it.

Having a quick butchers on the net I've come across this website : 8bitrocket, which has a wealth of wonderful tutorials on blitting and rendering models and such.

So yeah this should be fun working out how best to approach this, I'm sure someone told me when I first started programming that you should never develop  something unless you know you're going to need it...What the hell am I going to use this for!!

I talk too much

Hmmm....  I was just thinking, perhaps it would be a lot better to have a new Class which handles all the asset details...an Asset class :)


The Asset would be created and passed to the AssetManager which would then determine what to do with it, usually creating an AssetLoader, loading it and then allowing access to the loaded object.


I'll whack it in the code next time I work on it.

Asset Manager

Right so I made a couple of classes for the asset management tool.  I'm going to host all the code on Google Code at some point but I can't be arsed at the moment (too cold perhaps?).  Instead I'll just run through the basics.

So the bits I thought I needed were :

• Determine whether to use the URLLoader for data (xml, text, etc) or the Loader for swf's and images.
• Allow access to loaded data and encapsulate the getDefinitionByName function
• Unload assets that are no longer required (Garbage Collection, yuk)
• Queue loads
• Report load progress, handle errors and complete events

Out of the 5 I managed to do 3, I didn't bother with the getDefinitionByName just yet because it's mainly used to grab graphical assets from Flash files which I won't be using any time soon.

I also didn't bother with the unloading of assets because again the main purpose of this is to unload load graphics swf's to free up memory. I won't really need to do that with bitmaps and handling the disposal of those is much easier.

There are only two classes; AssetManager and AssetLoader.  The AssetManager simply instantiates an AssetLoader and adds it to a loadQueue.  The AssetLoader determines what type of file is being loaded (from the extension of the URL), loads the file reporting the progress (as a trace only at the moment) and then executes a callback.  Pretty basic but hopefully a solid base to start on, adding to it when necessary.

Ok so I'll create a google code account some time later on because talking about it is rubbish...

Next on the list : SpriteSheet handling!

To code or not to code...

A blog...to do whatever I want with....!

In making this blog...why is the Blogger spell check telling that "blog" and  "Blogger" incorrectly spelt.  Nice.

Anyway I'm hopefully going to use this to help me actually do some Flash work at home cos playing Skyrim, Minecraft, Zelda and SW:TOR is ... crap.

My first project is to build up a core library of components that I can use at home and for all the projects (many I hope) to come.  This should include some kind of loader and asset management, base classes for graphical purposes, some kind of animation handler (sprite sheet animations?) and a whole load of other stuff which I can't even think of!

The first project then : An Asset Management Tool which will load graphics, data and other bits into ApplicationDomains and allow decent management and access of them.

So I guess I should think about some sort of goal:

• Determine whether to use the URLLoader for data (xml, text, etc) or the Loader for swf's and images.
• Allow access to loaded data and encapsulate the getDefinitionByName function
• Unload assets that are no longer required (Garbage Collection, yuk)
• Queue loads
• Report load progress, handle errors and complete events

I'm sure there are loads more but I can't think of any right now!

Right, off to play SW:TOR then....