When I started my Flash project, I didn't know anything about blitting. I intended for it to play at 60 FPS, but it frequently dips into the 40s on a high-end machine and worse on lower-end machines. All of the game artwork is vector because I liked how it's perfectly scalable, for cases where you want to zoom in, or if the user is playing full screen on a high resolution display.
Then I learned about blitting and did some experimenting with positive results. But before I write a blitting engine, I was wondering what kind of performance I could expect. My Flash is set to 60 FPS and I'm going to use an EVENT.ENTER_FRAME to call my blit function, which would then go through each of my background, midground, and foreground vector art Sprite layers and create bitmaps by using BitmapData.drawWithQuality before copypixeling them onto my canvas bitmap. I plan on scaling my vector layers and canvas bitmap resolution up to the user's full screen resolution, which could be something huge like 4k. Those could be some huge bitmaps with huge draws occurring at a high rate. Can I really expect to get 60 FPS if I go through all this effort?
Related
My team is currently working on a rather large Web application. We have switched from the flash platform to Html5 in hope for a one size fits all platform.
The UI, is mainly based on createjs, which I by the way really enjoy working with.
However we have now reached the maturity phase and started optimizing some of the animations, that doesn't run smoothly in especially IE.
The thing is that we have a around 1500 sprites (pngs & jpgs) which is drawn onto a stage. We only draw around 60 of them per frame.
They are rather large (up to 800x800 pixels), and the application engine can choose which 60 to show more or less randomly.
The images are packed in a zip file and unpacked in the browser and Html images are constructed by converting the binary data to a base64 encoded string, which is passed to the src property of an image.
So in each frame render a set of around
60 images are drawn to the stage. And this is for some reason slow.
I have therefore used some time to experiment with the Spritestage of createjs to take advantage of Webgl, but with only small improvements.
So now I'm considering to pack our sprites in a spritesheet, which results in many sheets because of the large amount of data.
My question is therefore:
Would spritestage gain any improvements if my sprites are spread across multiple sheets? According to the documentation only spritesheets with a single image are supported.
Best regards
/Mikkel Rasmussen
In general, spritesheets speed up rendering by decrease the number of draw call required by frame. Instead of say, using a different texture and render for every sprite, spritesheet implementations can draw multiple sprites with one render call, provided that the sprite sheet contains all the different individual sprite images. So to answer your question, you are unlikely to see performance gains if the sprites you want to draw are scattered on different sprite sheets.
Draw calls have significant overhead and it is generally a good idea to minimize them. 1500 individual draw calls would be pretty slow.
I dont know if it this is applicable to your situation but it is possible your bottleneck is not the number of draw calls you dispatch to GPU but you are doing too much overdraw since you mention your sprites are 800x800 each. If that is the case, try to render front to back with the depth test or stencil test turned on.
I'm using Starling framework and Flash Builder.
I have big map image(around 5500x4500px) where player is flying around. It is non repeative, not tile based but vector based.
I'm moving camera around following player on each enterFrame event, camera displays approx 800x400 part of map per frame. Camera movemet is simulated by changing X and Y coordinate of maps parent DisplayObject.
What is the best way to draw this and have stable 60fps?
What I have now(attemp with max FPS on mobile):
9 Starling Images with max texture size: 2048x2048(or less on edges). I get 53-60 FPS, but I need stability, I feel like I'm hitting rendering limits already.
What I tried(gives less FPS):
Drawing sprites for each seperate map object(much more than 9 but smaller size)
Using CullingSprite(not rendering itsel when not visible)
Really you only need 4 images the size of your screen which wrap around and sample from the texture atlas. And for a starling implementation movieclips are great because you can just change its contents to a different frame or portion of the texture atlas. This way you aren't deleting and creating new images every time you need to wrap.
Batching is also one way you can improve on it, moving all samples as a single unit.
I am creating a bejeweled style game using flash builder for the web and I am wondering if it would be best (higher framerates, less render intensive, fast on all types of computers) to use the native rendering of actionscript 3 (display lists) or the gpu rendering of the Starling 2D Framework? My reasoning for wanting to use the native flash rendering is because from my research I understand that flash will utilize redraw regions and only redraw portions of the stage that need to be updated whereas starling will re-render the entire stage every frame. In a bejeweled style game there are many static objects and fewer dynamic objects so generally the entire stage does not need to be redrawn every frame, only small portions of the stage. Would it be better for performance to stick with the native rendering calls of actionscript 3 or would it be wiser to use the starling framework to utilize the gpu to accelerate the rendering? Any perspective would be much appreciated. Thanks.
Starling will be faster if you are using images, particularly on mobile.
The static regions can either be rendered as a single Sprite, or you can flatten it at runtime to improve the performance.
If you are drawing, in Starling you'll need to draw to a bitmap and then use that as a Sprite. You'll get better performance if everything is in the same sprite sheet, however.
While it's true that Starling draws every frame, it's a different sort of operation. Here's what actually happens:
1) The textures (images) being used by the app are uploaded to the GPU. This is done once.
2) Each frame, Starling tells the GPU "render this texture at this position with this scale and rotation". This is called a "draw call" but it's extremely fast. The slick thing with Starling is that it can batch these draw calls under certain circumstances to get serious speed improvements.
So yes, everything is "redrawn" each frame, but the GPU's hardware acceleration is used.
On mobile, Starling (or similar) is really the only way to do something at 60fps.
I'm making a fighting game, so I have giant character sprites (300px X 350px) with lots of frames of animation (~150 per character), so the maximum 2048 x 2048 texture size won't fit all frames of animation for a character. So, I'll need multiple TextureAtlases, right?
Do I need to worry about the costly GPU texture swapping, then, if I'm switching TextureAtlases on a MovieClip?
To change animation frames, would it be sensible to create a manager to select the frame and the atlas?
Or can I combine TextureAtlases so that one atlas stores multiple 2048 x 2048 sprite sheets?
How would you approach this?
A recommendation from Daniel Sperl on the Starling forum:
If you're sprites are so huge, I'm afraid you'll run into problems
with texture memory. Unfortunately, there is no easy workaround for
that at the moment, except creating that animation with "Spriter"
(beta):
http://www.kickstarter.com/projects/539087245/spriter
Consider whether you can reduce your animation demands by doing skeletal animation. Instead of drawing every single frame of your character directly into textures, break the character up into animatable parts, position the parts using transforms and then composite them into your animation frame at runtime. It's a fighting game, so this should be manageable (presumably you only have two animated characters, plus perhaps some relatively inexpensive environmental effects). As a result, you only need each unique part of each character, which should drastically reduce your texture budget (but increases the complexity of your animation engine).
You might look at DragonBones (http://dragonbones.github.com/getting_started_en.html) for help in achieving that.
Where is this 2048 x 2048 limitation documented? I've never read such a thing. The only thing i could find in the Starling 1.1 documentation concerning texture atlas size is:
Any Stage3D texture has to have side lengths that are powers of two.
Starling hides this limitation from you, but at the cost of additional
graphics memory. By using a texture atlas, you avoid both texture
switches and the power-of-two limitation. All textures are within one
big "super-texture", and Starling takes care that the correct part of
this texture is displayed.
Assuming i haven't completely missed this important detail and there is no size limitation on texture atlases, just create a one at 4096 x 4096 or 8192 x 8192.
hmm - my guess is that using textures larger than 2048x2048 has an effect on performance. And i would further posit that shifting between textures of that size will also cause performance to take a hit. Have you looked into scaling down your texture assets and upscaling them in the game?
I'm making an action game and I'd like to know what should be the maximum size of the stage (mine is 660 x 500).
Also I'd like to know how big a game-sprite should be. Currently my biggest sprites have a size of 128 x 128 and I read somewhere on the internet that you should not make it bigger because of performance issues.
If you want to make e.g. big explosions with shockwaves even 128 x 128 does not look very big. What's the maximum size I can definitely use for sprites? I cannot find any real solution about this so I appreciate every hint I can get because this topic makes me a little bit nervous.
Cited from:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/DisplayObject.html
http://kb2.adobe.com/cps/496/cpsid_49662.html
Display objects:
Flash Player 10 increased the maximum size of a bitmap to a maximum
pixel count of 16,777,215 (the decimal equivalent of 0xFFFFFF). There
is also a single-side limit of 8,191 pixels.
The largest square bitmap allowed is 4,095 x 4,095 pixels.
Content compiled to a SWF 9 target and running in Flash Player 10 or
later are still subject to Flash Player 9 limits (2880 x 2880 pixels).
In Flash Player 9 and earlier, the limitation is is 2880 pixels in
height and 2,880 pixels in width.
Stage
The usable stage size limit in Flash Player 10 is roughly 4,050 pixels
by 4,050 pixels. However, the usable size of the stage varies
depending on the settings of the QUALITY tag. In some cases, it's
possible to see graphic artifacts when stage size approaches the 3840
pixel range.
If you're looking for hard numbers, Jason's answer is probably the best you're going to do. Unfortunately, I think the only way to get a real answer for your question is to build your game and do some performance testing. The file size and dimensions of your sprite maps are going to effect RAM/CPU usage, but how much is too much is going to depend on how many sprites are on the stage, how they are interacting, and what platform you're deploying to.
A smaller stage will sometimes get you better performance (you'll tend to display fewer things), but what is more important is what you do with it. Also, a game with a stage larger than 800x600 may turn off potential sponsors (if you go that route with your game) because it won't fit on their portal site.
Most of my sprite sheets use tiles less than 64x64 pixels, but I have successfully implemented a sprite with each tile as large as 491x510 pixels. It doesn't have a super-complex animation, but the game runs at 60fps.
Bitmap caching is not necessarily the answer, but I found these resources to be highly informative when considering the impact of my graphics on performance.
http://help.adobe.com/en_US/as3/mobile/WS4bebcd66a74275c36c11f3d612431904db9-7ffc.html
and a video demo:
http://tv.adobe.com/watch/adobe-evangelists-paul-trani/optimizing-graphics/
Also, as a general rule, build your game so that it works first, then worry about optimization. A profiler can help you spot memory leaks and CPU spikes. FlashDevelop has one built in, or there's often a console in packages like FlashPunk, or the good old fashioned Windows Task Manager can be enough.
That might not be a concrete answer, but I hope it helps.