grey
grey

Reputation: 1150

AS3/AIR: Managing Run-Time Image Data

I'm developing a game with AS3 and AIR. I will have a large-ish quantity of images that I need to load for display elements. It would be nice not to embed all of the images that the game needs, thereby avoiding having them all in memory at once. That's okay in smaller projects, but doesn't make sense here.

I'm curious about strategies for loading images during run time. Since all of the files are quite small and local ( in my current project ) loading them on request might be the best solution, but I'd like to hear what ideas people have for managing this.

For bonus points, I'm also curious about solutions for loading images on-demand server-side as well.

Upvotes: 1

Views: 760

Answers (3)

grey
grey

Reputation: 1150

The solution that I ended up settling on was to create a reusable singleton loading class which manages the loading and storage of data on-demand. It manages "jobs" which can be LOCAL or REMOTE which store references and the loaded data itself which is mapped in the manager class once it has fully loaded.

While I really like back2dos's suggestion, managing the (re-)creation of SWF's everytime an asset changes isn't optimal for my purposes.

Upvotes: 0

back2dos
back2dos

Reputation: 15623

a good idea would be, to create external SWFs, that embed images, that are likely to be used together, if that is possible at all ... something like projectiles.swf, obstacles.swf, enemies.swf, misc.swf .... i don't know ... something that makes sense ... maybe divide assets by levels, or something ... take a simple interface, that allows you to extract assets from an swf ... for example, let there always be a class Assets, with a static method getAll, which returns an Object, mapping string identifiers to corresponding classes, so you will get something like:

function onComplete(e:Event) {//this is the handler for the loading operation
     var map:Object = (e.target as LoaderInfo).applicationDomain.getDefinition("Assets").getAll();//should return something like {"bullet1":Bullet1,"bullet2":Bullet2,...}
     //do whatever you need to do with it
}

advantages:

  • images get compressed one against another, so overall filesize will be decreased ...
  • you drastically reduce request count on your server ...
  • you don't wind up with n-hundred files, following some name/path convention, or even not (also, you need to have a file index somewhere, to know, which files exist and which don't) ...
  • you can easily reskin your app by loading a different swf, instead of loading n-hundred images seperately ...
  • the ultimate advantage of this approach is, that you will have classes, that you can simply instantiate, instead of loading images over and over again ... the first operation is synchronous, the latter is not ... if you really need to do that, consider loading the image in binary form into a ByteArray using URLLoader, and then getting it on stage with Loader::loadBytes ...

you may want to generate the swfs on serverside using swfmill, to automate the process ...

greetz

back2dos

Upvotes: 1

Kombuwa
Kombuwa

Reputation: 1651

for you project u can make solution using amfphp and mysql blob-storage. in this link u can take understand how mysql blob-storage.

http://www.anyexample.com/programming/php/php_mysql_example__image_gallery_%28blob_storage%29.xml

and for amfphp please visit http://www.amfphp.org/

and also please check this AMFPHP Live JPEG Encoder too, http://www.bytearray.org/?p=90

Upvotes: 0

Related Questions