Currently, Backstage2D’s code base is mostly a playground for proof of concept of some API ideas. Some stuff in this post may not match the git repo (for example, I’m still using “layer” instead of “surface”). There’s a bunch left to do, but it is working enough to run a modified version of MoleHill_BunnMark that some folks from Adobe put together (I actually lifted most of my GPU code from that example code, heh). The BunnyMark example was adapted from Iain Lobb’s BunnyMark, with some additions from Phillipe Elsass. You can view the Backstage2D version of BunnyMark here (and check out the original BunnyMark MoleHill here).

Fork Backstage2D at GitHub.

The rest of this post describes the thought process that went into Backstage2D.

The Flash AS3 display list API is not the best way to utilize the massively parallel capabilities of a GPU, and deal with the other limitations of a CPU/GPU architecture. The display list’s deeply nestable DisplayObject metaphor, and all the fun filters and blend modes just doesn’t translate well to very parallel, flat GPU hardware renderer. All of this is especially true on mobile like iPhones, iPads and Android devices, and that’s the primary target for Backstage2D.

With an API like the traditional flash display list, it’s easy to create situations that can’t easily be batched due to branching operations and other things which change the GPU state, and break parallel processing – slowing everything down. You see this in Adobe AIR’s GPU render mode, where seemingly random things can have a huge negative impact on performance. Behind the scenes AIR attempts to break the content into batches to speed things up. The use of certain features, or normal features in certain ways can drop you out of a batch. When performance degradation happens, it’s not always clear why. Because of that, to get great performance you must target just a subset of the normal features, and apply a lot of discipline to make sure everything keeps working smoothly.

I wanted do something different. I wanted to play with an API that is intentionally unlike the Flash display list – one designed to help the implementor (Flash developer or designer) understand how to arrange their content, so that it renders very quickly, even on mobile devices – and still get the benefits of all the glorious Flash stuff we are all used to.

Here are some of the primary principles I came up with, which impact the API:

• In order to take advantage of the parallel nature of GPUs, we need to batch many Quads (think, DisplayObject) into batches. The API should make batches easy to understand and use, so there’s no guessing about what’s going on.
• GPUs like shallow content – they draw a lot triangles all at the same time. There is no nesting on the GPU, so while some form of organization is necessary, the infinite nesting model must be reigned in.
• Backstage2D shouldn’t do too much in an automagic kind of way. Guessing about the impact of nesting things a certain way, or using a blend mode, or the performance impact of using certain features translates into extra effort and cost during production because of the unpredictable negative impact features can have on performance. Features should work as you expect them to, and the performance impacts of doing certain things should be clear.
• Think of the GPU as a remote server that you send instructions to. Uploading things like Textures to the GPU from system memory is slow (especially on mobile). Backstage2D should make these stress points clear.
• Flash’s vector engine is tops, and working with Bitmaps (and sprite sheets) sucks! The API should enable the continued use of the display list, in GPU friendly ways. Drawing vector art on the GPU is hard, and is ugly anyway. So leverage the CPU rasterizer, and make sure the API makes the GPU upload bandwidth and render time overhead clear.
• Backstage2D objects shouldn’t look like traditional display list objects – we’ll use names other than Sprite, MovieClip, DisplayObject, etc.

Of these, batching is the starting point, since it is the most necessary for advanced performance, and effects how data must be organized the most. You can draw each Quad (think Flash DisplayObject, or Sprite) individually by setting up the vertex, program, texture, etc. data for each quad, and calling drawTriangle for each and every Sprite. But the GPU can’t optimize to run in parallel if you do that – most of its processing cores end up underutilized in that model.

Batching let’s more than one quad be draw simultaneously, but there are limitations – Every item in a batch must use the same vector data (a giant array of x,y,other data), single texture and other state information, like blend modes. Additionally, the entire batch must be drawn without interruption, which means you can’t insert items from other batches (with other state settings like a different blend mode) in the middle of the batch.

So batches resemble layers, or surfaces. The model for Backstage2D will be a series of stacked surfaces, instead of a deeply nested tree structure starting at the root.

In this paradigm, the surface gets batched, and the children it contains get rendered in parallel – perfect for GPUs. To eliminate batch breaking APIs, certain “state changing” operations can be applied to only an entire layer, not to each element – operations like blend mode settings – or adding and removing elements from a surface. The limitations of surface API should help the implementor understand the impact of doing certain things. If you need to have 100 elements, and every other element has a blend mode of Multiply, while the one below it has a blend mode of Normal – in the traditional Flash API, this is fine, and can actually run pretty well. On the GPU, all 100 elements must be rendered individually in 100 distinct surfaces. Having that many surfaces feels heavy because it is heavy.

Texture changes are one of the things that break batching – a Shader can deal with only one texture (well, actually up to 8 – but that makes the pixel shader more expensive to run), so a set of elements in a batch must be combined into a sprite sheet or texture atlas. If you’ve tried to use a texture atlas in another 2D rendering engine, you may have noticed these are a pain to deal with – and usually it requires setting them up manually before compilation. This is one thing that Backstage2D handles for you – at runtime – in an automagic kind of way.

This feature was actually done for a bunch of reasons. I’d like to add is a resolution (screen DPI) independent measurement mode, where assets get generated on each device an app runs on, from high quality vector art, for exactly the necessary DPI the system is running at, and scaled to real life sizes. Type specified at 12-point, should truly measure at 12-point.

Additionally, Flash vector art looks great (especially with the new 16X16 quality modes), but they look their best when rendered to match the screen exactly. Resizing prerendered vector art can ruin the beautiful anti-aliasing in vector art. Proper sizing can also help performance with older hardware like an iPhone 3GS, which is actually pretty capable, but doesn’t cope well with iPhone 4 retina screen sized material (4x more pixels than will be displayed).

Setting all this up is expensive – especially generating the sprite sheet. But just setting up vector data and loading even predigested textures is already expensive enough that you wouldn’t want to do those tasks while your app is running some smooth animation – it will cause missed frames, and your users will notice. So Backstage2d’s API should guid the user to avoid doing expensive things while an app or animation is running. It exposes a build, load, and/or upload commands per layer. That way, the implementer always knows that what they are doing is computationally expensive (down the road, the plan would be to move much of that into concurrency – more on that another time).

The characteristics of this are very different from normal Flash, which is to load only the minimum of whats needed, when it’s needed, and try to keep as much as you can off the display list. In the Backstage2D model (in the standard surface type anyway), an entire surface, and all it’s children (called “Actors” to avoid colliding with AS3′s “Sprite”, etc.) gets rendered up front to a big TextureAtlas, and stored in memory or on disk. How to optimize and organize your assets to avoid running out of memory becomes an entirely different matter from the way to optimize for the CPU. A surface will have an associated sprite sheet bitmapData asset though, which can be measured.

With these restrictions in mind, the idea would be to create a variety of surface types to suit differing kinds of content. For classic content, a standard static Quads surface (done!), still frame animations (sprite sheet animations – generated at runtime), tweened animations (inverse kinematics – the bone tool), and streaming animations (dynamic MovieClips, large MovieClips, or video) – maybe even some surfaces useful for standard UI, like scroll panes. For more advanced 2D assets, a variety of different mesh layer types could be added (that’s where GPU stage3D programming gets fun!).

I’d love to flesh this out with more features, including an animation subsystem that would include a couple of different Animation display types. Alas, free time is short, and I’ll probably never get to it. But I already spent a lot of time on this (I broke my foot, and was couch bound for a while) so thought I’d share where I got to.

Scripts n Styles is a free OpenSource GPL project that you can fork and contribute to on github! (You can also fork and contribute to CodeMirror and LESS.js)

As a Shortcode example: I placed the following html into the Shortcodes tab and gave it the name “tweet test”.

<a href="https://twitter.com/share" data-via="WraithKenny" data-size="large" data-related="unFocusProjects" data-hashtags="ScriptsnStyles">Tweet</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

I then use the shortcode [sns_shortcode name="tweet test"] to display: Tweet

Some quick numbers from the performance-test with 1,000,000 iterations on a Core 2 Duo 2.6GHz (in milliseconds):

Func call time: 15
Runnable call time: 5
Event (1 listener) time: 863
Signal (1 listener) time: 260
SignalLite (1 listener) time: 232
RunnableSignal (1 listener) time: 56

Func call (10 listeners) time: 190
Runnable call (10 listeners) time: 399
Event (10 listeners) time: 2757
Signal (10 listeners) time: 741
SignalLite (10 listeners) time: 725
RunnableSignal (10 listeners) time: 221

The bold line is a vanilla SignalLite, and the line above Robert Penner’s AS3 Signals. They are pretty close, but SignalsLite takes a modest edge. But let’s look at the same test on iOS (iPhone 4S) with 100,000 iterations:

Func call time: 171
Runnable call time: 26
Event (1 listener) time: 3723
Signal (1 listener) time: 789
SignalLite (1 listener) time: 481
RunnableSignal (1 listener) time: 117

Func call (10 listeners) time: 2004
Runnable call (10 listeners) time: 1892
Event (10 listeners) time: 9217
Signal (10 listeners) time: 4030
SignalLite (10 listeners) time: 2074
RunnableSignal (10 listeners) time: 498

On iPhone you can see that SignalLite is almost twice as fast as AS3 Signals – a more substantial difference than on desktop. I’m not sure why that is, maybe the AOT compiler can optimize something about SignalLite better – IDK, but it sure is fast!

Then there’s that last line in each group – RunnableSignal. Now your talking speed. That one also solves a particular problem with function callback systems that they all seem to have – there is no compile time function signature checking. You have to wait until the thing runs, and then find out you are taking the wrong number of arguments, or the wrong type, etc. But, solving one problem (compile time type checking), solves the other (speed), and that brings us to SignalTyped which RunnableSignal in the test above extends (I’ll probably rename at some point).

SignalTyped is beginnings of a fast executing type safe implementation of AS3 Signals. The idea is, you extend 2 classes – SignalTyped and SlotLite. SignalTyped is effectively an abstract class – you must extend it and implement the dispatch method, and the constructor (at least for now, I’m looking for better ways to handle this). It takes a bit of boilerplate to implement this in a class that would expose signals. This example is based on the performance test from Jackson Dunstan’s CallbackTest which I borrowed (I hope that’s ok!):

// Interface for your class that might have listeners for the SignalTyped.
// Make one of these per listener type.
interface IRunnable {
	function run(): void;
} 

// Custom Slot has a specific property for the Runnable class.
class RunnableSlot extends SlotLite
{
	public function RunnableSlot( runnable:IRunnable ) {
		this.runnable = runnable;
	}
	public var runnable:IRunnable = new EmptyRunnable;
}

// An empty IRunnable class for first node.
class EmptyRunnable implements IRunnable {
	public function run():void {};
}

// You need one of these per dispatch type.
class RunnableSignal extends SignalTyped
{
	// last and first must be set to the typed Slot.
	public function RunnableSignal() {
		last = first = new RunnableSlot;
	} 

	// implement the dispatch method to call the runnable prop directly
	// It's easy to have it take and dispatch any type you want - with compile time type checking!
	public function dispatchRunnable():void
	{
		var node:RunnableSlot = first as RunnableSlot;
		while ( node = (node.next as RunnableSlot) ) {
			node.runnable.run(); // FAST!
		}
	}
}

That’s all necessary for the implementation requirements – a lot of boilerplate, I admit. Then you expose that in a class that might use it all:

class MyDisplayObject
{
	// could probably make this a getter..
	public var signaled:RunnableSignal = new RunnableSignal;
}

Now for the consumer to use this, it’s just a bit more boilerplate than a normal signal:

class MyConsumerOfSignalLite implements Runnable // boilerplate point 1
{
	public function MyConsumerOfSignalLite()
	{
		var dspObj:MyDisplayObject = new MyDisplayObject();
		// add the signal (boilerplate point 2 - normal)
		dspObj.signaled.addSlot( this );
	} 

	// boilerplate 3 - normal, but more strict - naming is specific - FAST!
	public function run(): void {
		// do whatever when signals
	}
}
// boilerplates 2 and 3 are normal for any signal, except the strictness of #3

What’s cool about this is you get compile time type checking for your method signature, and the performance improvement that comes with skipping those checks at runtime.

I’m also thinking about a slightly different signal API that would be more like the Robot Legs’ contract system – think signals by contract – I’m working on it. Since we would be implementing a defined interface per signal type, we could boil the add methods and signal nodes down to one method to add all the listeners of a single object – one add method per dispatching class, instead of one per signal on the dispatching class. This could lead to a reduction in boilerplate. We’d filter by interface type instead of using multiple signal.add nodes and methods. So – improved runtime performance, reduction in (usage) boilerplate (if not implementation) and compile time type checking. I love it!

Note – I tested none of the example in this post, and the code in github is all very early stage stuff. The performance-test class works though – give it a try!

Oh, here’s the github repo:
https://github.com/CaptainN/SignalsLite

I published an old post with my thoughts on the “Flash is Dead” thing that pops up routinely in media circles after anything happens to shake things up (like an Apple ban on Flash, or Adobe dropping a supported platform, etc.) yesterday. I optimistically highlighted in that piece the promise that AIR technology represents – it’s even in the title “Flash and AIR, Nothing But Opportunity“. I really believe the technology represents, and could fulfill all the promise those of us down in the weeds perceive. I also believe that Adobe’s Flash Platform engineers and evangelists also see that promise, and would like to see it fulfilled.

Yesterday Adobe unceremoniously dropped support for an entire class of platforms. No more Flash Player in mobile browsers. It’s not a terrible technical decision – working in AIR and native app land offers a ton more flexibility. It even makes business sense. Browser makers are increasingly hostile to Flash – Apple has never let it in the door on iOS (and never will), and Microsoft announced plans to kill off plugins even on the desktop in Windows 8 Metro interface. Browsers have become hostile territory for Flash, so it makes sense to move emphasis in the two directions the industry is headed – app store apps with AIR (which no one knows about) and HTML5 for browsers. In an important way, this does mean Flash is dead – it’s not going to be in the browser going forward. It really is out of Adobe’s control.

But there’s a problem. The longer Adobe’s bumbles the messaging, the harder it is to say for sure whether there is a lack of commitment to their platform (including AIR), or if it is truly just a PR problem. This kind of announcement had an easy to predict effect on Flash’s brand, yet there was no attempt to get out in front of that narrative that would show they are committed to the larger “Flash Platform” of which AIR is an important part going forward. In the non-technical parts of the industry – the media, managers, and creative side of production teams – they all heard Adobe Flash is out of mobile – use HTML5. It’s even worse in client land, where the term “HTML5 app” is used regularly along with “app store” – this news was so harmful to them, that clients with existing Flash content, which can be ported to the app space easily with AIR, are really freaking out. I can tell them about AIR all I want, but it’s hard for me to counteract all the media buzz (repetition is reality – brain science).

But what if they got the right message. This kind of move could represent a real intent on the part of Adobe’s leadership to get out of the Flash Platform altogether, and maybe out of the platform space entirely, and focus instead only on tooling to produce for the platform commons that HTML5 represents. Look at the kinds of decisions they’ve made recently. Adobe has essentially dropped internal support for their “Flash Platform” on every system platform they can, by either straight up dumping it (Linux, mobile flash, TV), or by farming out porting and support to partners like RIM.

On the other hand, Adobe and Flash evangelists and engineers seem committed to the “Flash Platform” which in an un-articulated narrative (narrative – it’s how we think – more brain science), really means AIR in app stores (mobile and desktop), but I’m not sure I’m getting the same message from the real decision makers at Adobe. I don’t know if it’s intent, or just plain old bad PR judgement, but it feels like I’m standing on the greasy platform, and it’s getting pretty tough to hold my balance. Some folks are already sliding off.

I think they are in it for the long haul, and they’ve even built some of their own apps on the little known Flash based mobile app technology that is AIR. But guessing someone’s intent is problematic – that only makes the PR problem clearer. I shouldn’t have to guess.

It boils down to this. I know technology, and I know the Flash Platform. I know it has merit and potential. But if people can’t tell if the decision makers at Adobe are serious about supporting it into the future, it’s going to be a tough haul to convince anyone to build anything on that platform. I already know a few platforms, including HTML, learning a new one isn’t scary, but I really prefer Flash and AIR because of it’s potential and even it’s legacy, which has value (despite the tar Steve Jobs dumped on it). If Adobe can’t or won’t make it clear that they are committed to AIR and the Flash Platform, I’ll have to find an alternative – and the decision won’t be mine. At this point, we need a clear unambiguous statement of intent from Adobe – are you committed to the Flash Platform and AIR, or not? A public roadmap wouldn’t hurt either.

In the technology business, if you aren’t looking ahead, you are being left behind. There is fundamental shift occurring in the content technology space, where Flash and HTML live their happy lives. This shift has mostly been explained using old terms, like “apps” and “HTML5 vs. Flash” – these explanations miss the point. They all describe how things were yesterday and are today, but miss how they will be tomorrow. The browser has been and is today, the primary means of application and content delivery. A new set of opportunities for delivering content are changing all that. The Split puts the traditional desktop browser market on one side, and app stores on new platforms, with new hardware, and new interface paradigms on the other.

App stores should be more broadly called content stores, because the line between apps and other kinds of content is pretty thin. Market specific content stores have been around for a while already on the desktop. Game shops like Steam and Direct2Drive already make up the lion’s share of the PC games market, and iTunes was already a form of an app store, before apps where apps.

The companies behind every platform are adopting apps stores, including all major operating systems on traditional PCs, including OSX, and soon Windows. Open source trail blazers like Ubuntu have actually had something like app stores for a long while now. Additionally, more and more types of content are being pulled into them, from apps, to music and movies, to Magazines and local newspapers. The models for monetization are so much clearer, and the tools to take advantage of the various models are already built, and for the consumer, very convenient. App stores are the new reality.

To really understand why this is happening, and what it means for those of us who make a living in the weeds, we need to understand where we are, and how we got here.

The PC Era

In the early days of personal computing, “applications” (or “programs”) were the hot action. You needed something to do with your new beige personal computer (PC), so you bought (or borrowed) software or other types of content on diskettes, and later CD-ROM (oh the magic) and installed that software to run on your PC or Mac. It was an offline process, but it was the only realistic way to go. Even if you had access to the internet, you weren’t going to download megabytes of data over your cutting edge 14.4KB fax/modem connection. Traditional forms of acquisition ruled in those days. You had to take yourself to the store, and buy a box or a publication or whatever else, to obtain content – probably paying with cash.

When the internet hit mainstream in the 90s, and data speeds increased, the transition from “applications” delivered through boxed diskettes, to continuously updated “websites” began. The internet had some advantages over boxed content. The biggest was that accessing a web site through the internet was exceedingly convenient for consumers. Far more convenient than traveling to the store and buying a box with a CD of clip art on it. For content producers there is also a sense of limitless shelf space compared with traditional retail outlets, so they were quick to try to carve out advantage there. Search engines and content indexing services like Google and Yahoo! made a killing on both ends by providing a way for content producers to get their content in front of users.

Broadband completed the transition. At the dawn of the new millennium and “the internet,” became the primary means of content and application delivery (aside from a few important smaller markets like games and productivity apps). The browser was the primary means of application and content delivery, and for good reason. The content is easy to access from multiple platforms, and is super convenient. All you need is an internet connection, and a browser.

A Flash of brilliance

At around the same time, Microsoft mostly won “the browser wars” with Internet Explorer 6, and basically stopped forward movement in their browser, and for many years, the internet – the commerce in the browser era’s “website” based economy was able to mature. The stagnant development of the dominant browser platform created a challenging environment, one in which it’s easy to see why Flash was able to thrive.

Flash brought many improvements over the browser, through constant performance and scriptability advancements, as well as significant additional features the browsers in the aggregate simply couldn’t match – video being an important notable feature. Additionally, Flash provided consistency across browsers and operating systems, and comparably great performance, when measured against HTML and JavaScript. A browser-based app simply couldn’t (still can’t) match it. Flash in the browser became the go to platform for serious interactive work on the internet. You just couldn’t get similar levels of awesome out of IE6 and the rest of the browsers of the time.

All good things

The split started to happen in 2006. On the PC, which really means in the PC browser, Adobe was getting more serious about the application space in the browser by releasing the first version of Flash with AVM2 (and s 3.0), a much more stable foundation than Actionscript 2.0 had been, along with an update to its application framework, Flex that took advantage of the improvements to Actionscript 3.0. This helped move trends in Flash’s direction, as seemingly every great site was build using the plugin technology. IE7 had come out that same year, but it only added to developers’ pain in the short-term, and it still wasn’t the robust interoperable platform that browser ecosystem needed to compete in the applications space. So in that space, movement continued toward Flash.

This could be considered the golden age for Flash. Flash ruled the content space during that time, in everything from banner ads, to browser-based games, to anything dealing with charts, and data (so-called RIAs), to just about all the video delivery on the internet.

Browsers didn’t come without problems. They have been slow to innovate, incompatible with one another – universally slow, buggy and crashy – and often full of horrible security holes (especially IE – the dominant player). They were mired in standards battles, forks, company and social politics (open source/EU fines) – but mostly, the leader – Microsoft with IE6, just held everything up. On top of all that, it was difficult for content producers, like traditional newspapers, to find revenue sources other than ad systems. The market was set for change.

That’s about when Apple fired the first warning shots across the bows of the PC browser fleet, by releasing the first iPhone, which could browse the internet, but didn’t run Flash. A brand new platform – software and hardware, with a brand new interface paradigm – touch, instead of mouse and keyboard. This would be a platform built from the lessons of the browser era, and it provided a wide open space for Apple to do what it does best. They rapidly iterated on their ecosystem, and came up with the overwhelmingly successful App Store, a system that seemingly everyone wanted in to. This was a system that came with multiple obvious revenue systems built right in – app sales, technology cross-licensing, advertising, etc. – all things that could be done in the browser space, but the app store made exceedingly convenient, to both producers and consumers. Apple catered to that demand masterfully, and over time expanded opportunities to include, in-app purchases, magazine publishing platforms, and subscriptions services, among others.

In the same way the internet – the modern PC era – had provided enough advantages over the previous content delivery systems to overshadow any of its shortcomings, the App Store model would provide enough promise to overshadow its possible shortcomings measured against its predecessor. App stores proved so compelling, and so big a threat to the existing browser-based models, it almost immediately ended a cozy relationship between Apple and Google, who ruled the browser era, as the gatekeeper to content, and the owner of essentially all advertising on the web. Google moved quickly to duplicate the app system  for Android, and the other platform makers – WebOS, and Microsoft Windows Phone 7 Series – have been playing catch-up ever since. Eventually, Apple brought the app store system to the desktop in OSX Lion, and even Microsoft is picking it up in their Windows 8 Metro interface for full app store coverage in the traditional PC markets.

The rapidly evolving iPhone (later iOS) platform created new ways to think about a lot things. The most important new things were app and content delivery, and revenue sources through new monetization strategies. The Apple App Store changed everything.

The end of an era

When Apple released the iPad in April, 2010, Steve Jobs announced the “end of the PC era.” With the release of the iPad Apple did nothing less than complete and publish the rule book rewrite they began with the iPhone. More than anyone else, the folks at Apple seemed to understand that there is a divide between the “PC era” – which is really the “PC browser era” – and the new app store era. They understood that these two are on two different trajectories, and the app store era will supersede the browser. From now on, for better or for worse, applications would exist in App Stores, and websites would just be websites.

In the same month Apple announced the iPad, Steve Jobs followed up with a special letter in his open letter titled “Thoughts on Flash”, which highlighted some of the negatives of the browser-based “PC era,” where Flash was settling in as the dominant platform. The letter also exploited a division between the Flash crowd and the standards and open source crowds. And he directly addressed the “full web,” – Adobe’s tone-deaf name for “the PC era”. In that direct critique Jobs highlighted the disadvantages of the new app store model, by putting the “full web” flash apps in the “free” – or unprofitable box, and painting the technology with the old brush. Even the main part of the label “PC” is an old term, from a time that came before the modern browser era.

That letter was truly a brilliant piece of market positioning magic, but it was ultimately unnecessary, and Apple has since backed off. The app store model provides a marvelous promise without the need to degenerate the old browser based economy. Content makers, all of whom struggled to find revenue from websites, now have multiple new revenue streams to explore, through app sales, and licensing, and other kinds of content transactions within apps.

During the PC Era, browsers dominated users’ mind share, and time on the PC, native applications were still the clear leaders in performance, access to hardware, and close integration with the underlying OS platform. Despite that advantage, native apps were hamstrung by seemingly insurmountable inconvenience – the boxed distribution model – an inconvenience that most online distribution stores of the time simply duplicated (download, unzip setup, run setup, store setup file somewhere in case you lose your hard drive, etc.).

App stores solve these native application distribution problems by providing a central hub for content, simple e-commerce (no more credit card into the random unverified website), and can be integrated with the legacy system – the website.

My head hurts.

So what does this all mean for us, the front line Flash developers? It means opportunity. There are now three platforms to develop for!

Yeah, that’s right – three.

The transition to app stores on the desktop will take a while to roll out, and old habbits die hard, and Flash will stick around in that space for .. well, as long as that space exists. There are still a chunk of 98%+ of the user out there on the internet, still accessing the web through their existing PCs. That won’t change overnight. Even initiatives like Microsoft’s plugin blockade with Windows 8 and Metro mode take effect, they will come hand in hand with app stores, so there’s a workaround.

But let’s get real for a second, the Flash Player – in the browser – sits at the core of entire new lucrative markets on the PC, in the browser. Take browser era social gaming and Zynga – a game company, with a quirky social media, micro-transaction game library, integrated with Facebook’s social platform, is more profitable than top traditional PC game companies like E.A. Flash in the browser is having a grand time. Stage3d was just released, Unreal Engine was shown running on it at MAX. Flash is still tops for the best kinds of awesome on the internet.

Second, you have all the HTML5 opportunity – not directly relevant for Flash devs (yet), but for those of us that have had their hands in both worlds this whole time, this is exciting! HTML, JavaScript and CSS are finally getting to the point where you can build really awesome stuff with it. And, for app store monetization to work, discovery is key. Searchable HTML (and HTML5) will dominate for that. App stores are easy to search and easy to link into – from a website. Websites aren’t going anywhere – in every way, the app store model can’t work without the browser based internet.

And finally, the new kid on the block, the app store. For Flash devs, that means AIR – which is essentially Flash for app stores. If you have Flash (or even HTML) skills to burn, you can almost, just recompile your Flash app for AIR. Adobe has built this amazing tool – the best kept secret they didn’t mean to keep (don’t get me started on their PR). The sky is the start with AIR for Mobile, never mind the limit (Apollo indeed). The best part is, once you build for one app store with AIR, you can build for basically all of them, with very little additional effort.

Have a look at Machinarium. A traditionally packaged standalone desktop app, made with Flash, and distributed in a box through traditional outlets (and the specialty PC app stores, like Steam) with an online demo that runs in the desktop browser in Flash Player. Now republished for the Apple App Store with AIR and some optimizations, to run on iPad as a native app.

So where are we? Flash is alive and kicking – thriving even – despite the clueless ramblings of know-nothing media pundits and their bandwagon seeking behavior. You don’t need to listen to them, just get out there, and make cool apps/websites/games/whatever else with the same technology you’ve always used. These are exciting times.

Some caveats – this only tests instances of flash.display.Bitmap on the display list, at the size they are, moving the way they move. It’s on my list to add Blitting (I have some initial work on that done, thanks to Iain, but I need to add the rotation, and alpha settings to it), and I’d like to add a vector test, and maybe some extra sized Bitmaps (I’ve heard that makes a difference).

Enough! Here are some results – quality had no effect on GPU mode, so I included only one line:

Note: some are reporting they see a difference in GPU mode, but I still don’t. Update: It appears some users are confusing “Mobile Performance Tester” with BunnyMark, which explains the discrepancy. BunnyMark is not currently in any App Store, which is one key distinguishing feature.

Notes about the Benchmark:

• In general, the CPU mode seems pretty consistent with the way you’d expect things to work on the desktop – the same optimizations you’d apply for the browser plugin, you’d also apply to mobile for CPU mode.
• Rotation in this benchmark is not continuous – the Bunny graphics are only rotated at the edge of the stage, which is why cacheAsBitmap works to speed those up. If they were constantly updated, it would likely be much more expensive on CPU mode (probably more like rotation without CaB).
• Alpha is continuous – the alpha value of each Bunny is based on the y position and is updated every frame. I would like to add a mode similar to the rotation, so see what effect CaB has on alpha transparent objects that don’t constantly change.
• iPhone 4 and 3GS numbers aren’t directly comparable for practical purposes. The Bitmaps on the screen on 3GS take up much more real estate, since the 3GS screen res has 1/4 as many pixels as the iPhone 4. In a normal app, we’d probably resize things to look comparable between the two devices. I’ll try to add a mode that makes this more comparable (because I suspect we’ll find that 3GS can keep up with iPhone 4 with similar looking content).
• Touching the screen seems to cost about 4 fps across the board.
• I think there may be an issue with returning to rotation = 0 costing some performance in GPU mode. Still have to test that.
• I’m definitely getting some variance on default speeds – basically, before any settings are messed with on some runs I get the faster numbers (the baseline numbers in the tables above). Other times it runs at default settings a couple of FPS slower (on start, or after resetting the switches). With any of the settings, everything is consistent across multiple runs.

It’d be nice to have more benchmarks for more devices, but I only have the above devices available. This should run just fine on Android, Blackberry Playbook, and iPads. If anyone wants to contribute a set of benchmarks, hit the comments. Here is the source. One of these days I’ll make another post, and try to draw some conclusions, maybe wrap the bullet points into a narrative, and edit some of this, but the tables are there, and the source code, and that’s the important stuff.

In the midst of playing with this benchmark, I found (or was pointed at) some great resources. Here are some of them:

• Understanding GPU Rendering in Adobe AIR for Mobile – Ton of good info here.
• Mobile Performance Tester — Now Live in App Stores – This is very similar to what I’ve done, and has some of the same kinds of tests. It shows some different results though, which I’m a bit confused about. I suspect it has something to do with using larger images, which have more alpha transparency (smoother edges). I intend to look at it more closely to see what’s up in there.
• Original BunnyMark by Iain Lobb
• Source for BunnyMark for AIR Mobile

Here is the Benchmark to see it in action:

Improvements in version 2.0.1:

The meta box has been improved to provide a tabbed interface for less clutter, and syntax highlight and formating is added using the open-source CodeMirror 2.1.

An option has been added to allow adding script to the head element in addition to the traditional bottom of the page spot.

An Options page (under Tools) has been added so you can add Script n Styles to the entire site, rather then just the individual posts and pages.

Some minor code improvements:

• Better selection of post_types.
• micro-optimization for storage of class names.
• Defined a later priority for Scripts n Styles to print after other scripts and styles.
• Better adherence to coding standards.
• began contextual help (notes on capabilities).

It depends on how you split that hair.

I think it depends on what platform level (hardware, OS, etc.) the particular user of the word native thinks that word applies to. It seems many use the word to refer to the actual bytecode and whether it matches the hardware (the CPU) – but in those cases I often see the term native used with the CPU architecture in the description – such as native ARM, or not native x86. iOS apps compiled with AIR 2.6 I’d say are compiled to native ARM bytecode.

There are other ways to parse it though – for example, it was pointed out to me that AIR for iOS apps are compiled from ABC bytecode into ARM bytecode to avoid the JIT (and Apple’s restrictions on the use of JIT), but that code still uses the virtual machine – the garbage collector, sandbox and whatnot. This gets right up to the edge of my understanding of virtual machines. But, if the use of a VM precludes an app from being called native then could .NET be native on Windows, or Dalvik apps on Android? In the case of .NET, there is even a JIT (pretty sure on that one, but not entirely so).

Then there’s the issue of targeted API (and ABI) – if an app is compiled to run on Windows, but is running in a VM on Linux, it’s probably not native (even though it’s CPU architecture probably matches), but if it runs in WINE on Linux, is that native?

Speaking of the Linux crowd – they parse their platforms even more granularity – Gnome apps, running on KDE are not native to some people, simply because they use a different GUI toolkit, though something running in an interpreted language like Python are native if they use the “native” GUI toolkit. Games are not subject to this line of reasoning – if it runs on Linux in OpenGL (without WINE) then it’s native.

I even remember reading some opinions in various places that programs not written in C are not native to Linux, and programs not written in C++ are not native to Windows – despite those programs using all the same APIs, ABIs, and not running a in VM.

So what is my opinion? As it relates to my current favorite target platform, I wouldn’t call an AIR app native – especially since it requires a 3rd party runtime to be installed separately (like on Android or desktops), and doesn’t have access to the native GUI toolkits and widgets and other OS APIs. That’s not a hard and fast opinion though, my definition of native is pretty malleable, and likely to change over time (or over the course of writing this response). I think I’d have a hard time selling the idea that a Java or AIR app is native to a client – on Android mostly because of the separate runtime requirement – and on all platforms, because of the lack of access to OS level APIs. It would feel disingenuous to call an AIR app a native app.

AIR for iOS comes closest to being reasonably called a native app – it is compiled as a complete standalone package, and runs pretty close to the metal (being compiled to ARM code) – and most importantly doesn’t require a third party runtime to be installed separately. If AIR for iOS apps had access to the native (underlying OS platform) GUI toolkit and other APIs, I would be more comfortable calling it native, though probably still wouldn’t.

Probably the best definition of “native” I could come up (which you still won’t get anywhere close to universal agreement on) is an app that comes out of using the platform maker’s tools to develop apps for the platform – XCode + Objective-C (and other supported languages) for OSX and iOS, Visual Studio for Windows and Windows Phone, Android SDK for Android – even using Adobe’s tools to make an AIR app makes it a “native” AIR app – where using HaXe may not count as native.

Generally though, as much as I could, I would try not to discuss whether or not an app development tool like AIR is native at all – especially since that term is so subjective. A project needs a particular problem solved, and if I can do that with AIR (on iOS that means it doesn’t require iOS GUI elements and conventions, or other features of iOS), then that’s what I’d recommend.

Update: AIR 3.0 closes this gap, and makes the “Native App” comparison easier because of two features; 1. Captive runtime – no more separate runtime requirement means it’s a standalone app. 2. Native Extensions – now an app has access to all the native functionality of the underlying platform. I’m comfortable calling an AIR app a Native App with AIR 3.0.

If your theme is getting unwanted scroll-bars because of the new Admin Bar is WordPress 3.1, the core team included a way to handle it. Add Theme Support for it!

With a full height layout, you’ll want to avoid adding a margin or padding to a height that is already at 100% because you’ll get useless scrollbars, and no one wants that. Instead, find the first non-full height element (usually #header or some-such), and apply the margin there (either the 28px for the height of the admin bar, or add 28 to the existing margin if the element already has one). In the code snippet below I assumed you’d create an element or assign the class ‘admin-bar-fix’ to an existing element.

In your theme’s function file, add the following and modify as you see fit: (best to leave out the closing php tag though)

This snippet is derived from the TwentyTen Theme’s function file. The callback’s original code can be found in the source. Original snippet also found commented in the source (props ocean90).

Basically, by declaring support for the new (as of 3.1) “Admin Bar,” you declare that you can handle how your theme’s content gets “bumped” (by default, it gets pushed down by 28px via a margin on the html.) Most of the time the default behavior is fine… but it’s not fine on theme’s that have a height declaration of 100% (even min-height) or that have external scripts that declare 100% height on the html/body (like Google Translate does).

WordPress’s admin needed a similar treatment but that got patched. The 28px margin is just a default to handle most normal cases. Your theme is your responsibility

Cheers! Hope this saves some time for someone!

Update: Admin Bar Shim!

If you don’t have a 100% height type of layout but are annoyed by improperly scrolling anchored links try the following.

If you add a >div id=”admin-bar-shim”> (for lack of a better name) in your theme surrounding everything inside the body except the wp_footer call (where the admin-bar gets echoed), you can add

to your style sheet, or use the method above adding the callback. This new method allows anchor links to scroll properly.

Download unBrix Alpha and let me know what you think! I’d provide a link, but I don’t know how.

Update: I Nerfed the framerate a bit to get it to run a little smoother. I think the problem will be solved better by setting NO_SCALE, but I’ll have to do that another time (probably when I get to iPad port!). I also fixed the red line, and the icon too (I don’t know that didn’t show up last time). There is a report of the paddle jumping to one side when some users remove their finger from the screen. I haven’t been able to reproduce, but please let me know if this happens to you! Here is a link to unBrix Alpha on appbrain (it isn’t showing the update yet).

Update 2: I switched to CPU rendering, because it seems as though GPU rendering is just slower on Android devices than CPU rendering – at least in this kind of game. Anyway, this solved a lot of problems, including missing text and missing affects. I also had to set a fullScreenRect to match the original intended size of the game (iPhone 3Gs size). Doing these two things cleaned up most of the performance issues and graphics glitches. I’ll work on getting the remainder of the basics in place, like proper shutdowns – so this doesn’t run in the background like it does now (didn’t have to worry about that for iOS!).

This won’t run at 60FPS on Android Flash Player plugin in the browser (or Firefox on Mac!) – this post is about the iPhone build – but here’s the web version to look at anyway.

Here is a blurry video of the thing running as a native iPhone app on a 3GS (I smoothed out the choppy splash transition in a later build by setting the BG element with cacheAsBitmapMatrix):

The most important thing was to make sure GPU acceleration was working, and to learn what things will impact performance in that area.

It turns out, there are some important differences with how GPU accelerated Flash woks compared with the traditional software renderer. In the software Flash renderer keeping your display list shallow, and sparse (using addChild/removeChild a lot) or avoiding the display list completely (by writing to BitmapData – as the Flixel game engine does) is a key optimization for performance. This is how the exploding bunny video demo is done, and why it’s so fast.

My current theory is that on GPU accelerated content (even on desktop) the reverse is true. You want to avoid CPU/system RAM to GPU/video RAM updates as much as possible – which means avoiding BitmapData updates which cause the player to upload a new texture to the GPU VRAM with every update. Because I don’t have access to the internals of the Flash Player architecture, I can’t be sure, but I think the bottle neck comes from clogging up the lanes between the CPU and GPU, and all stressing all three areas of the rendering pipeline (CPU, GPU and the bus) as they juggle around objects in memory. The key observation this conclusion is based on is the large performance impact addChild and removeChild has on the framerate. So I relentlessly avoid that in my iPhone Flash development – I precache everything, and don’t mess with the display list. This is also one reason why filters (which operate on a BitmapData representation of the DisplayObject you apply them to) are not recommended on mobile content.

Anyway, hopefully I can turn this into a full app for iPhone in a reasonable timeframe.

Ever need to add a CSS style or some code snippet to just one page or post in WordPress? We release an admin tool to do just that.

On the post edit screen of the admin, Scripts n Styles adds a meta box where you can add JavaScript, CSS or even add class names to the body tag or the post content wrapper (as long as the theme supports wp_head, wp_footer, body_class, and post_class functions and almost all do).

The plugin is available on WordPress.org Extend (and therefor your plugin admin screen ). You can also fork it on Github. It’s licensed GPLv2. (current version 1.0.2)

Enjoy!

History Keeper does not provide any state management features beyond the information you store on the actual deep link (URL hash). However, you should be able to use the deep link information to grab the data you need out of a standard JS object (using it like a hash table):

Once you have your values stored like that you can use the storage object to lookup your chunk of data by the deep link string:

You can make the “value” as deep as you want ( key: {more: “complex”} ), I only used a simple string for demonstration purposes.

This example is JavaScript, but the concepts are the same for Actionscript as well.

I hope that helps!

Steve Jobs is full of crap. I could actually understand and respect a straightforward admission that the Flash Platform is a threat to Apple’s iOS business model – which is the real reason Jobs won’t let Flash on the iPhone and iPad. That’s not even a very good reason – the App Store has many compelling features on it’s own, even if Flash is in the browser, not the least of which is the easy to understand path to monitization. Performance is another issue – Flash is fast enough, faster than JS/Canvas by quite a bit, but it’s still not as fast as a native app and all it’s OpenGL goodness (among all the other great Apple APIs). Keeping Flash off iPhone (and especially CS5 iPhone apps) has nothing to do with performance, or compatibility. That’s just bunk! And nobody likes a liar.

/rant

Here are some screenshots to show how well many sites I’ve been involved with work in Flash on the iPhone (3GS using jailbreak and Frash).

A quit note on the technology: this is using Frash, which is a hack (a wrapper or compatibility layer) to get the Android version of Flash Player 10.1 running inside of iOS – it has not been optimized (or even completed at this point) to run well on iOS yet, and probably will never run as well as it can on Android. A recent test app I’ve been playing with runs 50% faster on a Droid Eris, vs. the iPhone 3GS – the Eris is slower hardware, running Android 2.1. It’s also crashy, and is missing features like streaming movie support (it does work with videos embedded in a swf) – and touch events are not quite as streamlined as they are on a real Android device (hover works better on Android for example, and hot spots are easier to hit). It’s also got all the quirks of the Wii and desktop Flash Player’s “noscale” feature (on Android there is a workaround that solves this, not implemented in Frash yet).

I just like to point that out, because some users are judging the viability of Flash on iOS/iPhone/iPad based on this hack (which is current at version 0.02), which is beyond silly.

For anyone interested, I followed these instructions to install it on my iPhone. Note: this uses SSH and dpkg to install. If you don’t know how to reverse that, you may want to find an apt repo and use Cydia to grab this, so you can uninstall Frash when you are done playing, as it can be quite unstable.

So the first thing I needed to figured out was what functions needed to be filtered to let me add the plugin directory to the locations that WordPress checks for. I eventually found the appropriate ones by reading the source code and asking in the #wordpress IRC chat (not #wordpress-dev, that’d be the wrong chat to ask this kind of question). “get_single_template()” and “get_taxonomy_template()” are the functions of interest and they in turn call “locate_template()” which is the function we need to rewrite.

(reference: ‘function locate_template‘)

The “locate_plugin_template()” function is a direct copy of “locate_template” function but I added the $this_plugin_dir variable (using code I found on the wordpress.org forums) and added a 3rd check to the foreach loop. (Some of the code here can be removed, for example the $load check with the load_template() call, as our code won’t be invoking it but I left it to better reflect the source.)

Next we have to filter the appropriate functions to call our new function.

There’s not much in the original functions that need to be changed:

(reference ‘function get_taxonomy_template‘)

There’s some bonus remove_filter calls at the beginning and ‘locate_template’ is replace by ‘locate_plugin_template’. The only other thing is that we simply return the $template variable instead of using ‘apply_filters’ (I got errors when trying to apply the filter while running the filter filtering the filter :-/). There is also a check to see if we are working with our own taxonomy: The code in the if statement doesn’t really need to run again unless it’s one of our taxonomies, else it’ll just return the original $template.

The single template function filter is much the same:

(reference ‘function get_single_template‘)

Now, this isn’t a perfect solution. For example, themes have much varying structures, so building a template that’s compatible with Twenty Ten wouldn’t necessarily be compatible with any other theme. If the theme isn’t compatible, it could be bad since you’ve interrupted the fallback that the theme provides in favor of yours. You should probably include a check to see if the current theme is the theme you are targeting. I suggest you use this code in a plugin that is basically a companion plugin for your own theme or framework. Additionally, you could offer template tag functions, shortcodes, and widgets as a more robust solution.

I wanted to see how far I could push that exploding Actionscript 3.0 code – see if Flash could handle updating each animating pixel every frame, while playing a video, then blurring it. Sure enough, it can! It did take further optimization from the version I posted the other day – including swapping copyPixels with getPixel/setPixel, and removing an anonymous function call (wow that was expensive!). Here it is:

Note: This WILL run like slush on the debug player. I don’t know why. If anyone knows why, please let me know!

Well I guess technically the pixels don’t explode as much as the DisplayObject explodes into pixels! I recently needed an effect that would make a bitmap image look sparkley, so I did some goggling, and game across a Firefly particle effect on a blog post belonging to Erik Hallander (at least I think so, the blog has been down for months, so I can’t double check). This pretty impressive effect looks like the following example (I hope reposting it here is not a problem).

Note: This is a modified version of the original adding the Stats.as box, and autolooping – and removes the actual firefly affect (I didn’t need that part for my purposes).

Very nice start! I don’t get an FPS problem – on my computer the example above rocks 62/60 fps (25% CPU on my Core 2 Duo)! So FPS was not the big problem. This example uses over ~19-23MB of RAM (with a lot of fluctuation)! And that is with 2×2 pixels, it goes up higher with 1×1 pixels. Additionally, this example already has an optimization in it to skip over empty (black) pixels in the DisplayObject it works on – which leads to a significant RAM savings.

Using the display list this way – and two filters per DisplayObject – it began causing the player to kick up a lot of invalid BitmapData/null reference errors (which I’m guessing is what happens when you run out of memory, since many many checks confirmed that the BitmapData was not invalid) – especially when I tried to make it work on 1×1 pixels to animate every pixel.

So the first thing I did was to clean up some of the obvious stuff, to bring down the memory usage – in the original blog post, Erik noted that this was unoptimized code, so I knew what I was getting into. I did things like remove the extra nested DisplayObjects (each pixel was a subclasses Sprite instance, with a BitmapData added to it), and cleaned up extra variables that were laying around, moved a lot of things inline, reused as many variables as I could, cutting down on object instantiation – and followed a lot of the other tips in a conveniently timed ByteArray post. Doing that really helped – I cut the memory use about in half – and on the initial animation (a black and white logo) the affect seemed worked quite well. But it didn’t scale well – larger images simply wouldn’t work.

I still wanted to use this affect, and I’ve seen many thousands of pixels being animated before – so I knew it was possible. So a radical departure. I’ve been reading about drawing directly to Bitmaps for quite a while, and that was going to be my path. So more optimizations – removed the display list code completely, changed the Pixel class to a simply property class (where are the enums?!), and used that to store information about where in the original source to look for the pixel data as well as other relevant animation data (most of which was already done for me – thanks!) for each pixel block. I also removed dependence on TweenMax – which is what the original uses for all the animations – and used the easing equations directly, within an ENTER_FRAME event.

The result is a RAM reduction by 25% and a steadier memory usage, coming in at ~5MB with 4x as many pixels (and roughly the same amount of CPU). The changes utilize copyPixels and a linked list, with an accumulation buffer like effect – for a total of 3 bitmaps (the original, which is rendered from the DisplayObject and stored, the scattered one the pixels get copied into, and the copy of that that gets blurred by the BlurFilter – a hidden memory cost illuminated by Thibault Imbert).

There are further optimizations that can be used as well (and should really be used for full image per pixel animations) – such as writing to an opaque BitmapData, rather than one with Alpha, and reducing the BlurFilter quality – getting a better handle on type marshaling, etc. It might also be faster to store the RGB value of each pixel, and draw those directly instead of using copyPixels, but I haven’t tried that yet.

I got so much help from the Flash community on this, that it would be irresponsible not to share this back, so feel free to check out the source.

Some Notes:

The memory usage applies to both swfs on this page – so you can’t see the memory usage difference in these examples. I quoted the standalone Flash Player in this post.

Also, I’m getting some kind of performance problem in plugin browsers (everything except IE) on Windows, and on every browser on mac but Firefox which is limiting both of these to around 30FPS. I have no idea what’s causing it.

On the code quality – the code isn’t all that messy IMHO, but it is not well documented, and a lot of the configuration hooks I left in are not really being utilized in a decent API – I may refactor at some point to clean that up. There is also a limitation of the skip pixel check that will keep it from working well for greater than 1×1 pixel size (since it only checks the top left corner of the size rect).

Enjoy!

I wanted to try to find a solution that did not require the layout of hundreds of dollars just to test out how well (or not) the 3D of these systems actually worked, so I wondered if there was a way to test these out, with minimal cost – sure enough, both available 3D graphics drivers support anaglyph mode to preview the tech. The third option anaglyph – you may remember this trick from super bowl half time commercials, and cereal box addins. First up is nVidia’s solution is slightly

For nVidia 3D Vision Discover, you’ll need to make sure you have a beefy enough nVidia video card – ATi users are out of luck. As luck would have it, I have a supported card, an 8800GT (the lowest end card supported!). To turn it on, follow the instructions on nVidia’s 3D Vision Setup page. Make sure you have both the correct version of display drivers, and the 3D Vision drivers.

If you don’t have the correct glasses colors (as I didn’t – I used magenta/green glasses backwards from Monster’s Vs. Aliens DVD – eventually I replaced one lense with a red one from a children’s spy kit I got from Friendly’s) it may be a little tricky to enable the affect in nVidida’s drivers if you don’t have the correct colored glasses, since they don’t actually let you turn it on without testing you first. Just guess at what the answers are and press back if you get it wrong – there are not that many combinations of answers, and you’ll eventually get it right.  Once you do that, you’ll have an option to turn this all on in the Stereoscopic 3D section of your NVIDIA Control Panel (right click desktop to get there), or use the CTRL + T shortcut to turn it on.

The nVidia drivers work amazingly well on Valve Source engine based games – like Left 4 Dead and Team Fortress 2. In some parts of Left 4 Dead 2, such as the sugar cane fields on the return trip level of Heavy Rain, it may even give you a bit of an advantage, since you can see the depth of the plants – it’s much easier to see where you are going. They did less well in older UT3 engine based games, like Bioshock, where you can see noticeable gaps around some objects where the fog effects just don’t line up correctly in both eyes (it’s shifted to the right or left, for each eye respectively), and certain shadows are lost. Newer UT3 games, like Batman .. Arkham Asylum, which claims out of the box support for nVidia 3D Vision, and Avatar, which has 3D support that must be enabled in game, look phenomenal. (For Avatar you need to set nVidia stereoscopic view on in the driver first and then the game to get it to work). Other Ubisoft games like Assassin’s Creed and Prince of Persia also look great.

Another option is to use the iZ3D 3D drivers – which work with any 3D card, including ATi Radeon. iZ3D sells a line of specialized monitors that actually polarize two images (similar to how many 3D movie screens work), and use passive glasses to filter out each image from the correct eye, thus presenting two different images to each eye. You don’t need a 3D monitor to use the drivers though, as they have a free anaglyph mode built in (among other modes). These drivers seem to incur a greater performance hit than the nVidia glasses – but despite many posts (seemingly little more than assumptions) I’ve found on forums and blog posts, I actually found them more compatible than nVidia’s drivers, especially in Bioshock, which is downright amazing in 3D (despite missing many shadows). These drivers don’t start out with the modest 3D settings as the nVidia’s more out of the box settings, but once you tweak these (there are more options for tweaking, and each game starts out with a tweaking guide overlay to help you out), you should be up and running.

The best part of the iZ3D drivers is that you can actually change the color settings of the anaglyph mode (apparently you used to be able to do that for nVidia, but they removed that ability). This is fantastic, because it means you can get all the colors, with less ghosting that you’d miss if you don’t use the correct glasses with the nVidia drivers. Most anaglyphs actually separate 3 colors, not just two – one channel (red) to one eye and the other two channels (green + blue = cyan) to the other. In my case, I am using green and magenta (blue + red). The fact that blue is being split to the wrong eye is why you get ghosting with the nvidia drivers and the Monsters Vs. Aliens (or Coraline) glasses.

Here’s a quick guide to change the anaglyph colors for iZ3D drivers. First find the correct config file – for me (Windows 7) it was:

C:UsersAll UsersiZ3D Driver

I can’t confirm these two, but they helped me find the location in Windows 7 - from the iZ3D forums:

XP: “Documents and SettingsAll UsersApplication DataiZ3D DriverLanguage”

Vista: “ProgramDataiZ3D DriverLanguage”

Once you have opened the Config.xml file in one of those folders, you can edit the following items to make it green/magenta:

In case you are interested, here is a quick key for what these values actually mean – or at least 3 of them – it’s matrix math which is hard :

m00=”R” m01=”0″ m02=”0″
m10=”0″ m11=”G” m12=”0″
m20=”0″ m21=”0″ m22=”B“

There are bugs and drawbacks with each solution – most games were not made with 3D in mind, so this can be a bit of a hack. Some games are missing shadows or have misaligned affects (like Bioshock), and I couldn’t get OpenGL games to work at all with either driver (despite settings for it in iZ3D). Other games seem to perform flawlessly (like Left 4 Dead, Batman or Avatar). Another big drawback of these systems is the cost – full color 3D setups can be pretty expensive $300-$400 for the monitor, and another $200 for the glasses (and an additional $150 for each pair you want to add for group movie watching). The iZ3D solution (and Zalman makes a compatible monitor) are getting cheaper, but are still quite pricey at around $300 for the monitor and cheaper passive glasses (with no other special requirements/costs, except some kind of reasonably strong video card).

The affect is pretty convincing for me though, and since I already have a nice 120Hz monitor, and a decent enough graphics card, I’ll be adding nVidia Shutter glasses to my birthday list.