Blitting is slow on the iOS!

[Guest]

We decided to go on full scale developing a high quality phone game with Air for phones, after air behaved greatly on the android.

bought an iPod touch 4 (which is similar to iphone 4G except the ram part) to test the engine, being excited to see the boost in performance as flash is running as a byte code on the iOS, I was shocked that it's really slow, slow to the point that it's useless, even with only 10 renders the fps is bad!

I am running this same demo which runs at 30 fps on the android while in iOS it's sliding between 10 - 30.

this is funny after I played infinity blade which has graphics comparable to the PS3!!

I removed ever single variable declaration inside the game loop just in case the garbage collection is doing this, but it still slow.

tried different methods of clearing the drawing canvas even not clearing it but also didn't work.

both gpu and cpu are slow.

so any ideas about this?

don't bother with the graphics in the video, what we're making is something like this which is going to be a great demonstration for Air, and we'll proudly state that we used Air for development, so please help me on this Adobe!

so should try changing the method for rendering (scraping everything I've done for the engine including a world editor), or have faith and keep testing on the android until a faster update for the iOS is released?

even being an android fan boy, iOS is more important than android as google doesn't support publishing/buying on the android market from my region while apple happily does, a release for blackberry playbook is also planned that's in case we don't end up using unity3D which I don't really wanna do.

[Guest]

MWAHAHAHAHAHA

I FOUND THE PERFECT SOLUTION!!!

http://www.youtube.com/watch?v=C775bXGitJw

This is so different from the blitting technique, and so tricky ... but it's the only way I found to run frame by frame animation on iOS!

[banzai76_]

Nice one

Can you give me some pointers as to what technique you used, if not blitting?

I'm guessing you got to grips with the GPU?

[Guest]

well the basic idea is to keep everything on the gpu, what I did is loading an animation strip, slicing the frames to separate bitmapDatas.

then whenever I need a new actor (monster in my test) I create new bitmaps each holding one bitmapData reference as a frame, activate catching to keep them on gpu, then swap between those bitmaps using the visible property aka just keep the current frame (bitmap) visible.

the advantage here is that I can use rotation, scaling and 3D fast.

but the downside is that this'll eat the gpu memory, and I crashed my iPod 2 times while testing more than 30 monsters so it's a bit dangerous, but anyway my animation is actually too much for a mobile game (48 frames x 30 = 1440 )

also it seems that creating new bitmap objects and referencing those bitmapDatas then sending them to the gpu is quite slow on the iPhone so no dynamic creation (need more testing)

next I will try to optimize this process, if I can find a way to just keep what's in the screen on the gpu without a performance hit it would be cool.

I need at least 4 actors at once (each has multiple animations) and also the background objects for my game.

If someone from adobe would provide some tips it would be awesome!

[ZRock2]

hi

I found very interesting you solution

also i saw in the video that you were able to compute gpu memory allocation on the fly,

how you did that?

I absoutly need to compute how much memory is still available on the gpu, can you tell me how?

thanx a lot

[boat5]

I thought about trying this before, glad to hear it works! To make sure i understand you, each character has its own set of cached frames, correct? Rather than having only one source set of frames in memory for use with duplicate characters?

Also, hows the audio delay? I think i had read its better or non existant on iOS.

thanks

[Guest]

"each character has its own set of cached frames, correct?"

Each character instance has its own set of Bitmap objects for each frame, and each Bitmap object (aka BitmapData container) has a reference to a unique BitmapData in order to save memory.

as described in this article:

For Bitmap objects, the Bitmap's BitmapData is represented by a texture. This distinction is important. It means that if multiple Bitmap objects are on the display list, but they all have the same BitmapData object, they will only require one texture in video memory.

also make sure you do not do my mistake and set the Bitmap object property catchedAsBitmap=true which was causing the bad performance and crashes when creating more instances of the monsters, unless you want to rotate or scale your sprite.

and in case you need to scale (mirror) a large number of characters, I suggest creating pre mirrored bitmapDatas.

right now I can render 40 animated sprites at once at ~30 FPS which is really awesome!!

I am still trying to squeeze more speed out of this to save more room for the background.

"Also, hows the audio delay? I think i had read its better or non existant on iOS."

on my iPod touch 4th generation, it's perfect unlike on the android phone.

I might release this engine as an open source after I do more progress and if someone is interested.

I'll rewrite the tile engine to use the gpu rather than copyPixels, and hopefully will have a fast and usable Flash game engine that can run with the same performance on all mobile devices supported by AIR.

[Guest]

lol forget about the previous method ... I found an even faster way! ... 90 smoothly animated sprites @ 30 FPS!!

I'll give more details after I do some tests

now I want the retina display feature more than ever!

and I officially announce that Air is the perfect tool for 2D games targeting all mobile devices!

just wait for the best Air on Mobile game to be released soon

[Jyri_Kilpelainen]

Hi Ammar!

Could you share the method you find the most efficient for sprite animation? If you can, a sample .fla would be awesome!

We are currently having problems with poor performance on iPhone 3G so every tip is appreciated.

[Colin Holgate]

I have been through some of these same issues, and was also using visibility to cycle through the frames. I have ways in which the non moving parts remain visible, and the just moving parts are cycled.

But where I'm headed next, and perhaps what he has now done, is to use scrollRect(). With that you could have a sprite sheet, and leave it visible the whole time, and just change the x values of the scrollRect's rectangle, to reveal the next needed image.

[banzai76_]

Colin - sorry, just to go back to your scrollRect idea, that sounded interesting. Could you elaborate?

I'm guessing you add layers of bitmap sprite sheets to the stage, with transparency where necessary, and cache them to the GPU. Then create a scrollRect on each one to show the bit you need, and scroll the x,y of the scrollRect to change the animation frame. Is that the general idea?

Would this be any different in theory to applying a rectangular mask of the required width and height to each bitmap, then scrolling the bitmap x,y to the correct animation frame?

[Colin Holgate]

Masks work out very poorly on iPhone, and so far scrollrect isn't doing as well as I had hoped. Here's a test:

http://xfiles.funnygarbage.com/~colinholgate/swf/chicken.swf

There are 100 chickens having their scrollrect set, and the original bitmap is a 6x5 grid of the 30 frames in the walk cycle. Unfortunately I only get 5 fps on my iPhone 4, so there's something amiss.

[Colin Holgate]

Here's a slightly more demanding 2000 chickens:

http://xfiles.funnygarbage.com/~colinholgate/swf/lotsofchicken.swf

It doesn't quite go smoothly, but it's amazing that it almost works.

[Guest]

well it's not really a very advanced code! I've done this before with browser based flash games, but never expected it to work this good on iPhone! I found it while desperately trying anything to boost the performance!

first here's the result rendering up to 1400 sprites at once, which means it's memory efficient.

though if you notice in the video, the movement will start to become sloppy if there's more than 90 sprites on screen!

The core idea is to load the frames to different BitmapData objects, I personally keep them in a vector, and create a Bitmap object for each sprite and just swap the bitmapData property inside the Bitmap object.

_spriteContainer.bitmapData = _frameBD[_currentFrame]; // where _frameBD is a vector containing the BitmapData objects that hold the animation.

and do not cache the Bitmap object!

also you should not rotate or scale the container (Bitmap) or it will severely lower the FPS, so if you want to mirror the sprite you can write a code to pre mirror the whole animation.

if you want to dynamically rotate and scale your sprite you can use the method I talked about on the previous post (multiple Bitmap objects)

I am working on full engine (animated sprites, collision, tile maps, object based maps, world editor) based on this method, and it works great so far!

I will release it as an open source soon after I release the first game that uses it.

tell me how this runs on the 3G, and if you want to try my test app on your 3G contact me and I'll send it to you.

harfoosh@gmail.com

[Colin Holgate]

When you said "lol forget about the previous method ... I found an even faster way!", what was your new faster way? What you just described sounded like your previous way.

[Guest]

This is the faster way, the difference is that I am not using multiple bitmap objects for each frame and recycle them with the visible property.

I am just adding one Bitmap object for each animated sprite onto the stage and animate it by swapping bitmapData objects which is the fastest way I found so far.

[Jyri_Kilpelainen]

Thank you Ammar for you test app. We tested it on iPhone 3G and with 10 sprites the fps was around 15. So at this point it seems that 3G is out of the question if you want to for example develop games that require any animations. Hopefully Adobe will fix this soon so that 3G would perform a bit better.

Could someone test Ammar's test app with iPhone 3GS so we would get results to compare with 3G and iPhone 4 (which apparently work great) ?

[Colin Holgate]

On the 3GS I could get 24 fps for 80 monsters, and 20 fps for 100 monsters. The iPad was twice those figures.

I think that even with only 15 monsters you could make an interesting game for the 3G.

[dissipation]

Just ran accross this thread, I have been using the 'visibilty toggle' technique myself, but after reading this later bitmapdata swapping way of doing things I'm quite ready to give it a try.

I realize this is an old thread, and possibly dead- would love to hear if anyone is currently using this and if they are getting good results.

-dis

[p3v1]

I'm currently using that technique in several games and the results are good. I don't think there is really any faster way of doing animations. I have used that technique succesfully in iPhone and Android games that are currently in App Store/Android Market: http://www.itunes.com/app/blockslide and http://www.itunes.com/app/cheezia. I'm also working on a shmup and kind of a snake game for iOS and in both of them I use this technique.

[Guest]

I think if you want to target the 3G, a game with around 5 sprites at once and a static background would work.

as for the 3GS, 4G, iPad it seems we have some more freedom.

I am working on a supposedly fast scrollable tile engine, will post the results when done.

[Guest]

I still cant help but think that the Iphone Packager we have at the  moment is simply a poor implementation, as its still only a 'Preview 2'  version.
What you are doing is building a very elaborate Display Object based  'Workaround' for a buggy Packager, but I think you are running a big  risk of  wasting your time, as when the next version of the Packager  comes out your work might(should) become obsolete.

The fact that blitting works as it should on Android phones, proves that  its not a hardware issue, its simply an implementation issue, as you  have pointed out in your first post, the fact that Flash now runs in  native iOS byte code, should IMPROVE performance if affecting it at all.  Also that CacheAsBitmap = true, impairs performance instead of  improving it, like what common sense would tell us about what we know about mobile GPUs, are all telling signs that this is just simply buggy, and  you trying to fix Adobe's work and nothing else. Of course I could be  wrong on this...

But Adobe should finally either release a new version or at the very  least just comment on one of these forum threads, that when can we  expect the next version and If the Blitting issue will be addressed. A  lot of people (including myself) are in your situation where you might  have to publish a game relatively quickly so its a tricky business  decision, if its worthwhile to invest time and money into a 'hack'  Render Engine, or maybe its best to wait another month(s) for the  official version and use the existing codebase.

[Guest]

yeah, I would really appreciate if someone from Adobe comment on this, so I could plan the game better, this would heavily impact our game as right now I told the artists to limit their imagination and we're cutting a lot of features from the game.

It would be very frustrating if we have to redo the work again in case of an update! we want our first iPhone game to be as good as possible.

[Guest]

Thats exactly my fear as well, developing 2 render engines simultanously, mantining two codebases (as for PC you cant do Display Objects as there is no guaranteed GPU there) only that it turns out at the end that the Blitting was only a bug.

If Adobe said that its going to take maybe another month, then i would say OK, its probably best to wait. But if 6 month, or Never? I think a lot of people really depend on this!

[Terrence_Tee]

I agree.

it will be really cool if Adobe can share with us a roadmap...

what can be expected in how many months...

many lives are depending on it....