[DISC] When is BitmapData necessary? Some rendering questions.

[Alluvian]

The help for the BitmapData class says:

The BitmapData class lets you create arbitrarily sized transparent or opaque bitmap images and manipulate them in various ways at runtime.

This class lets you separate bitmap rendering operations from the Flash Player internal display updating routines. By manipulating a BitmapData object directly, you can create very complex images without incurring the per-frame overhead of constantly redrawing the content from vector data.

The bolding is mine, and it is what I would like to discuss. I apologize if this has been done to death, the search keeps timing out on me

Lets say I have a movieclip that is a series of image files (.jpgs or .gifs) with no vector data. Just a flipbook/sprite essentially with the different animations packaged together. If I take this movieclip and place it on the stage, is flash doing any unnecessary work that would be helped by using the BitmapData class? As you can tell, I don't know much about the class and am wondering if I should be learning it.

I don't think it will be much of a problem with my current project (being turn based and all), but I would like to be aware of better ways of doing things before I get into bad habits. The game is basically a tilebased game with movieclips thrown on a scrollable 'playfield' movieclip so the player can move and scroll it easily to plan, and the game engine can move and scroll it to highlight what is happening while the turn is playing out.

[mr_malee]

i think yes, flash is re-drawing it, unless you either convert it (like you said) to bitmapData or simply set its "cacheAsBitmap" property to true.

And yes, you should learn to use bitmapData, its very useful in game development

[tomsamson]

no, raster art that doesn´t change doesn´t get redrawn. You can easily check what gets redrawn by testing your movie in the flash ide, right click and choose show redraw regions.
Still,yup, its less ressource/performance demanding to have your tilebased engine bitmapdata based rather than handling several movieclips (since mcs cost quite some ressources)

[mr_malee]

whoops

[renderhjs]

from my understanding certain methods like scrolling can be done quicker with bitmap data instead of movieClip tiles (each tile a movieClip).

I read that papervision and some other engine (wich name I can´t remember) use pixel by pixel drawing wich seems to be very fast in as3. Even the not long ago doom flash clone showed what loops with pixel placement can archive regarding performance.

I´ll write another linear texture mapping demo in as3 to see if drawing within a loop (x*y) is really that faster as using for example the drawing api with a beginBitmapFill with a matrx applied to the bitmap.

Anyway in the past one would for example for a raycasting engine duplicate a Movieclip assign a mask dynamicly and scroll the movieClip while the mask stays static. This all now can be simplified by just using bitmapdata so imo. its a very interesting topic as one has to use different techniques to get better performance as the classic way.

[tomsamson]

papervision does not do pixel by pixel drawing and sorting,that´s the main reason why it has sorting issues in various scenarios. Maybe you mixed that up with the custommedia engine.
pixel by pixel drawing is still not that fast in as3 (since besides using the latest beta player the rendering side isn´t much different with as3/f9 player), what makes that doom demo so fast is that it doesn´t use a polygon texture 3d mapped approach for simulating the 3d effect.
And yup,beginbitmapfill is still slower than actually dealing with a bitmapdata since when you use beginbitmapfill what´s used to render the shape is the old vector renderer which yeah,is slow.
Sure though,when compared to masked movieclip type approaches of pre f8 days its faster

[Alluvian]

Interesting. I will definitely look into bitmapdata. I might still use more movieclips on this project than optimal because speed is not too big of an issue being turnbased and all.

I think my first step when I restart the coding will be to form a quick and dirty worst case scenario with everything a movieclip running on a slow computer and see how bad the hit is. I think learning bitmapdata for the tiles will have enough of a payoff to make it worthwhile, and then when I do the final spritework I can use whatever I learn to do the best I can do at my knowledge level.

[Alluvian]

My project is going to have fixed mapsizes depending on the number of players / personal tastes of the players / gametype. It is a turnbased game, so fps is not critical, but running nice would be preferable of course.

Without any playtesting yet, I am thinking that the grid would be 32x32 to 64x64. The problem is that it is a sea based game and I was planning on having the ocean tiles be animated. I don't think cacheing as bitmap will help me at all with an animated tile, so that leaves me to wonder if anyone has any optimization tips?

The obvious one is to only draw tiles that are on the screen. Would turning the offscreen tiles to visibility = false do the trick or should I use removemovieclip and then re-create them if the screen comes back to them?

The problem is with this being a strategy game, I would want the player to be able to zoom out to see the whole map. I am thinking that at a certain zoom level the animated ocean tiles would replace themselves with non-animated pure blue clips. Would this even make much of a difference (it would still be a silly number of movie clips on screen at once)? Would the screen suddenly redrawing itself with new tiles be a huge framerate hit when the transition occurs?

Any suggestions? Maybe cap zooming out to a reasonable level and include some kind of overhead map made with the bitmapdata class pixel by pixel?

[ImprisonedPride]

If I understand what you are saying, I think you have the idea of a bitmapData tile based engine wrong. The idea is that instead of an mc holding a frame of a graphic, each "tile" is nothing more than an object that holds data about the tile it represents. The entire map is built into a single bitmapData object at runtime, and only a rectangle the size of the viewable playarea is selected and displayed on the screen on any given frame.

[Alluvian]

Yes, I do not yet understand a bitmap tile based engine, my understanding is that it does not handle scaling and rotation well, which is something I will be doing. Scaling a LOT, rotation a little.

So instead I was going to simply place tiles on an object we can call 'canvas' and then just resize/move/scale canvas. I have done it in another project

The second post suggested cache as bitmap which I don't think helps when scaling much either.

My tests are working out pretty well in terms of the kind of performance I need (turning the offscreen movieclip tiles to _visible=false, but I have yet to try it on a really crappy computer.

I could be wrong, and maybe I can do scaling well with bitmapdata. I haven't found a great post about it yet, other than the one in the knowledgebase post which is probably way out of date, and most of the discussion in the thread mentions another engine "gotandstop" that would handle a full screen of tiles better (but the board search is still timing out on me for the third day running).

I am really just looking for ways to minimize the hit of more tiles on screen when I zoom out. I was wondering if a swapout to a less detailed (solid color, non animating) tile would help.

Anyway, performance and fps isn't much of an issue for me, so just ignore the question I guess.

[tidenburg]

cacheAsBitmap was a godsend in my lemmings game. It ran fine then I added more characters and the game began running insanely slow. Then I used cacheAsBitmap on all my players, tiles and objects and it runs great now.

[Alluvian]

It helped even with the animated characters? Guess I'll just have to do some experimenting with it.

As far learning how to do a tile engine RIGHT, I'd love to if it would allow for easy scaling as well, most of what I see is just about panning quickly. Does it allow for easy scaling as well?