Flash memory limit?

Hi all,

I was working on a game using prerendered bitmaps for rotations and animations to make fulle use of copypixels. In other words: I create a bitmapdata for every rotation and animation. For my testing I used 360 rotations per graphic. An animated graphic with rotations would really skyrocket the memory usage as it would roughly use 360*Frames*BitmapData.

This all was fine and dandy untill I added a certain graphic to the prerendering. From that time on Flash would give me the error "ArgumentError: Error #2015: Invalid BitmapData." After some experimenting I've noticed that it has nothing to do with the bitmapdata, but it seems to give me this error when my totalmemoryusage is over about 23mb.

I think the problem is, that Flash just won't add anything when it uses that much memory. I'm not sure though, as Flash is able to give out of memory errors. That raises my first question, why don't I get out of memory errors? And the second ofcourse: is there a limit?

Has anybody got any experience with this or is able to find some documentation on it? I'm kinda stabbing in the dark here.

Why don't you use one bitmapdata spritesheet with each rotation drawn onto it? I assume 1 big bitmapdata is more efficient than many small ones?

I have yet to run into a limit but I haven't done anything with a crazy amount of bitmapdata's.

Several reasons:

1. I prefer coding 360*Frames of graphics over having to make them myself ANYDAY
2. Prerendering allows you to ship a swf which (with my current prerendering settings) would not have to be over 22mb
3. It allows for more precisely sized borders per graphic
4. It's easier to keep track of an array of bitmapdata's

I would like to know if there is a way around this problem, as the only thing I've found so far is a thread by Mr Malee, which confirms my suspicions: http://board.flashkit.com/board/showthread.php?t=750057

What really made me wonder is this from the adobe itself

Quote:

---

Note: The maximum dimensions of a bitmap in Flash Player is limited to 2880 pixels in either direction (width or height). If you attempt to create a BitmapData instance that is larger than this restriction, the Bitmap will not be created. This limit is in place to keep people from creating Flash movies that gobble up the client's RAM. A bitmap that is 2880 x 2880 pixels, will use roughly 32MB of RAM.

---

So one bitmap can be bigger then the limit I'm running into? Now I'm really baffled.

I dont get your reasons,- I use sprite sheets as well in a current project- works perfectly. All I had to do was writing a class that slices up the bitmap-sheet and let me scroll to the desired frame.

and just to be sure we are talking about the same,- what I mean is loading a image like this:
http://board.flashkit.com/board/imag.../2008/10/1.png
there are even free tools on the net that can stitch together automaticly the rendered sprites all together in a nice sprite- sheet while preserving the alpha channel.

That's another situation all together. Let me just show you it in it's current state: http://home.planet.nl/~bogaa096/Tank...ksAS3test.html. Everything you see is cached in memory. Every rotation for every frame of animation.

I hope this is as much as I have to defend my reasons for doing it like this. My main issue is if there are ways to go round the memory problem.

edit: sorry bit irretated

Do you actually need all 360 rotations?
Maybe 36 would be more reasonable.

I think too,- 360 is quite a overkill - though of course it looks smooth atm. but perhaps 160 or little below 100 should be still smooth.

Overkill indeed :)

360 is just for testing purposes, I wanted to see how far I could push it. The example uses 120 rotations actually and has reduced frames by giving the animations their own frames per second. But I don't know how many graphics I'll use in the end. It just feels like an unneeded limit in times of 1gb of ram.

Did some testing with lesser rotations and scaling down the bitmaps to reduce it further:
Zero-usage 9523200 (at the start of the document class)

Memusage 10596352 Scale .5 Rotations 60
Memusage 10608640 Scale 1 Rotations 60

Memusage 11534336 Scale .5 Rotations 120
Memusage 11563008 Scale 1 Rotations 120

Rotations have a significantly bigger effect then scaling. In other words: the amount of bitmapdata's has a significantly bigger impact then the size of the bitmapdata's. The logical conclusion would be that for further optimization I should use spritesheets.

Still, it feels like postponing it.

Quote:

---

It just feels like an unneeded limit in times of 1gb of ram

---

make it 2 if your OS responds to the name Vista ;)

why not creating those sprite sheets via AS and then scrollRect using a instance of that sprite sheet.
BitmapData btw. has a method of dipose() or alike to quickly dump it- so you could draw each time into the same temporary bitmapData and copyPixel it to the big sprite sheet.

Yeah that's what I meant by using spritesheets. That adds a tidbit to complexity as I'd also have to check in which row the sprite will be. I'll probably be chasing bugs for half a day.

Nice one on the dispose method: that should scrape of a bit of prerendering time.

also for finding the rows ect,
it propably goes like this when storing:

PHP Code:

---

for (i=0;i<something;i++){
    x = i % columns;
    y = Math.floor( i / columns);
} 


---

when reading out or applying the scrollRect,- quite eqal like

PHP Code:

---

function getScrollSlice(nr){
    var slice_w = 64;
    var slice_h = 128;
    
    x = (nr% columns) * slice_w;
    y = (Math.floor( nr / columns)) * slice_h;
} 


---

Well I've just finished the prerender portion and have compared the two methods.

Loose Bitmapdata's
Zero-usage 9547776
Memusage 16097280
delta 6549504


Spritesheets
Zero Usage 9461760 (the test main class defines less instance variables/functions)
Memusage 9764864
delta 303104

Spritesheets vs Loose Bitmapdata's
4.6% vs 100%

Now I understand the hype around spritesheets! I also expect a speed increase in the rendering method, as I've set up the spritesheets to be directly accesible.

Oh, and the dispose method didn't quite work. I think it completely trashes the bitmapdata, as I got invaled bitmapdata errors. Using fillrect() instead did the trick.

Quote:

---

Originally Posted by TOdorus

I'll probably be chasing bugs for half a day.

---

We should all be so lucky. :)

Honestly, sprite sheets are still the way to go. You can load different for different objects though, say one for the tiles and one for the interactable objects, one for the characters (or a seperate one with each character so the engine can be simplified), etc. Personally I've switched everything over to spritesheets because in the end it just makes the engine that much simpler to code. For example, the character sheets from the Charas character generator: I wrote a simple class that attaches the bitmap to an mc with a scrollrect for easy scrolling. I can post an example later today if you want.

Thanks for the offer IP, but I'm almost done. Still, got one hell of a bug, maybe your experience could offer some insight.

With every rotation I calculate the position of the corresponding reference point. With testing I've concluded that the reference point is spot on for every rotation. I translate the graphic to make it rotate over the reference point.

Code:

---

var RelX:Number = (X - ScreenX) - RefVector.X
var RelY:Number = (Y - ScreenY) - RefVector.Y
var RelPoint:Point = new Point(RelX, RelY)
Screen.copyPixels(SHEET.Sheets[FRAME],Rect,RelPoint,null,null,true)

---

Now when I use this, the graphic... well it jitters a pixel or two off the actual reference point. When I remove -Refvector from the two lines, there's no jittering and it rotates over the center of the image (as it was prerendered).

Since testing shows that my RefVector is correct and omitting it shows the prerendering has gone correct, I'm only left to think it's in the copypixels method. This is quite odd, as I've used the same technique before, with the method of loose bitmapdata's, and the problem wouldn't arise. :confused:

The bughunt continues.

Edit:

I just found out my 'old' way of prerendering and rendering actually jitters more, I guess the constant movement hides it. I'm starting to think this is a copypixel problem. Pixelsnapping?

Well, I updated the link with the spritesheet version and it looks ok. Even just with one unit roving around I wouldn't notice the jitter.

I've implemented pooling for the projectiles to reduce overhead some more, but I was also looking for a way how to efficiently write away data. This is the battle part of the game I want to create, where armies/fleets clash. I also want a bigger World part in which these confrontations are set up. To get the idea, think of "Pirates!"

Basicly data on a few standard AI fleets need to be stored as well as what an outpost/city/planet/whatever has to offer. Currently I was thinking of using 2-dimensional arrays for a fleet, with every unit having it's own array of attributes, and objects for towns.

Are there any better ways of going about this?

Edit:

Something else I've noticed: when I close down Flash, restart and run the file again, my total memory usage can drop up to 4mb!