It’s a worthwhile book for just about anyone interested in optimization. These guys are veteran experts in this field, and the book gives specific advice and practical tips in many areas. A huge range of topics are covered, the authors like to run various experiments and show where problems can occur (sometimes the cases are a bit pathological, but still interesting), and there are lots of bits of information to mull over. Long and short, recommended if you want to know about this subject.

You can read the rest of the review here or even (if you wanted to) buy your own copy of Video Game Optimization from Amazon.

Which reminded me I had never linked it here on my blog! So if you’re curious about why components are a great fit for games, I encourage you to watch my 5 minute video above, and check out the resources linked in Steffen’s post.

Have you struggled with the tools built into Flash Builder?

Well, if all you want is a basic functioning profiler, let me introduce the PBLabs Profiler! It shows you where your time is going:

It’s available under the GPL with source and binaries on GitHub. You can also post on the PBLabs Profiler forums. There is more information on the profiler in the forums and on the github site.

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.

More precisely, Eric Preisz and I wrote a book!

The book is called Video Game Optimization, and it covers everything you need to know to get maximum performance from any software project – but especially games. If you’re struggling with getting a great framerate out of your game, I highly recommend checking it out.

Video Game Optimization goes all the way from high-level concepts like planning for performance in your project’s timeline, to determining which broad area of your system is a bottleneck, down to specific tips and tricks for optimizing for space, time, and interactivity. Based on the course that Eric Preisz taught at Full Sail University on optimization, it isn’t the only book you’d ever want to read on the subject, but we think it is a great introduction!

The journey from that initial conversation where our mutual friend Jay Moore introduced us and suggested I would be a good co-author, to the day when we finished and shipped the book was a long but rewarding trek. Eric moved across the country from Florida to Nevada, as he moved from teaching at Full Sail University to running the Tech and Tools group at InstantAction. He also became a father with the arrival of his son, Grant. I left after 5 years at GarageGames and helped build a new company, PushButton Labs.

A lot has changed while we wrote it, but it still felt really good to arrive at GDC, visit the book store outside the exhibition hall, and finding a big stack of Video Game Optimization sitting front and center.

I spent a little time with Flash 10’s 3d features recently. Since Flash 10.1 is imminent and FP10 has been at 90%+ penetration for a while now, it’s probably safe to start looking at using FP10 stuff in my projects.

I also used this as an opportunity to try out git. It was easy to get git installed on OSX (I used the command line version, installed from git-osx-installer) and put my code up on Github. You can browse my test code at http://github.com/bengarney/garney-experiments/tree/master/exploringFlash3D/.

My main concern was the transformation pipeline – I think there might be some benefits to using 3d positions for the rendering pipeline in PBE. So I wanted to do a brief survey of the built-in 3d capabilities, then look more closely at the transformation routines.

My first test was making a DisplayObject rotate in 3d (minimal source code). It runs well, and if you turn on redraw region display, you can see that it’s properly calculating the parts of the screen that need to be modified.

This was easy to write, but it revealed the primary flaws with the built-in Flash 3d capabilities. First, look closely – the edges of the shape were sharp, but the interior detail is aliased. This is because whenever the 3D rendering path is engaged, it turns on cacheAsBitmap. This is fine for simple scenarios (say, taking a single element in a UI and giving it a nice transition) but not for more complex situations.

Which brings us to the second and bigger flaw. I added a thousand simple particle sprites at different 3d positions (source code). This runs extremely slowly because of an issue described by Keith Peters involving nested 3d transforms. Nested 3d objects cause excessive bitmap caching, dramatically reducing performance. You might end up with bitmap-caching in action on every 3d object and every DisplayObject containing 3d objects.

My next step was to stop using the 3d capabilities of DisplayObjects, and just position them in x/y based on their 3D position (source code, notice it is two files now). This gave a massive performance gain. At low quality, 1000 particles runs at 1440×700 at acceptable FPS. Most of the overhead is in the Flash renderer, not the code to update DisplayObject positions, but it still takes a while to do all the transformation, and it causes a lot of pressure on the garbage collector from all the 1000 temporary Vector3D instances that are created every frame. (600kb/second or so – not insignificant.)

Next I figured it would be helpful to make my camera move around (sample code).

This required that I understand the coordinate space all this operated in. What are the coordinate spaces? According to the official docs, screen XY maps to world XY. So forward is Z+, up is Y-, right is X+. Once I figured that out, I had to prepare a worldMatrix with the transform of the camera, then append the projectionMatrix. The PerspectiveProjection class always seems to assume screen coordinate (0,0) is the center of the projection so you will have to manually offset. Maybe I was not using the projection right, since the docs imply otherwise.

There were two other details to sort out. First, I had to reject objects behind the camera, and second, I had to scale objects correctly so they appeared to have perspective. The solution revolved around the same information – the pre-projection Z. By hiding all objects with Z < 0 and scaling by focalLength / preZ, I was able to get it to behave properly.

Next up is Matrix3D.transformVector… which is slow. Transforming 1000 vectors eats 3ms in release build! This is really slow in absolute terms (Ralph Hauwert has a good example of the same functionality running much much faster). I didn’t really want to introduce Alchemy for this project. But we can use AS3 code that avoids the allocations, saving us GC overhead and getting us an incremental improvement in performance.

Andre Michelle has some interesting thoughts on the problem of temporary objects related to transformations (see http://blog.andre-michelle.com/2008/too-late-very-simple-but-striking-feature-request-for-flash10-3d/). I did notice that Utils3D.projectVectors had some options for avoiding allocations, but it did not seem to run significantly faster (even in release build). (sample code for using projectVectors)

In the end, I settled on my own implementation of transformVectors, as it seemed to give the best balance between performance and ease of us. There’s a final version of the sample app where you can toggle between transformVector and the AS3 version by commenting out line 105/106 up on github, so you can test it for yourself. The transform function took some effort to get right, so here it is to save you the pain of implementing it yourself. It transform i by m and stores it in o.

        final public function transformVec(m:Matrix3D, i:Vector3D, o:Vector3D):void
        {
            const x:Number = i.x, y:Number = i.y, z:Number = i.z;
            const d:Vector. = m.rawData;

            o.x = x * d[0] + y * d[4] + z * d[8] + d[12];
            o.y = x * d[1] + y * d[5] + z * d[9] + d[13];
            o.z = x * d[2] + y * d[6] + z * d[10] + d[14];
            o.w = x * d[3] + y * d[7] + z * d[11] + d[15];
        }

Time for some conclusions. I think that the 3D capabilities built into DisplayObject are OK, but very focused on light-weight graphic design use. Building a significant 3D application requires you write your own rendering code built on Flash’s 2D capabilities (either DisplayObjects or drawTriangles and friends). The 3d math classes are ok, but immature. Some things are very handy (like the prepend/append versions of all the methods on Matrix3D), but the tendency for Flash APIs to implicitly allocate temporary objects limits the usefulness of some the most central API calls. In addition, important assumptions like the order of the values in Matrix3D.rawData were not documented, leading to frustrating trial and error. I am excited to see Flash’s 3d capabilities mature.

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.

It is pretty cool stuff, and I’m excited to be sharing it! You get introduced to the PushButton Engine, get a preview copy of Clint Herron’s excellent Platformer Starter Kit, and (assuming things go smoothly), you end up building this platformer:

We’re excited about it.

If you are a Flash game dev and at MAX or in the LA area, I’d love to talk games with you. Shoot me an e-mail (ben dot garney at gmail dot com) or DM me at @bengarney and let’s make it happen!

Also, with luck, Monday there should be a cool update on that secret project I was working on.

See you at MAX!

We’ve been trying different approaches for the documentation for PushButton Engine. We have reference docs, API docs, and tutorials. There are comments at the class, function, and body levels. There are example applications of varying size and complexity. There’s still a lot more to document, but what is covered seems to be making sense to people.

Lately, I’ve been doing short – 5 or 10 minute – Keynote presentations, recording them, exporting them with the iPod video export option, and putting them up on YouTube. They’re a nice workout for presentation skills; I spend an hour or so building a slide deck, then run through it a few times before recording and uploading. They also seem to be a good way to explain high-level concepts about PBE.

I’ve done them on Resources in PBE, on the PBE profiler, on why components are a smart idea, and how your UI and PBE related. Nearly 500 views across the four of them in the last month, which I think is pretty good for what is dry technical content at best.

Speaking of presentations, I will be talking about Developing in the Cloud at Austin GDC this Friday, 4pm. Talking to game developers, I have noticed there is not a lot of awareness of how cloud computing can help cut budgets, shorten development time, and increase features. We’ve been using cloud resources heavily at PushButton Labs, so the talk will cover the risks, rewards, and tradeoffs related to things like EC2, S3, Google’s services, SVN hosting and so forth in terms of letting you focus on your game. I’ll also talk about how you can directly integrate things like Google Spreadsheet and Analytics directly into your game, and why it is a good idea to do so.

I’ll be at Austin GDC Wed-Fri. If you want to meet up and talk cloud computing, Flash game dev, or PBE, shoot me an e-mail, tweet, or comment and let’s make it happen!

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.