next »

[Titch]

After numerous frustrations with links to embedded files getting broken when I wanted to re-structure code (which is so backwards to me, anyway). I decided to enact my own Library class to handle all the resources being pulled into the project and put it in the root of my lib folder.

Code:

scr
|->|Lib
|  |Library.as
|Main

Then everything is embedded as a public static const. So now when I need a library asset I just call this:

Library.AssetName

Because everything is contained in the library folder, it doesn't matter if I have to change the structure of the rest of my code. Even if I shuffle library assets around it means a lot less hunting through code for the associated embed tags and updating them with the new path. In general it's been working so well I'm getting suspcious that it's either:
a) Really terrible programming practice
b) A really inefficient way of accessing resources. I've heard bad stuff about making lots of static references in Flash.

So can any programming/flash experts set me strait on this?

[knucracker]

I've embedded around 50 or so images and xml in a similar way... without any performance issues.  I use flex builder (since it's eclipse based) and structure my project so I have a "common" project that I share between things like the game and a map editor, etc.  This common project contains a directory tree of assets (images, xml, etc).  And I have several classes that embed all of these assets.  Works great....  I wrote a great big ole tile engine with all kinds of 100x100 pngs.  I've also loaded up dozens of xml files the same way (for things like level content).

If you are really worried about it I'd create a performance test in a scratch project where you embed like 1000 assets (write a script or whatever to write out the as3 that has 1000 statics in it).  You could probably do this fairly quickly and get a definitive answer that applies to your specific situation.

[Martin 2BAM]

I think using statics fucks with the preloaders as they must be loaded at start, even before any code get's executed.

Had some problems with this, but perhaps I'm wrong.

Anyway you can make something similar by defining everything non-static and implement a singleton pattern.

-Martín

[Reiss]

Flash's [Embed] tags are pretty terrible for proper code structure.  I guess you could make some kind of complicated etc etc whatever, but it'll barely cover the fact that [Embed]'s are a pain to deal with, and it'll probably be slower.  The only issue I see possibly arising from what you're doing is that the resources will all be initialized when Flash loads your game, and won't be cleaned up until the game closes, and so you could be wasting memory.  If it's not being a huge memory hog now, though (and normally I wouldn't say this about code structure and memory-wasting)...  If what you've got works, it works. 

[John Nesky]

As far as I'm know, assets that are not produced by your code and are embedded into your SWF or EXE might as well be some sort of global variable in almost all indie games. Given these constraints, I'm having trouble thinking of situations in which that would be a bad idea. The "global variables are BAD" thing is more applicable to data structures that are created by code at runtime.

As for static being slow in Flash... well, yeah, but by what order of magnitude? If you're accessing the static variables tens of thousands of times per frame, yeah, it may be noticeably slower than performing some other simple action the same number of times. If you're only accessing the static variables a hundred or so times per frame, that's fine. Alternatively, if you access the static variables many times at startup but  then leave them alone afterwards, that's probably also fine.

I think using statics fucks with the preloaders as they must be loaded at start, even before any code get's executed.

I believe the static variables won't be loaded until the class that owns them is loaded. Then it becomes a matter of trying to figure out how to tell the compiler that you want the class with assets to be loaded later, which is honestly a tricky thing to figure out if you're using MXMLC to compile, and it's almost impossible if you're actually using any MXML. But if you're using Flash CS3/CS4 and a standard preloader, the standard techniques for creating preloaders should work as long as you don't make any reference to the class containing the assets from the preloader.

The only issue I see possibly arising from what you're doing is that the resources will all be initialized when Flash loads your game, and won't be cleaned up until the game closes

This is necessarily true unless the assets are loaded from separate files instead of getting bundled into the SWF. Which I guess is the alternative you must have had in mind?

[Martin 2BAM]

As for static being slow in Flash... well, yeah, but by what order of magnitude? If you're accessing the static variables tens of thousands of times per frame, yeah, it may be noticeably slower than performing some other simple action the same number of times.

Not quite, it's just a global variable access.

I think using statics fucks with the preloaders as they must be loaded at start, even before any code get's executed.

I believe the static variables won't be loaded until the class that owns them is loaded.

Yes, I think you're right. I come from C++ where all statics are initialized before calling the entry point.
But with dynamic classes and that new age crap (:D), you're probably right.

Using getDefinitionByName instead of a direct reference to any class that could (in turn) reference the "Library of assets" class and load it's statics it should work fine.
(Yes, doing something like "static var a:Class = SomeClass;", loads SomeClass' statics... I've tried!)

The only issue I see possibly arising from what you're doing is that the resources will all be initialized when Flash loads your game, and won't be cleaned up until the game closes

This depends if Flash loads the whole resource because of the Class definition (using "[Embed]..MyAsset:Class", or if it just does so when calling "new MyAsset".


Regards
-Martín

[bateleur]

This depends if Flash loads the whole resource because of the Class definition (using "[Embed]..MyAsset:Class", or if it just does so when calling "new MyAsset".

Although in the case of "new MyAsset" you have to think about where it might be getting the data from. Supposing we're talking about something like an image then the data will be in memory whether or not anything creates an instance. The only way to avoid this is for it not to be downloaded until it's needed, which you can't do with resources embedded in a SWF (hence "embedded"). (There is a sort of exception in that you can embed stuff in later frames which aren't downloaded until they "play", since Flash is a streaming format... but that's not generally useful for games.)

[Martin 2BAM]

This depends if Flash loads the whole resource because of the Class definition (using "[Embed]..MyAsset:Class", or if it just does so when calling "new MyAsset".

Although in the case of "new MyAsset" you have to think about where it might be getting the data from. Supposing we're talking about something like an image then the data will be in memory whether or not anything creates an instance. The only way to avoid this is for it not to be downloaded until it's needed, which you can't do with resources embedded in a SWF (hence "embedded"). (There is a sort of exception in that you can embed stuff in later frames which aren't downloaded until they "play", since Flash is a streaming format... but that's not generally useful for games.)

I was thinking about compressed images/audio. The embedded MP3s probably are in the temp files or memory as you saye until needed... but a 5MB uncompressed MP3 could take up to 100MB on RAM.

Regards
-Martín

[Draknek]

Except I'm pretty sure MP3 files are decompressed on the fly: same with images.

So all that would be in memory is the compressed version.

[knucracker]

Just a few additional notes from my experience:
I can corroborate what everyone has said about preloaders and such.  The statics don't 'appear' until the class defining them loads.  So with a preloader your preloader code all runs in the first frame, and your app appears in frame 2+.  So long as you don't reference any of your game classes in your preloader, you'll be set. 

Having said all of this, I still would recommend just using cs3/cs4 to create an 'asset' swc if you are using something like flex builder to write your game.  In other words, just create a project in cs4 put all your your images, sounds, and whatever in the library.  Export this and make sure to create a swc.  Add that swc to your flex builder project settings and party on.  You will want to develop a clean naming convention for your assets so you can reference them in your code without having a photographic memory.

You definitely want to do this with wav's since you get great control over their compression when you embed them.  In fact, embedding wav's requires some trickery without cs3/cs4... but that is another story.

[Martin 2BAM]

Thanks for the insight, man!

[bengarney]

PushButton Engine has a nice class for dealing with [Embed]s: http://code.google.com/p/pushbuttonengine/source/browse/trunk/src/com/pblabs/engine/resource/ResourceBundle.as

It automatically scans the embed metadata and registers the data by filename, so you can look it up later by filename. This is IMHO a lot more sane than referencing the class everywhere.

[Triplefox]

In haXe you don't get an Embed tag. Instead you build a library swf with swfmill and either use flash.Lib.attach(classname) or create a stub class of the desired type and instance that. It's ugly, and it screws with preloading, but it can be made workable - it's not hard to write a pipeline script to deal with the semantics of getting access to everything in the library, and from there you can use a method such as this or this to do preloads. (Albeit, at the moment there are changes going into haXe to better deal with overlapping ApplicationDomains, it's caused miscellaneous breakage in these methods, a debate on the compiler list, etc., but it looks like it will all get resolved soonish and with cleaner methods than before.)

A static access is indeed slower than a local or instanced one in Flash 9.
See: http://blog.haxe.org/entry/26 and http://blog.haxe.org/entry/31

[Titch]

PushButton Engine has a nice class for dealing with [Embed]s: http://code.google.com/p/pushbuttonengine/source/browse/trunk/src/com/pblabs/engine/resource/ResourceBundle.as

It automatically scans the embed metadata and registers the data by filename, so you can look it up later by filename. This is IMHO a lot more sane than referencing the class everywhere.

This = very cool.

I just wish all the solutions wheren't tied up with using a certain engine/script. Perhaps I'll take a look and see about using Pushbutton next time, or at least getting this out and a nice clean class I can use without having to initiallise a bunch of other engine driving classes.