We develop iOS application on flash

Probably, many have heard about the Adobe Air project - a very sound initiative from Adobe to make the application on flash compile and run on any platforms - desktop, iOS, Android, TVs, ...



For a long time nothing sensible could be done on air. But recently the technology is gaining momentum, Adobe has introduced a number of optimizations to the air code, and now it is possible to write a very smart application on it. In this article I will talk about our experience in developing an air-application for iOS.

How did we get to such a life? ...

At the moment, the main project (social game) of our small startup, a company of several people - after a year of development is frozen at the final stage during the search for investors. So in order not to sit idle while searching / negotiating is underway, it occurred to us to do something not very labor-intensive, and if it can earn something, then in general it is gorgeous.

')

Because Neither of us is familiar with unity, nor even with xcode, but we are on “you” with a flash — it occurred to me to try out the Air technology, which was vaunted, to create a more or less presentable and dynamic game.



At the moment, use case'ov eir under iOS - count on fingers. Yes, Machinarium is not bad. But, after all, this is not an indicator. We were interested in how air will cope with a dynamic toy.



So the decision was made. Approximate dates (1 month) - set. And we sat down to delve into a new technology for us ...



The main platform on which we focused was the iPhone 4.

The idea of ​​the game.

Here we have not thought for a long time. The task was to find something that would fit the following criteria:

• Simplicity => faster development
• Lack of a large number of animation, graphics, etc. (so that in the first place - not to burden the artist with work for half a year, and secondly - not to burden the processor of the phone)
• Desirable - nezayannost themes
• No need to create 100 challenging puzzle levels (which would also slow down the development)

We didn’t want to invent something of our own, and it wasn’t even the calculation. So we started surfing the Internet in search of a cloning object.



After a couple of days of searching - we stopped at the toy " Ax in Face ". She met all our requirements. Its essence was to draw a finger on the trajectory of the ax and throw them at enemies.

Start of development.

So, we started ... It is worth noting that we had no idea about Air technology at all.



But as it turned out - it's not at all scary. This is the same flash, only with a couple of additional classes for working with specific mobile devices functions - multitouch, etc.



So we started the usual development in flash. I will not write about it - this is not the topic of the article.



I’ll tell you only about the problems and difficulties that we encountered while launching the application on hardware (iPhone, iPad).



By the way, for those who do not understand what the Air is - I will say it in two words. You are developing a game in flash. Then compile it under Air iOS and at the output (ideally) - you get a ready-made .ipa file for sending to the app store.



For the user, the program is no different from those written in Objective C or Unity. It also runs on i-devices. No additional settings or dancing with a tambourine - does not require.

Speed ​​performance.

The theme of speed is the most important in our development. Naturally, we wanted to get a product that smoothly differed from other iOS games. Well, or as close as possible to them. Overtaking events, I will say that it was not possible everywhere.



So, our game required the output of a couple of dozen animated sprites to the screen as quickly as possible. I will describe the technology in chronological order.

Flash engine, bitmap frames.

Of course, about any vector of speech can not be. So the first thing we tried was to export our vector into bitmap and insert them back into flash frames.







It turned out not bad, but I wanted faster / smoother.

Bitmap blitting.

Probably many are familiar with this technology. This is the case when you spit on the flip pipe and do everything yourself - generate an empty rectangle and every frame, sprite after sprite, using copyPixels, copy them onto it.



Next, output the resulting canvas as one Bitmap object.



This technology shows itself well on desktops, but on iOS it turned out to be fayl. The engine worked 10 times slower.

Modified flash engine.

Here it is - the golden mean.



After some googling, it became clear that it allows to speed up the graphics. The bottom line is that when we, as in the 1st case, did each frame of animation in a new frame, Flash had to kill each frame of the old frame from memory and create a new one. What is very resource intensive.



I read somewhere about technology that allows you to squeeze the most out of your mobile environment.



Its essence is that you create a MovieClip with 1 frame and throw ALL frames of animation into this frame at once.



Further, with the help of visible you only show what you need. The trick is that all the animation frames are simultaneously present in the memory (and the virtual machine has already allocated memory for them and stuffed them there), and you only turn on / off their visibility. But it does not rebuild the memory and everything works as quickly as possible.



As a modification of technology, there is an option (which was used) when all frames are stored in separate bitmapData. And instead of jerking visible at the heap of Bitmaps, you have one, the main Bitmap and rearrange bitmapData to it. Those. something like main_bmp.bitmapData = bd_frame [i];



On this and stopped. The animation speed was about 1.5 times higher than the first case and allowed to display 20-30 sprites at 40 fps on iPhone4, which was fine with us.

Performance Optimization Tips.

In the course of development, we encountered a rake, which I would like to sum up in the form of tips:

1. Create as few dynamic objects as possible.
2. The fewer objects on the screen will catch the events of the "mouse" (finger) - the better. Set all mouseEnabled, mouseChildren to false.
3. Better not try to move large objects and even more so to change their alpha.
4. Put cacheAsBitmap for everything that is not animated.
5. If you need to rotate something or change alpha - use cacheAsBitmapMatrix - this will speed up this process.
6. Do not hang a bunch of liseners on ENTER_FRAME. Better make one that will call all the necessary.
7. Do not become attached to the frames, but become attached to the timer. Those. in your liceboard on ENTER_FRAME, keep the time counter from the last call and proceeding from it - do all the calculations.

So ... We didn’t meet the deadlines, and instead of 1 month, it took 2 everything. But I really didn’t want to let out a very poop.

The specifics of the platform.

Retina vs lo-res.

How does an air application run on iPhones with a different screen behave? In fact, everything is simple. In the settings you set, whether you want a retina application or not. And depending on this, your application will scale.



In our case, we created a retina app and the size of the scene is 960x640. On the iPhone 4 / 4S, it goes without scaling. On the 3rd series, it scales by 50%.



Of course, with a great desire - you can get confused and get scale when initializing, and depending on whether it is 1.0 or 0.5 - output different graphics ... But it would seem very difficult for us (and it wouldn’t allow collecting scenes in the flash itself, everything I had to write code), so we spat.

iPhone vs iPad.

This is the same as with the retina. If you tick “iPad”, then the application on the iPad will run full screen, scaling under it (which in the case of 960x640 will cause non-repeated scaling and artifacts). If you do not put such a tick in, then it will behave like a normal iPhone application running on the iPad - i.e. run in a small window with a button "x2".







We did just that.



Later, we will probably assemble the HD version specifically for the iPad - full screen and with full graphics.

CPU vs GPU.

Flash for Air can be assembled in two versions - with the engine on the GPU and on the CPU. To my surprise, the algorithm of the engine was such that the difference between the GPU and the CPU was very small (no more than 10%). Therefore, we stopped at the CPU, since GPU compilation does not support effects. Those. all font strokes and shadows would not work. Of course, the way out was to take a font with effects, create bitmapdata, draw there () of this font, and add the resulting bitmap to the scene. In this case, all the effects would be in place, because draw () is performed in any case on the CPU and therefore does not lose effects.



But it was somehow very hemorrhoid and it was decided that the game was not worth the trouble.



But I think this issue should be considered individually for each project.

Problems and solutions.

Obviously, not all the features of iOS, we will have access from the Air. For example, to the capabilities of the Game Center. What to do? Dead end?



Not at all. For all this, there is a technology native extensions. With these extensions, you can "reach out" to any specific iron. How to use them - the topic is quite extensive.



In addition, the use of native extensions entails the second (and even third) problems - the inability to compile ipa from flash (you need to use the command line) and dancing with a tambourine to make this work on the hardware.



Also, for some reason, the new versions of Eir didn’t want to spit on the sound switch on the phone. To make it work, you also need to use the native extension. If it is interesting, I can write a separate article about native extensions.



Plus, the whole process cannot be completed on the PC anyway. Despite the fact that even certificates can be created under windows (again, if anyone is interested, I can describe all the dances with a tambourine in a separate article), but what cannot be done under Windows is to fill the application in app store. Recently, this is being done in the only possible way - with the help of a special program that requires a minimum of Mac OS 10.6.8. And nothing else. A long and hard dance with a tambourine allowed me to put this version of makosi on a virtual machine under AMD (if anyone is interested, then briefly: only image 10.6.4 (legacy) worked, downloaded a combo update to 10.6.8 (hands!), Set , not rebuilt, replaced kext'y so that it does not hang on PCI configuration begin, loaded with ignored caches). A few more tambourine dances - and the app is flooded!

Findings.

Did the experience succeed? How exactly the experience of the new technology - I think yes.







But as a platform for writing dynamic games, I would still not advise Flash. Because brakes still have. For example, the animation of the movement of objects in the menu could not be made smooth on the 4th iPhone. On 4S and iPad 2 - everything flies. But, on the other hand, these features are not particularly critical and do not interfere with the gameplay.



Summarizing - you can say so - you can write. And it can even look good. But on some points, it still does not reach native applications.



Although Adobe is also not standing still. Yesterday he announced the release candidate Air 3.2, where there is full use of the GPU (including 3D). We'll see…

Result.

There were pictures, promo codes and links to the product, but because I do not want to publish in "I am promoting", then I removed them.



It's too early to talk about the results - the toy is only a few days in the app store. Recently published on iphones.ru. So for now - all ahead. If it is interesting, then I can write about commercial results. True, we have already caught a review by 1 point from the “hero” who complains about the lack of achivok (and they are, and right on the main menu) and physics . Yes, it is precisely the physics that we lack in the game.



As a bonus - a couple of sketches: