I gave a talk on the PushButton Engine at the Flash Gaming Summit a few weeks ago, titled “PushButton Engine 101.” It is available online, thanks to Adobe’s kind support in sponsoring FGS and recording the sessions. You can view the PushButton Engine 101 talk here. It’s about 40 minutes long. People seemed to like it!

If you have comments/questions/feedback, I highly recommend visiting the PushButton Engine forums thread about it.

The Flash Gaming Summit was a blast. I got to spend time with the guys from 8bit Rocket, with Dan Cook, and, of course, the crews from Adobe and Mochi. For the second conference, Adam Saltsman eluded me, but I had a great conversation with Nicolas Cannasse about building companies. Lunch was spent with the PBE crew in attendance – JD Conley, Dion Whitehead, and a couple of others. I had a million other awesome conversations, too, which is why I love going to conferences.

Other than the very early start, I thought FGS went a lot better than last year. (Perhaps because they had me on the advisory board – conference organizers take note! ) They had a solid tech track in addition to their business track. Maybe next year it can be two days – or just start a little later.

I wanted to post some real world information on Adobe’s latest big announcement, Adobe Flash Applications for iPhone. I participated in the pre-release beta along with several other very talented Flash developers. We got to be some of the first outsiders to work with the iPhone technology. To try out the tech, we wrote and shipped Trading Stuff in Outer Space in just 8 days.

By the way, if this is Flash on iPhone stuff is new to you, you should definitely read Aditya’s “Developing for the Apple iPhone using Flash” article on adobe.com. In addition to being an all around great guy, Aditya was also a huge help in working through the very early beta issues we encountered. Ted Patrick posted some cool iPhone example apps with source. (Not only does Ted make a good jedi, he also helped me debug some rendering issues in Trading Stuff at the last minute. Thanks, Ted!) And Mike Chambers, who brought me into the program, has posted more explanation with a lot of useful links for Flash/iPhone work.

It’s worth stating emphatically that Adobe has a large, talented team working hard on iPhone. I couldn’t hope to properly thank all the Adobe folk who explained, demonstrated, debugged, and implemented through long sleepless nights to build this tech and fix bugs so we could ship Trading Stuff. Guys, you rock!

A brief history of Ben – I spent five years working on 3D and 2D C++ game engine technology before I moved to Flash, so I have a little different background than most Flash developers.

Ok – thanks and context out of the way. Let’s get to the meat. What’s it like to develop for the iPhone with Flash?

First, the toolchain is fantastic. All you do to get on the iPhone is write a Flash app however you like, and then (more or less) click the “compile IPA” button. You get an IPA, you deploy it on your device, and bob’s your uncle. That’s the easy part, and it has been that easy since day one. (For comparison, I’ve seen builds with pre-release and final XBox 360 SDKs, with homebrew PSP and Nintendo DS, with PS3 and Wii – they are all a lot harder to start building on.) Sometimes takes a while for all the optimization to happen, but you don’t need that unless you are packaging a release for distribution.

Deploying to the iPhone is the easy part. The hard part is getting your content to run silky smooth and in an iPhone-friendly way. What do I mean by that? Performance? Sure, you have to be careful with performance, but you also need to make sure you respect the touch interface’s limitations, that you obey Apple’s guidelines, that your art fits the device, and so forth. We spent as much time on that stuff as we did on performance in Trading Stuff.

The main things to watch out for is rendering – you must use hardware acceleration, which acts a lot like cacheAsBitmap – and memory allocation – the iPhone has very slow memory, so the GC running is the kiss of death. I could list a bunch of specifics but at this stage in the game, they would be out of date by the next SDK update. The best thing to do in this and all other optimization cases is to measure, find the biggest bottleneck, change it, and measure again to see if you got a win. Repeat until you have adequate performance.

Louis Gerbarg posted a great analysis of the iPhone tech based on Trading Stuff. Since I wrote Trading Stuff, I figured I should comment on it.

On the LLVM piece, Adobe has put in major effort to make this function properly. And it really does work. Even on day one of the prerelease, the compiler worked pretty well. Occasionally you’d hit an optimizer error – but it’s worth noting that in LLVM most optimization operations are separate from the backend. IMHO, Adobe was very smart to use LLVM as opposed to rolling their own or repurposing GCC, due to code maintainability and extensibility issues. You will notice that they have used LLVM before in Alchemy, so there’s prior experience here. And though Louis cites Apple not using LLVM for iPhone compilation as a weakness, Apple is using LLVM for their desktop compilation, which shows that LLVM is going to be a good choice long term.

For the resource bundling, that’s entirely my fault – I chose to embed all my resources in my SWF and when the SWF was converted, it was converted to a binary with those resources in it. I could have put them alongside the SWF and they would have been bundled as part of the IPA (in fact, this is the case for Default.png, which is treated as a normal file even though it has special behavior thanks to OS X). I’m not so sure about this linker behavior Louis is referring to; checking the Mach-O segment reference doesn’t reveal any insights beyond that yes, it is probably bad to keep the compressed version of assets in RAM. But Trading Stuff isn’t paging anyway, making it a non-issue.

For the rendering performance, the build of Trading Stuff that is on the App Store is not using hardware acceleration at all. And the ARM11 is a crappy chip for software rendering. I was showing a build at Adobe MAX that used hardware rendering, and it runs smoothly, like a real game should. I am waiting for a few bugs in Adobe’s SDK to be fixed, at which point I will release a new version on the store. The performance difference is night and day. I’ll post about that when I get the update out.

Let me put a caveat here: the iPhone is something like a tenth of the machine your desktop PC is. So if you want to do incredible 3d graphics and hand-optimize your assembly, maybe you should look into using XCode and Objective C, and build your content and code explicitly for the iPhone. However, if you know Flash (or have a project in it to port) and want to put something out quickly, this is a fantastic path, and worth a look. And it’s only going to improve from this very early version.

Time for some closing thoughts. Adobe has shown that they value the platform and want to bring their content to it by making some serious technology investments. I hope that Apple will respect that, and work with Adobe to make sure Flash works well on the iPhone.

What’s the Flash community been saying about AS3 recently?

• Nicolas Canasse, the guy behind haXe, wrote an insightful article about whether AS3 has really delivered on its promises. Lack of language feature velocity and lack of conciseness are his major points.
• Joa Ebert, a talented Flash hacker (AS3V, AS3C, etc.), is a little bit incensed about Adobe’s troubles with involving the community. He cites some examples where they have ignored code contributions.
• Even Andre Michelle, of Hobnox audioTool fame, and one of the guys who helped drive the Make Some Noise petition to get Adobe to improve audio in FP, has weighed in in some areas where Flash should improve.

I’ll be honest about where I stand on this. Flash 9 is great, 10 even better. For desktop/web interactive apps I am very happy. There are a lot of things that would be nice to see, and a few things that need to be fixed. But I would not have stopped doing C++ 3d game development unless Flash was good.

I hope to see Adobe releasing a lot of improvements to AS3 (perhaps even an AS4 someday!), and there are some features, like generics, delegates, overloads, and enums, that would make my daily life easier. But the fact is that being able to target a single, mostly consistent platform with AS3 is great, and that there are nearly a billion people with Flash Player makes it very worthwhile. It is easy to create quality interactive content accessible by hundreds of millions of people in Flash, and that is a huge win.

If I had to agree with one complaint out of all the comments by my fellow Flash developers, it would be that Adobe is having some trouble getting the community involved in what they are doing. I can’t blame them – the Flash community is hugely varied in skill level and interest area. You have artists using it to create TV shows, web content, and deliver video. At the same time, there are skilled coders building DAWs and 3d renderers. There are developers making games and building business applications. I’m not sure there’s a broader set of users out there.

The best thing to do in a situation like this is to stop treating Adobe like a big faceless company and start to get to know the people who work on Flash. In the last two years I’ve had opportunities to visit the Player VM team, the Flash Builder team, and several of the Flash community managers and members. Everyone on those teams is, in my experience, willing to listen to your problems and interested in improving their product. Obviously, they don’t implement every hair brained idea that I propose. But they listen and there is forward motion.

So what does this come down to? I have to agree with Ted’s advice from his The Future of Flash – be public about it. But also make sure you are reaching out to Adobe. They are human and they respond a lot better to respectful conversation from people they know than they do to internet rage.

Please make Flash into the ultimate console for the web and mobile devices.

Do not listen to the people who want you to make DRM. Centralized DRM for games doesn’t work. Adobe, we developers are a fearful lot and wish not to face the reality that all DRM can be cracked. It is much better for 3rd parties to do their own DRM. People will claim they want you to do DRM, but don’t listen to them. Adobe, they do not know what they are asking. A good fast crypto library would be nice, though.

Do not listen to the people who want you to add high-end GPU capabilities. Games don’t need to be able to launch a background thread that does deferred collision using a secondary GPU. They need to be fun. HW accelerated rendering on the platforms that can support it would be nice, but it is more important that there be consistent performance than that there be high performance on some computers and bad performance on others..

Do not listen to the people who want you to write their game logic for them. Adobe, they do not know it, but they are asking for a monoculture that will ruin your platform. Let the distributors and publishers create good high score and friend and sign on features. They will promote them and make them good because they are financially motivated to do so.

Do not listen to the people who want per-pixel collision primitives. For, lo, they are lazy as hell and do not realize that it is a bad idea to tie collision to visual appearance. Every serious game from Super Mario Bros on down implements collision using bounding volume checks behind the scenes. Many games use good collision libraries, which are more easily extended and debugged than native code in the Player.

Oh Adobe, devourer of companies, creator of digital art tools, hark unto the example of Microsoft. For were they not like the wild beast of the field, clueless as to the nature of game development? Then they created DirectX 1, and it was shitty. DirectX 2 was right out, and DirectX 3 could draw sprites ok but not do 3d for beans. Did it not take Microsoft fully eighteen revisions to achieve a game API that was good?

But what truly made their API good? Was it the functionality, which was adequate? No, it was the tools and the consistency! The consistency they achieved by enforcing it on hardware manufacturers and having strict standards! The developer tools they created for the XBox and the XBox 360! These excellent tools made developers love working with the XBox 360. Even Carmack switched to using the 360, because of these excellent tools!

Adobe, make Flash like unto a console! Give us consistent performance! Give us excellent tools! Flex Builder is not that great, Adobe. Your compilers could be a lot better, too. Don’t worry too much about lots of fancy features. People who have to have super high end 3d and do not want to run everywhere will use tools like Torque or Unity that do 3d really well. Be everywhere, run well, be easy to develop for, and you will be loved and well rewarded.

Adobe, I have a vested interest in you succeeding. Please listen to my words. I have spent years developing game middleware on a variety of platforms. Now I am working with Flash. If Flash dominates the game industry, it will be possible for me to afford to eat.

Please, Adobe. I am hungry.

Your Pal,
Ben

HaXe is cool not only for platform compatibility with things like the iPhone (and who knows – maybe other platforms like Android or Windows Mobile), but also for its language features. They deployed support for the new Flash 10 high-performance memory intrinsics before the official Adobe compiler. HaXe has generics/templates, decent conditional compilation, inlining, a big performance margin over AS3, as well as better memory management options.

And performance is a big deal when you’re an interpreted language trying to run on Netbooks and televisions.

Since my day (and sometimes nights, too) job is working on a Flash game framework, HaXe looms large on my radar. AS3 and HaXe can already interoperate so if you want to use a HaXe physics library from your ActionScript 3 code, there’s no problem. But should we switch the core engine over? Having a seamless way to target iPhone would be big. Having an easy way to run your server code without requiring an integration with Tamarin would also be nice.

Ralph Hauwert over at unitzeroone summarizes the HaXe situation very well:

The language is great and has many features ActionScript lacks. It baffles me how one man army nicolas can single handedly write a language and a multi target compiler, and in many respects stay on top of the ActionScript compiler.

My first problem with Haxe is just that. The one man army. Should nicolas decide he doesn’t feel like it anymore, the platform is dead. Sure, there’s more people working on it, but in it’s core it seems to be that nicolas is the driving force. My second problem is that although there is a huge pool of ActionScript developers, which can work together within the industry standard called ActionScript. There’s not even near that many people who’ve even touched haxe, let alone the number of developers who are able to call themselves “Haxe Professionals”.

HaXe is very cool. But it doesn’t have the ecosystem and infrastructure to justify targeting it exclusively. As a small startup, we only get to target one platform for our technology, and AS3, although it leaves performance on the table, wins in terms of the pool of potential developers and the accessibility of the toolchain. How many people out there are using PHP or Java vs. x86 assembly?

If the basic technology is good enough, ease of use always wins out over performance. So for now we are going to stick with ActionScript 3 for PushButton Engine. You can write compelling content on it. If you really need HaXe for something, the option is there to link it in.

But I want to put the plea out to Adobe. I love you guys and all you have done in the Flash space. But please update your compiler technology. At least give us the compiler optimization wins like inlining and generics. It’s simply embarassing that one guy’s work can outperform you on your own VM!

Adobe, you have smart people working for you. You have smart people in your community. You have pretty decent tools. None of us want to jump over to a third-party technology, but if HaXe keeps beating you at your own game, it might be necessary. Buy HaXe if you must, or else match it with your in-house tech, but either way – I know you can solve this problem.

The web is catching up with you on the player front. You could dominate on the tools front and make the world better for everyone. Please. As a middleware developer, I really don’t want to have to support anything other than a single mainstream language and platform.

Google released O3D, a web plugin for 3d rendering, today. It’s a pretty sweet piece of work. Definitely check it out if you have any interest in 3d rendering, the web, or JavaScript.

There are a couple of cool pieces to this puzzle, and I wanted to call them out to other people who might be reviewing this technology. The two sentence review: I am blown away. They got this right.

(FYI: This post isn’t meant to be a full walkthrough, just a quick indication of the cool jumping off points in the codebase.)

Stop number one is the graphics API abstraction. This is rooted in o3d/core/cross/renderer.h, which provides an abstract interface for performing render operations. This is sensibly designed, oriented for SM2.0 through SM4.0 level hardware. It will also deal with DX11 class hardware, although it won’t expose all of the niceties DX11 gets you. It wraps GL (o3d/core/cross/gl/) and D3D9 (o3d/core/win/d3d9). The purpose of all this is to provide a common ground for all the higher level code to issue draw commands from. It is not directly accessible from JavaScript (although some of the related classes like Sampler and State are.)

As an aside, writing a Pixomatic or Larrabee backend would not be hard. At GarageGames, we had a rendering API similar to this (unimaginatively called GFX), and it was fantastically useful. Last time I checked, there were DX8, DX9, DX10/11, GL, and Pixomatic backends for it in varying states of usefulness. We even had one guy write a backend that would stream draw commands over a socket, which was pretty cool. In the context of O3D, they have an implementation of Renderer that queues everything into command_buffer, then streams it to a command buffer server running in a separate thread, which issues the actual draw commands. It’s unclear whether this is used in the current version of the plugin based on casual inspection, but it’s a great example of what good design can get you.

The next piece is the DrawList, which is where most of the heavy lifting for drawing happens. JavaScript, of course, is not really desirable to have in your inner rendering loops, so you queue everything you want to draw (DrawElements) into a DrawList. This is wrapped by higher levels, of course, but it represents the lowest level API that’s available to JS code. All the sorting and state management to get stuff on screen happens in this area.

Alongside the DrawList stuff, you find the material system, which is pretty slick. You write your shaders in their shading language, and it converts to HLSL SM2.0 and Cg (arbvp1/arbfp1). This is enough to do almost anything you might want to (as fantastic as SM3.0+ is it’s not really necessary for most rendering). There’s a full SAS system so you can interface programmatically with your shaders.

Above this, you get into the scenegraph. Now, I subscribe to Tom Foryth’s views on scenegraphs, which is that they are basically a bad idea, but I think the Google guys were smart and set up their API so intelligent developers can avoid being screwed by the scenegraph. The scenegraph-esque stuff they do have (they call it a rendergraph) is powerful enough you can do most rendering without going nuts, and lets a lot of the heavy lifting stay in native code, where it will be fast. You end up doing retained mode-ish things, but since JS is slow, and most JS developers come from a DOM background, it works better than you might expect.

There are a lot of cool miscellaneous features, too. They embed the fast V8 JS engine right in the plugin so you can have consistently fast JS execution. They support falling back to an error texture (via Client.SetErrorTexture) when you fail to bind a sampler. You can group objects via Pack objects for easier management and stream things from archives, too. There are debugging aids and libraries for math and quaternions.

You should check out the samples. There’s a lot of impressive stuff. There’s the beach demo in the video at the top of this post, but they also do some cool stuff with animation, HUDs, text rendering, picking, and stenciled teapots. And everything is done in JavaScript right in the web page. Even the shaders are embedded in <script> tags!

O3D is a great piece of technology, and I hope it thrives. I’m excited to see what people build on this (and I’ve got a few ideas myself .

My Default Playstation Home Avatar

PlayStation Home came out not too long ago. Penny Arcade pretty much said what needs to be said about it, but I had to try it myself. Naturally the first thing you do is create your character from a randomized (I hope) default character.

To the left is the default character that I got.

…

Sony appears to be targeting the coveted 18-25 male Caucasian skinhead/serial killer demographic. I’m kind of surprised that they didn’t filter the default characters to avoid characters that appeared obviously threatening/defective. If this guy showed up at my front door, I’d call the cops.

Naturally, I ended up tweaking him to try and make him freakier, but honestly, what I ended up with was less terrifying. He resembled a creepy real life version of Robbie Rotten.

He stood out nicely compared to all the cookie cutter people on Home, but nobody really cared. In fact, it was hard to communicate with people or interact with the world at all. The loading times were ludicrous. The difference between last gen and this gen is that you can let things load in the background while you stare at the room you’re stuck in. Why would Sony spend millions of dollars and years of time on something like this?

Does anyone else get the feeling that big game projects don’t have fun on their agendas?

Most of these integrations are there just to post nice status messages from one place to another or provide a link to a profile. Why not use a central service like FriendFeed to handle the details? The FriendFeed API is almost there. If FriendFeed had better options for the API to push outwards, 90% of that service configuration box could go away.

My read is that the GPU guys don’t have a clue. A lot of their talent has moved on. They’re focusing on maximizing flops without realizing that it isn’t always the flops that matter – it’s how you spend them. There’s for sure a market for teraflops of raw power, but LRB’s feature set maps so beautifully to rendering that I think the reduced performance is going to more than make up for it.

The trend in rendering is towards branch-heavy shaders doing random access. GPUs are fast when you’re doing branchless shaders with linear access patterns – but the trend is forcing them into the realm that Intel has been dominating for thirty years.

I guess we’ll see where things are in five years. But you can see which way I want things to go.