Optimizing a Flash Game for Mobile?

[DigitalDesignDude]

Good day,

I'm currently developing a side scrolling arcade flash game for PC and Mobile to use as my thesis project for a college multimedia program. The problem that I'm running into is the game is running very slowly on mobile devices in comparison to other flash games on the android store such as "Super Toss the Turtle". It amazes me how large the levels in that game are and how much vector art is in it while still running at what feels like 60 FPS on my underpowered android phone. My college does not have any instructors who are well versed in Adobe Animate CC and for the most part I and other students have to teach ourselves. 

I feel as though I'm missing something other than caching movie clips as bitmaps. Would anyone be able to take a look at my prototype below and see what more I need to do to make it run at a professional standard on mobile? My actual project has a lot more detailed vector art in it and typically runs at a lower frame rate of 20 fps on my Samsung Tab 4.

sidescrollerPrototype.fla - Google Drive

I am very curious to hear how most people make their flash games mobile apps so any tips, resources, or development advice is very much appreciated.

Thank you.

[Colin Holgate]

Begin by caching the vectors as bitmaps, meaning at the lowest level. Don't cache the man, do cache the body parts.

Set the Render mode in publishing settings, general tab, to GPU.

Those two things should improve things a lot, and you could start with just the render mode change, see how much that does on its own.

[DigitalDesignDude]

I tried setting the render mode to GPU and it did improve the performance of the prototype very much so. However, when I tried it on my actual project the frame rate went down significantly  and some of the background art went missing. I have a lot of vector brush strokes to make up the game's background and the player's character has more detailed vector art as well. I cached the character's body parts and the game background as bitmaps but it still runs sluggishly.

Are there any more solutions for increasing the performance of the game while having detailed game art?

Here is my main project Animate CC file if it helps.

MainProjectSideScroller.fla - Google Drive

[Colin Holgate]

One problem with GPU render mode is that if you have a lot of unique images that are all cached, it will fill up texture memory, could cause corruption, or crash the app. If that's the case for you it could be with trying Direct rendermode. In Direct it's not using GPU texture memory, unless you're using Stage3D, but it does do fast blitting. That might be quick enough for you.

Something that would help quite a bit too would be to lower your expectations. Make the game work well at 24 or 30 FPS, and don't worry if you can't get 60 FPS. Pretty well all older console games were running at 30 fps, and you still enjoyed them.

[DigitalDesignDude]

That is good advice. So far the game is able to run at least 20 FPS using auto and direct render modes. Since I saw a few games running very well I originally thought I was doing something wrong but I guess it's just a matter of optimizing the game as much as possible or not using up all of the texture memory.

Would it be better if I just used PNG files for game's background or does cache as bitmap do the equivalent of that anyways?

[Colin Holgate]

A cached static vector image should be just the same as if it was a PNG. It's where you have constantly changing images that uses up texture memory.

One thing that could help a lot is to design your game at 960x540 instead of 1920x1080. Make the images be truly be for the 960 size (having them in something at 50% won't gain you anything). Doing that should reduce the demand on the texture memory to 25%. On HD devices it will look slightly softer looking, but should play a lot better, and worth trying GPU render mode again.

[ASWC]

That's not correct, while the cache creation can feel seamless on normal device, on weak ones you can directly see the power needed as the caching process for only a few vector can take measurable time. I did measure 500ms+ for a few vector on some very weak android device as opposed to nothing at all using bitmap directly, so the cache creation is a major difference and should not be ignored.

[Colin Holgate]

Cache on Export happens on your computer, at publish time. The device would never see any vectors.

[ASWC]

I see then in that case yes that should suffice for an improvement. Realtime caching or bitting or any bitmap manipulation will take power and time on mobile device and you see that when running on low end device (but that's still measurable with good device).

[Colin Holgate]

On the question of blitting, I have used that in apps where the graphics had so many unique frames. Those darn animators! By using Direct render mode the performance was good enough, and it didn't fill up GPU texture memory. In GPU mode the screen would start to get corrupted after a short while, then the app would crash.

Would be very handy if Adobe AIR could make GPUs handle vectors, in the way that Illustrator seems to.

[ASWC]

Well biting in direct mode is not per say bitmap manipulation as long as the raster data is uploaded to gpu anything can be done to it without overhead, in GPU mode everything has to be done in true bitmap manipulation and that is very CPU demanding on mobile device. AIR does offer some native caching when you embed your assets but even better is providing your own cache system on top of that (a lot of pooling)

[DigitalDesignDude]

I tried what was suggested and fortunately the game was able to run at 60 FPS on my weaker android phone. I set the render mode to GPU and for each body part I made sub movieclips that were set to Export as Bitmap.

Having a sub movieclip within each body part may lead to having a lot of symbols though. Especially when I get to giving the head different mouths for lip syncing to dialogue. At least this way, the parent head movieclip can be a graphic symbol for easier animation and the sub head movieclip will handle the Export to Bitmap requirement.

[Colin Holgate]

Yes, that should work. There is a thing called JSFL that could set things by script. It could go through every movieclip and if the movieclip has no instance name, only has one frame, and only contains shapes, set it to export to bitmap. But it's maybe not worth the time to research and test that. Just get into a habit of making the lowest non-moving part be a movieclip with that checkbox selected.

[Lars Laborious]

If you'd like to drop sub movieclips, I would recommend what Colin mentioned earlier: duplicating the inner layer containing your vector, make it a Guide Layer (invisible) for the possibility of later editing. Then select the visible vector and choose Convert to Bitmap, (I've added a shortcut for this in Animate).

It's also worth mentioning that the pixel size of bitmaps matter when using GPU. For larger graphics like backgrounds, try cutting it up in smaller chunks (e.g. 256x256).

[DigitalDesignDude]

I see what Colin means now, that is a great work around. It will definitely save me from making symbols for every facial expression. And if I if I wish to, I can easily remove the bitmap layer for the PC version and un-guide the vector layer so that it's back to looking sharp. Awesome! 

[Colin Holgate]

For the PC version you could guide the bitmap layer, and unguide the vector one. No need to delete them, except for drive space reasons.

[Colin Holgate]

By the way, each bitmap you make will have a generic name. It may be worth naming them in the library as you create them. Also, at the end you can select all of the bitmaps in the library at once, and click the i button to get their common properties. In there you can turn on Allow Smoothing, and also make them be Lossless (if they are flat colored areas they should still compress well, no need to make them be JPEG).

[ASWC]

Can you expand on your "pixel size" statement? What are the problems inherent with this, for which rendering mode and how to measure those problems?

[Lars Laborious]

Pixel size has to do with GPU efficiency.

You can read about it here: http://help.adobe.com/en_US/as3/mobile/WS901d38e593cd1bac-3d719af412b2b394529-8000.html

This old Adobe article is also worth a look: Sylvester's Band: An interactive children's book for tablets, smartphones

[ASWC]

I wasn't aware of this and now I'm interested in performance tests but I can't find any. Are you aware of a simple setup that allows to test the performance hit?

[Colin Holgate]

I'm skeptical about that too. There is this somewhat confusing bit of advice in the docs:

"Make bitmaps in sizes that are close to, but less than, 2n by 2m bits. The dimensions do not have to be exact powers of 2, but they should be close to a power of 2, without being larger. For example, a 31-by-15-pixel image renders faster than a 33-by-17-pixel image. (31 and 15 are just less than powers of 2: 32 and 16.)"

It could be they are trying to say that in sending the bitmap to the GPU, anything below 2^n x 2^m will be sent at 2^n x 2^m, and implying that something that is 2^n + 1 wide will be sent at 2^(n+1). If it's also 2^m+1 that would end up being a 4X size bitmap being sent to the GPU.

In terms of draw calls (if that applies to AIR, not sure) you would think that 1024x1024 would be a lot better than 16 256x256 graphics. I try to stay at or below 1024 across, for the benefit of older devices, but I wouldn't panic if I dared to use 2048.

One thing that does affect GPU memory usage is the true size of a bitmap you're sending. A 4096x4096 bitmap that is scaled on stage to 50% will take 4096x4096 amount of GPU, and not 2048x2048. Making the bitmap really be 2048x2048 would use a quarter of the GPU memory, even though it looks the same on stage.

[Colin Holgate]

I realized one flaw in my thinking, the benefits of 1024x1024 over 16 256x256 is only really of much use if you are using spritesheets. You would not want to make all your graphics be huge, just to make the most of what the GPU can do. AIR doesn't support spritesheets, so those benefits will have to wait until it does.

[ASWC]

This is for mobile AIR 2.5, I'm wondering how accurate this still is considering they recommend using cacheasbitmap in GPU mode while it is known doing this on mobile can produce rendering glitches.

Overall the recommendation makes sense if that means the rendering uses arbitrary power of 2 "canvases" to render everything as in if your object is 33 wide then a 64 sized canvas must be used, that sort of thing.

[zwetan_uk]

the advise like "Make bitmaps in sizes that are close to, but less than, 2n by 2m bits ..."
is due to the internal way SWF save bitmap data and calculte the size in TWIP

look in the SWF spec, chapter 1: Basic Data Types / Coordinates and twips

"

The SWF file format stores all x-y coordinates as integers, usually in a unit of measurement

called a twip. In the SWF format, a twip is 1/20th of a logical pixel. A logical pixel is the same

as a screen pixel when the file is played at 100%—that is, without scaling.

For example, a rectangle 800 twips wide by 400 twips high is rendered as 40 by 20 logical

pixels. Fractional pixel sizes are approximated with anti-aliasing. A rectangle 790 by 390 twips

(39.5 by 19.5 pixels) appears to have slightly blurred edges.

Twips are a good compromise between size and precision. They provide sub-pixel accuracy for

zooming and precise placement of objects, while consuming very few bits per coordinate.

Coordinates in the SWF file format use the traditional graphics axes: x is horizontal and

proceeds from minimum values at the left to maximum values at the right, and y is vertical

and proceeds from minimum values at the top to maximum values at the bottom

"

[ASWC]

I think this is the best setup for you for the minimum amount of work, congrats on getting 60fps.

With any technology, multiplatform development requires often different asset types and different rendering for different platform and to achieve that you often need to think very carefully in advance how to handle all that in one multiplatform project long before you actually start working on it.