Solitaire 3 with Air 3.2 initial test

28 Feb

Adobe have recently posted the release candidate for AIR 3.2 which enables Stage3D for mobile, so it’s time to dig out the games I worked on last year in preparation for this.

What I have done in the following video is take my Stage3D game ‘Solitaire 3’ (which also uses the traditional display list to display UI elements) and publish it to run on my Android 4.0 Galaxy Nexus (A pretty powerful phone at this time). I haven’t had time to try this on my iPad, but as my focus is more on the Barnes and Nobile Nook device, the iPad is less of a priority to me.

Solitaire 3 is pretty efficient, it uses simple 3D planes, a single spritesheet for all the cards, the cards are created only once and then reused throughout the entire game.

You can play the web version of Solitaire 3 here:

Before continuing it is worth having a look at the benchmarks of devices as shown here: Which shows that the iPad 2 and iPhone 4S are clear leaders in GPU performance.

Unfortunately the results are total rubbish …

So what’s the problem?

This is early testing for me to get this running, and my time is very short, from what I understand a lot of the problem is that I am using the traditional displaylist several layers deep.

Just to clarify what several layers deep means, here’s how the DisplayList layout of Solitaire works on top of Stage3D …

-Game ‘Shell’
–DisplayManager (controls display of different screens)
—Screen (‘for example Main Menu’)
—-UI Within screen (this can have layers within it)

… so, not unusual within the normal Flash world, but apparently potentially very bad when using Stage3D.

NOTE: Flare3D doesn’t appear to be the problem as shown in this video by @chribbe1, BUT this is running on an iPad, where as I’m using my Galaxy Nexus.

Here’s an excerpt from Tom Krcha’s blog post ( that explains why …

If you want to reach maximum performance, do not overlay standard Flash DisplayObjects over the Stage3D during the gameplay, as you are using Direct render mode, every change in Flash DisplayList will force to re-render whole stage, so you can use DisplayObjects for instance in the main menu and so on or leaderboard, but especially on devices, to get the most out of it, just use pure Stage3D for the in-game runtime, that way you get the best performance.

So WHY Terry did you build this game (and 2 others) using the DisplayList?

Because of this type of message from Adobe (excerpts from

“A big plus of Stage3D is that you combine 3D hardware accelerated code with the great features and ease of use of regular 2D Flash authoring within the same application.

When creating a native 3D application, the creation of the 2D UI often requires custom solutions that rarely have authoring tools as flexible as Flash.

With Stage3D, regular Flash 2D content coexists with Stage3D content. So, you get all the power of Flash and you also get 3D accelerated content. You can choose to create a main 3D scene in the background or embed smaller 3D items that are part of the 2D experience.

Stage3D applications can run on a multitude of platforms. You can execute Stage3D applications as AIR applications as well as playing them with Flash Player. This capability means that you can use Stage3D to create desktop 3D applications, similar to the standard 3D games for the desktop. Eventually it will be possible to use the same code to deploy the application to mobile platforms, such as iOS and Android. When you consider the huge penetration of Flash Player installed base, it’s easy to see how wide the distribution of a Stage3D application can potentially be.”

Obviously those words are to be taken very carefully and mobile is a VERY different space to desktop. I’m also no stranger to mobile development with AIR, but this is a completely different performance paradigm than what I’ve encountered before.

So where to from here?
As you can imagine I’m extremely disappointed that the 3 games I’ve developed using Stage3D (for gameplay) and (2D for UI), at the moment, pretty much have no chance of running smoothly on mobile (And I mean Android when I say mobile as I haven’t tested on iOS). It was the whole reason I built those games, to be ready early for when Stage3D arrived on tablets and phones. This sets me back probably for several months, which as an Indie developer is an enormous blow financially and on my time. If it seems like I’m using a lot of superlatives it’s because this impacts me more than you know.

From here I think I need to start from scratch, get basic 3D stuff working smoothly – without any DisplayList – and then find solutions for replacements of normal UI. Genome2D shows a lot of potential for filling this gap, as shown in this blog post: and has an API that handles the creation of text display on the GPU.

Also I will test on an iPad 2 once I get time, but again iOS is one of my less profitable platforms so there is little priority in this for me.

And hopefully my experiments will lead me to ways I can get my games running smoothly on mobile (read: Android), either that or they are a complete rebuild … but at least I have all the gameplay and logic worked out :\


Posted in Game Dev


Tags: , , , , ,

  • James Paintwork

    This seems like a huge ball drop on Adobes part….

  • Tom

    Did you compile a release build? It makes a HUGE difference. I made some quick tests which were really slow and I had no idea why ( I used starling ). Then did a proper release build and got everything at 60fps without changing a thing.

  • Terry Paton

    Yeah I did, I even mentioned it in my blog post about the Solitaire 3 on the iPad 2 (Just posted)

  • Richard Davey

    How is performance if you disable all of the UI? Or is too much of the game bound to the UI to make that an easy test? Just wondering if it’d be faster for you to re-create the UI in Stage3D than it would to rebuild all 3 games from scratch. I share your pain though :(

  • Terry Paton

    Yeah I managed to disable all the UI but it made little difference. I had started to rebuild the UI in Stage3D (not shown) but it made little difference. I still working on it …

  • Matt Summers

    Does AIR 3.2 default to compiling against android SDK 2.2? You might try using the addtional ADT command “-platformsdk c:androidSDK” and pointing it to the android 3.x SDK. The new manifest setting “” requires you are using ADT to compile against the android 3.0 SDK rather than the built in 2.2 SDK. Could also try changing the android colorDepth manifest setting from the AIR 3.x default of 32bit to 16bit. Adobes AIR docs say going to 16bit is a rendering performance boost, at the expense of color fidelity. I’d curious to know the outcome of any of these tweaks if you get around to trying them.