A

Anonymous

Question

Blitting is slow on the iOS!

Forum|Forum|15 years ago
December 23, 2010
4 replies
9267 views

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.

Development

This topic has been closed for replies.

RossD20Studios

Known Participant

Greetings fellow Flash Developers!

My name is Ross Przybylski, manager of D20Studios, LLC and creator of the Flash multiplayer game Hero Mages. Currently I am working to port my game to mobile platforms including Android, iPhone, and iPad and have been working the past 3 months to discover the best cross-platform technique for rendering sprite animations on these platforms.

I wanted to invite all of you to join in our conversation on Kirupa forums: http://www.kirupa.com/forum/showthread.php?p=2594775&posted=1#post2594775 where we are discussing this issue as well.

In particular, I'd love to hear more from Ammar about the solution he's been working on. If I gather correctly, you are storing your animation frames as bitmapData and then using bitmap.bitmapData = frameBitmapData to blit the model animation, while the actual sprites are contained in clips and moved upon the stage using regular x/y properties. How are initially storing your model as bitmapData? Do you have a single sprite sheet or is it a movieclip vector timeline animation that you precache in an array or object at runtime? If you have an example FLA I could take a look at, that would be extremlely helpful!

Again, I encourage others to join us on Kirupa. Another forum user, tbo, posted some simple code experiments to test the rendering methods and I have posted these as ZIPs as well as the results for Android and iPad devices.

A

Anonymous

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.

A

Anonymous

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.

A

Anonymous

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.

B

boat5

Inspiring

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

A

Anonymous

"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.

A

Anonymous

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

A

Anonymous

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!

B

banzai76_

Inspiring

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?

A

Anonymous

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!

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded