this is a newer version to a question i have asked before but have not received an answer to.
I am developing a mobile AIR app with many animations and tests have shown that using bitmaps and GPU rendering give the best performance across all mobile models. I receive normal vector animations from the app's artists, and have built a system which loops through these animations at runtime and draws the content into bitmapdatas.
my concern is looping through the movieclip's frames. If I have these lines of code:
for (var i:uint=1; i<mc.totalFrames+1; i++) {
mc.gotoAndStop(i);
bitmapData.draw(mc);
}
I can't be sure the frame got "constructed" before being drawn, and my tests with an Android tablet prove this right - sometimes frames aren't drawn.
This mc is off the display list obviously (we dont need to render to the screen). So is there a way to make sure the frame has been built before drawing it to a bitmapdata? (and waiting for FRAME_CONSTRUCTED, EXIT_FRAME, etc.. is obviously slow and unneeded)
any ideas?
thanx
Saar
more info to clarify:
this is a children's book. each page has animations in it. all these animations are vector animations in timelines in FLAs I receive from the devloping artists (not the users).
Every page has an FLA which i publish to a swf.
what i actually do is replace vector animations in loaded SWFs with bitmap version of them.
At app runtime, upon each new page, i load the swf, go though all the animations in it (looping through the content's children) and each movieclip i rasterize into array of bitmapdatas.
My custom "Bitmap Movieclip" places on the displaylist a replcaement bitmap for each movieclip, and on ENTER_FRAME i switch the bitmaps' bitmapdatas from the array.
this gives very hight performance
I'd suggest use a splash screen, and place your MC to be converted to the bitmap to the stage first, then draw to your bitmapData. Several issues had me force to put a DisplayObject being drawn to the stage before actual drawing once already, so this might be a quick fix for you too.
var splashBD:BitmapData=new BitmapData(stage.stageWidth,stage.stageHeight,false,0xffffff);
var splashBM:Bitmap=new Bitmap(splashBD); // draw a thing as needed here
addChild(splashBM);
addChildAt(MC_to_convert,getChildIndex(splashBM));
// then advance it by frames and draw.
sorry MY BAD
waiting for FRAME_CONSTRUCTED is the answer
Related
So for my latest Flash project, I'm designing a game. The dimetric character can move in 8 directions. I've been given the spritesheets for the hats, hair styles, etc., that the player can wear.
The spritesheets contain the images for each direction, AND they contain four frames of animation (four per direction) for when the player is walking. This is basically the layout of the Spritesheet (and all of the files and "frames" are the same size, which makes things easier):
[IDLE] [WALKING]
[S][SE][E][N][NW][W][S1][S2][S3][S4][SE1][SE2]...
My goal is to embed all of the items in a single file other than the main one. But I need to implement walking animation.
One thought I had is to set the main SWF's framerate to 7 FPS, then use an Event.ENTER_FRAME handler to alternate between the walking ones. Programmatically animating.
Another thought is to create SWFs for each item of clothing, then use motion tweening to move the spritesheet symbol over the stage.
What I'd really like it so avoid using Adobe Animate entirely. Even if there's an approach that requires the use of Flex, I'd take it if it meant saying goodbye to graphically-designing.
using flash builder (flex) does not mean that good bye graphic! there is a relationship between Adobe Flash and any As3 Ide like FlashBuilder or FlashDevelop.
exporting movieclips and everything in library with .swc format, and then importing it by the IDE, read this
My goal is to embed all of the items in a single file other than the
main one. But I need to implement walking animation.
One thought I had is to set the main SWF's framerate to 7 FPS, then
use an Event.ENTER_FRAME handler to alternate between the walking
ones. Programmatically animating.
i dont undrestand! why 7 fps and also why Event.ENTER_FRAME
there might be a character movieclip, whit above frames in its time line, well! to playing any animation (for particular direction) you have to call mc.gotoAndPlay("walk_S"); then it will be played automatically, if you need lower frame rate, only select each frame by mouse pointer and then press [F5] in time line to insert a blank frame gape between keyframes.
as i said before, you must use a callback script at the end frame of the each loop animation like walk_s walk_ne ...
also idle animations must be called like it: mc.gotoAndStop("idle_s");
I am making a game in AS3 for a school project (using the AIR api). I have about a year's worth of experience in AS3, so i would say i'm proficient but not an expert. Anyway, i have never attempted to do sprite animations in AS3 and i'm not quite sure how to approach it.
If i create a list of bitmaps and call addChild() and removeChild() to display each frame of the animation, it would affect the framerate as these functions are not very efficient (i have tried this before and it tanked my framerate if i had too many animations going at once). I have also tried creating a list of BitmapData objects, adding a bitmap to the display list, and then pointing it to a different BitmapData each frame, but this does not seem to work at all.
So what is the best way to do this? In XNA, for example, i would create a sprite class that draws to the screen using a sprite batch, then i would create a list of sprite objects and cycle through them to create the animation. Is there any way to achieve a similar result in actionscript?
First (simple) method: you can just use multi-frame MovieClip for animation. Put an image in each frame, put a MovieClip on the stage and that's all. You can control this animation using play(), stop(), gotoAndPlay(), gotoAndStop(). It will work without much problems for a generic platform game (I did that myself long ago).
Second (advanced) method: use bitmap blitting. For each animation, create a bitmap image that holds each frame of the animation. Use this image as a source for copying pixels into your current animated object. You just need to copy a particular rectangle area inside a source bitmap that corresponds to the current frame.
The actual blitting happens here
destinationBitmapData.copyPixels(sourceBitmapData, areaRectangle, destinationPoint);
Where destinationBitmapData is your "canvas" that you're blitting to; sourceBitmapData is the source image holding all animation frames; areaRectangle is the Rectangle inside the source image defining which area to copy; destinationPoint is left-top coordinate of the copy area in your canvas.
The destination canvas can be just one small object (like your game character that is moving around) or the entire game screen with all objects. I.e. instead of blitting and adding each object separately, you can just have one big canvas and blit any necessary parts directly to it.
That said, there is already a number of various ready-made engines that use blitting and even advanced techniques like 3D acceleration for 2D sprites.
One of them is Starling.
I have a MovieClip in Flash with 100 frames. Each frame contains a certain icon I need to use in a project. I create instances of this icon MovieClip wherever I need an icon to appear, and gotoAndStop to a certain frame to display that icon.
Will storing a 100 icons in a single movieclip cause every single icon to be created in memory whenever I create an instance of the MovieClip? If I stored each icon in the library and attached only the icon that is needed, would that consume less memory than creating this MovieClip that has all the icons in it?
To answer your question: When you go to a frame with an icon on it, Flash will create a new instance of that icon. When you leave that frame, Flash will make that icon eligible for garbage collection, unless you force it to hold the instance in memory somehow, such as using addEvenListener where the method that is the listener is the icon or somewhere inside it.
I think the memory usage is likely to be higher for the goToAndStop vs. the new instance. If you are not experiencing problems with goToAndStop(), you are unlikely to experience additional issues by instantiating a new icon each time you switch from one icon to another. The other people who have answered are quite right that you will use fewer CPU cycles by instantiating all the icons only once (by whatever method), and then simply using the same one every time you use that icon. However, your overall memory footprint will be higher, because you will have all of the icons (even ones you are not currently using) in memory all the time.
If you want to go the route of only instantiating each on once, I'd suggest you go with Lazy Loading, where you only instantiate each icon when it is first used. One way to do this is to use what you already have and visit the frame the first time you want to use a specific icon, then store the BitmapData or a reference to the icon itself after that and reuse it. Another way is to build a swc and use a similar pattern.
None of this requires a static variable BTW, since it sounds like you're not using tons of different copies of your icon MC. Even if you are, it's probably better to handle referencing the icons you have through dependency injection.
I think you are probably asking about file size, however, vs. actual memory usage. The answer to that questions is that all assets that are used by your fla get compiled into the swf, regardless of whether they are in a MovieClip, a SWC, or in the library with Export for Actionscript in Frame N checked.
I get it, I've got boobs, I'm guessing
Try this, to verify my "guess."
Create a swf that has a keyframe on frame 1.
Draw a circle there.
Put another keyframe on frame 10. Draw a square.
In Publish Settings, check "Generate size report."
Now, you know (or you should know) that this swf can display the circle on frame 1, even if the assets compiled on frame 10 have not yet been downloaded. So, is there any possible way that the square could be loaded into memory before Frame 10 has been downloaded? Hint: the answer is no.
Now ask yourself this: Do you think Macromedia wrote a special version of MC that is incapable of lazy loading that the MC that is the main Document Class that Flash generated for the movie you made above so obviously handles so well?
The Macromedia engineers did a lot of things that in hindsight look pretty stupid, but they're not that incompetent.
If each icon that goes into the 100 frames MovieClip is an image you can easily enough export that image for actionscript and access only the image you need.
Another idea is to create a static class that stores each icon frame as a symbol in a static array(if you want to access the icon by index) or Dictionary(if you want to retrieve it by name).
e.g.
package{
import flash.display.Bitmap;
public class Icons{
public static const assets:Vector.<Bitmap> = Vector.<Bitmap>([new Icon01ASExportName(),//instance bitmaps once
new Icon02ASExportName(),//reuse them later multiple times
...
new Icon99ASExportName()]);
}
}
Yet another is to generate a SpriteSheet, either once and save it as a file, either at runtime, then copyPixels() to paste the icon from the right rectangle of the main spritesheet. You've got multiple tools available for generating the spritesheet:
Zoë
SWFSheet
Flash CS6
TexturePacker (if you have movieclips, you can export them as an image sequence to drop into the software)
There are also ways to generate a spritesheet at runtime.
For some nicely explained video tutorials on spritesheets and BitmapData by Lee Brimelow: Sprite Sheets and Blitting - Part 1,2 and 3.
If your icons are Bitmaps then each movieclip will share the same data - the only memory increase will be due to more movieclips, rather than their contents (which shouldnt be a problem).
If your icons are not Bitmaps (other movieclips, shapes, buttons etc), then everything gets duplicated, so memory usage will increase a lot faster as more movieclips are added.
Another consideration is that lots of movieclips on screen will have more of an effect on FPS than simpler objects so you may want to consider adding the icon itself rather than the movieclip even if you are using Bitmaps.
I'm making an animation of a 2D character that can walk, run, jump, bend,...
Would it be better to load one big 'spritesheet' with all the animations and just use a mask, or would loading separate files (walk, run,...) be better because you're not using a mask on such a big image every frame?
I'm not using the Stage3D features with a framework like Starling because I think the normal flash display API is fast enough and has much less bugs than the relatively new GPU frameworks.
Blitting just the character (using lock(),copyPixels(),unlock()) works pretty well.
private function updatePixels():void{
//update sprite sheet copy position based on the frame placements ons prite sheet
position.x = spriteSourceData[currentFrame].x + offset.x;
position.y = spriteSourceData[currentFrame].y + offset.y;
//draw into the bitmap displayed
displayData.lock();
displayData.fillRect(displayData.rect, 0x00FFFFFF);//clear
displayData.copyPixels(sourceData, spriteData[currentFrame], position);//copy new frame pixels
displayData.unlock();
}
//a bit about vars:
position:Point
spriteSourceData:Vector.<Rectangle> - from parsed Texture Packer data
offset:Point - front view and side view animations weren't always centred, so an offset was needed
displayData:BitmapData - pluging into a Bitmap object displayed
sourceData:BitmapData - the large sprite sheet
currentFrame:int - image index on the sprite sheet
I've done this on an older project writing a custom class loosely following what I've learned from Lee Brimelow's tutorial series Sprite Sheets and Blitting (Part 1,Part 2, Part 3)
In short, you'd use two BitmapData objects:
a large sprite sheet
a small image to display just the character (size of the largest character bounding box) to copy pixels into
In my project I had a character with front and side animations and for the sides I've used one set of animations and used the Matrix class to flip(scale and translate) the side animation accordingly. I've used TexturePacker to export the image sequence as a sprite sheet and the frame data as well as a JSON object. There is native JSON support now, so that's handy. Texture Packer isn't free but it's really worth the money (affordable, fast and does the job perfectly). I haven't used Flash CS6 yet but I imagine it's also possible to import your image sequence and export a spritesheet with the new feature.
In my experience the rule "the simpler the display list the better the performance" generally applies. Which means you should use the most specific display object that will do the job (don't use a Sprite when a Shape would be sufficient or favor Bitmaps over vectors where it makes sense).
The most extreme version of this is to only have one Bitmap display object on the stage and use copyPixels to draw all game objects into it every time you want to update the screen. It doesn't really matter what the source in the copyPixel call is, it could either be a large BitmapData acting as a sprite sheet or a small BitmapData objects representing a single frame in an animation. This method is really fast and you could easily have many hundreds of objects on screen at the same time. But using copyPixels means you can't scale or rotate a game object, so for those cases you would have to fall back to the much slower draw() method. Of course this single Bitmap method is not suitable for games where you need to attach mouse events to specfic objects in the game, but works well for shoot'em ups or platform games.
To answer your question, I think you will get better performance by using a single Bitmap display object to represent the player and a collection of BitmapData objects for all the animation frames. Then you can just change the Bitmap's bitmapData property to the frame you want to display. You can still load a large spritesheet png and then plit it up into a series of BitmapData objects during the initialization of the game.
I'm working on a small game in Flash (AS3) that generates levels using small tiles.
The location,width,height and other properties of the tile are stored in an array upon generation. Each tile is added to the same container movieclip. When all tiles have been generated, the container movieclip is converted to a bitmap, all tiles are removed from the stage, and the original container is removed from the stage and then deleted. The bitmap is the only remaining "graphic" on the stage, aside from the player.
This yields far better performance than allowing all 60,000+ tiles to be rendered individually during gameplay; however, the framerate still reduces as the number of tiles is increased. This makes no sense, as all the tiles are added to a single bitmap that is always the same size, regardless of the amount of tiles.
With 20,000 tiles during generation, the game runs at the full FPS, but with 60,000 it runs relatively choppy, probably around 4-5 FPS.
I've removed collision detection and any/every script that runs through the tile array to rule out the possibility that some other CPU intensive part of the script is lagging the framerate.
Any idea why, despite the fact that all tiles have been removed from the stage and their container is deleted, the game is still running slow even though the background bitmap contains the same amount of data regardless of the number of tiles generated?
Here is the last part of the level generation algorithm which converts the container movieclip to a bitmap and then removes all the tiles:
var temp_bitmap_data:BitmapData = new BitmapData(this.stage_background_mc.width,this.stage_background_mc.height);
temp_bitmap_data.draw(this.stage_background_mc);
this.stage_background_bitmap = new Bitmap(temp_bitmap_data);
main_class.main.stage.addChild(this.stage_background_bitmap);
for (var block in blocks_array)
{
//every block in blocks_array has a child that is the actual graphic of the tile
blocks_array[block]["block"].removeChild(blocks_array[block]["block"].getChildAt(0));
if (blocks_array[block]["type"] == "bg_block")
{
this.stage_background_mc.removeChild(blocks_array[block]["block"]);
blocks_array[block]["block"] = null;
}
if (blocks_array[block]["type"] == "path_block")
{
//path_blocks have a second child in addition to the first one that's already been removed. the second child is the only other child
blocks_array[block]["block"].removeChild(blocks_array[block]["block"].getChildAt(0));
this.stage_background_mc.removeChild(blocks_array[block]["block"]);
}
}
this.stage_background_mc = null;
[Edit]
Here is a picture of the game to give you a better idea of what's going on:
[Update:]
Even removing the final created bitmap from the stage, ending up with only 1 child on stage, and setting that removed bitmap to null doesn't improve the speed.
A couple of thoughts.
First, you're sorta half taking advantage of AS3's quick work with blitting. You've got the right idea about having only one single Bitmap on the stage, but the steps before (adding DisplayObjects to a MovieClip and the doing draw on that MovieClip) isn't the fastest process. For one thing, BitmapData.draw is slower than BitmapData.copyPixels (here is a post on that). One of the best ways to get speed is to pre-blit all of your graphics, and store them as BitmapData. Then, keep Object references (containing position, etc) for each graphic. In your render loop, run through each object, and use copyPixels to copy the graphic's pixel information to the appropriate positon in your single, on-stage Bitmap. This way, all slow BitmapData.draw commands have happened upfront, and now you are just pushing pixels, which Flash is really fast at.
That process isn't without its downsides, however. For instance, you can't do easy transforms with it. You'd have to pre-blit all frames of a rotation, for instance, in order to rotate the individual graphic (since you can't rotate a BitmapData, and you aren't using draw on a DisplayObject). Still, it is mighty fast if you can live with the limitations.
Here is a post that serves as a tutorial of the process I explained above. It is old, but informative none-the-less.
Finally, 60,000 is a very large number. Flash isn't exactly a "speed demon." No matter how optimized, eventually you'll hit a limit. Just something to keep in mind.
Oh, and this additional post gives some great tips on performance in Flash.