To fix the OutOfMemory error, you should do something like this:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 8;
Bitmap preview_bitmap = BitmapFactory.decodeStream(is, null, options);
This inSampleSize
option reduces memory consumption.
Here's a complete method. First it reads image size without decoding the content itself. Then it finds the best inSampleSize
value, it should be a power of 2, and finally the image is decoded.
// Decodes image and scales it to reduce memory consumption
private Bitmap decodeFile(File f) {
try {
// Decode image size
BitmapFactory.Options o = new BitmapFactory.Options();
o.inJustDecodeBounds = true;
BitmapFactory.decodeStream(new FileInputStream(f), null, o);
// The new size we want to scale to
final int REQUIRED_SIZE=70;
// Find the correct scale value. It should be the power of 2.
int scale = 1;
while(o.outWidth / scale / 2 >= REQUIRED_SIZE &&
o.outHeight / scale / 2 >= REQUIRED_SIZE) {
scale *= 2;
}
// Decode with inSampleSize
BitmapFactory.Options o2 = new BitmapFactory.Options();
o2.inSampleSize = scale;
return BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
} catch (FileNotFoundException e) {}
return null;
}
Update: thanks for the high-stress version. Again, I couldn't really see a difference just running around. But I cleverly figured out that "r" drops turrets, and when I dropped 20-30 turrets, the native version was somewhat slower than the manual one, so maybe I was wrong. (I saw no difference in memory usage.) It still seems like doing things natively ought to have the potential to be faster, but it may well be that it would require specialized handling of some opaque sort.
Since this was accepted I'll add a note to make explicit what I said in a comment to a different answer: If all your assets are bitmaps themselves, then as HanClinto points out it's not surprising to find that compositing them manually can be faster than making native objects and letting Flash do the work, since it eliminates the overhead associated with display objects, like event structures.
However there are probably situations where doing things manually might win out, such as if you have vector contents that need to be rendered into bitmaps, or lots of animated sprites, or if you need to detect mouse events on your actors (which you'd need to do manually, perhaps painfully, if you do your own compositing).
So if you don't need to do anything that would slow down manual compositing, it appears to definitely be the best answer, and if you do, then trying both approaches is the best way to be absolutely sure. (A hybrid model is also possible, where you make one layer of native objects that need mouse events, and overlay or underlay it with a layer of manually composited bitmaps.)
Best Answer
First of all, BitmapData and Bitmap are not interchangeable. They are two very different things. The BitmapData class contains bitmap pixel data, and allows you to manipulate that pixel data, e.g. draw to it, change the color of particular pixels, et c. There is no way of displaying a BitmapData directly, i.e. by adding it to the display list.
The Bitmap class, on the other hand, is a DisplayObject, like MovieClips and Sprites, which you can add to the display list. It's single purpose is to render a BitmapData in the display list. In fact, it is not even interactive, so you cannot detect clicks directly on a Bitmap instance, for example.
On to your question: If you have a bitmap data that contains a tile sprite, and you want to draw that tile in another bitmapdata, you can use the BitmapData.draw() method, or the BitmapData.copyPixels() method. The latter is one of the fastest methods you can use on any BitmapData, so I would highly recommend it.
Depending on your particular application, it might not be beneficial to draw everything in a bitmap at all. It sounds as if you want to be able to detect click events on all the tiles, which makes me think that you would probably benefit from having them be separate DisplayObjects, e.g. Sprites.
If you want to, you can create a Tile class that extends Sprite, and draws a BitmapData using a bitmap fill. That way, you can have any properties you want, and also detect mouse events on the tile instances.
This class could simply be instantiated for every tile in your game, passing in the bitmap data that should be drawn in the tile. You could also listen for events on such a tile instance.
This way, you don't have to use the Bitmap class at all to render the tiles. They can be added directly to the display list.