Posts

Showing posts from November, 2010

BunnyLandMark - a new Flash game benchmark



I learned a lot about Flash rendering with my BunnyMark benchmark, but I felt it was missing a few vital features that would make it a true test of game-specific performance. So I've come up with a brand new test: BunnyLandMark! Once again I created a version using display list Bitmaps, and a version using copyPixels blitting. Here are the new features:
  • a large scrolling world - about 4000x4000 pixels. I chose this size as it is roughly the biggest bitmap you can make in Flash player 10. With a bit more work it is possible to make infinitely large worlds, but this size was big enough for my purposes.
  • Perspective depth-sorting. Bunnies that are further into the scene are sorted to appear behind those that are closer to the viewer.
  • More bunnies - as off-screen bunnies don't need to be drawn, the total number of bunnies can be increased.
And here are the results (INSTRUCTIONS: use ARROW KEYS or WASD to scroll!)
  • The blitting demo can handle 90,000 total bunnies at 30fps, with about 1,900 on-screen bunnies at a time. Blitting was ridiculously fast! That's definitely more bunnies than you require! Depth sorting using blitting is definitely more efficient. Don't forget to scroll with the arrow keys.
  • The display list demo can handle 22,000 total bunnies at 30fps, with about 450 on-screen bunnies at a time. So, in this case blitting is about 4 times faster than the display list, versus only about twice as fast on the previous test.
So here's my conclusion: depth sorting on the display list is pretty slow. In fact, before I came up with some optimisations, it was much, much slower and I couldn't even handle 2,000 total bunnies at 30fps. In my first iteration I used setChildIndex to order the display objects, ignoring those that are offscreen. But when you think about thousands of bunnies slopping about in the display list, you can guess that this was incredibly slow. I don't know how the display list works behind the scenes, but it doesn't like you changing depths. The trick I came up with was to loop through and removeChild every bunny, and addChild back only the ones I need on screen. This meant my displayList was much shorter and so all my display list operations were much faster. I still think 450 on-screen, depth-sorted entities at a time is going to be plenty for most games, but I can definitely imagine a few scenarios where it wouldn't be enough.

Ok, over to you now readers! Please test and report any differences in frame rate you get. I'm particularly interested to see if Mac Safari performs as woefully on this display demo as it did on the last. I have updated the source zip to contain all the bunny demos.

Windows Phone 7 for Flash Developers, Part 1


As I write this I am in possession of a Windows Phone 7 developer handset, the problem is I don't know quite what to do with it yet. I think WP7 seems like a well thought-out platform, hence my interest in developing for it, but as a completely new technology, it's hard to know exactly what the best strategy for app and game development is. Here are some random facts and thoughts about the platform. (Since I first posted this, Mike Ormond from Microsoft has emailed me with some more definitive answers, so I have updated the post to reflect this).
  • Let's get the bad news out of the way first: there is currently no support for 3rd party tools like Adobe AIR and Unity3D. Although Mike says "there will almost certainly be support for 3rd party tools" in the future, he couldn't give any specifics about what those might be, and as always with these things, it's impossible to know whose court the ball is in.
  • The phone's browser works well, but doesn't support either Flash or HTML5 content at present. This may well change, but nothing is confirmed or has been officially announced by Microsoft for either HTML5 or Flash. The lack of HTML5 support really surprised me, considering how enthusiastically Microsoft are supporting it with IE9.
  • Ok, now on to the good stuff. You can develop apps with Silverlight and games with XNA. You can only develop on Windows 7 or Vista (SP2), and in fact for the XNA emulator to work you need Windows 7 and a recently produced graphics card, so I can only test games on my device, not on the emulator. Installing the free developer tools takes about 2 hours - you get special versions of Visual Studio 2010 and Blend 4. Visual Studio is good, although 2010 uses WPF and doesn't feel as punchy as 2008 did on my machine. The auto-completion is great, although it doesn't have all the handy keyboard shortcuts I'm used to in Flashdevelop. Blend is a design tool similar to Flash Catalyst, but I haven't really played with it yet.
  • To release apps to the app store, you need to pay an annual fee of about £70/$100. This fee also allows you to release games on Xbox 360 indie games. Xbox shares 95% of the same XNA apis with WP7, so it would be relatively easy to make a game on one platform and port to the other - you would just need to account for input and screen size. I have paid my fee, so I will definitely release something for one of the two platforms this year. I've always wanted to do a console game, so I will probably try to do something that I can release on both.
  • Silverlight is a high-level, vector based scene-graph with standard components like buttons, menus etc, a bit like Flash + Flex. Silverlight could theoretically be used to make games as well as apps, although I don't know what the graphical performance would be like. If you make a game with Silverlight, you can still make it show up in the games section of the marketplace rather than with apps. The phone UI has nice, consistent styling and fonts, and by default your Silverlight apps match this styling automatically.
  • XNA is a fairly low-level game/graphics library which exposes hardware accelerated 3D rendering and 2D blitting. I've not benchmarked it yet, but it's really fast. XNA has no scene-graph or concept of a sprite, so if you are used to working this way in Flash, some things are going to take you a lot longer. See this post for what I think are the benefits of a scene-graph, but the main difference for me is not being able to create hierarchies of objects, for example a player object containing arm and leg objects that can be manipulated relative to the position of the player. I'm going to investigate some way of recreating this functionality myself.
  • The resolution is really high (800x480) on a pretty small screen, so if I want to use any of my pixel art characters from other games I will probably have to look at double-scaling everything. Otherwise, a 32x32 pixel character is only about 2mm on the screen. Mike tells me that a lower resolution device may be available in the future, but I'm not sure how existing apps would be scaled scaled down to fit a lower resolution, and I could potentially see that causing problems.
  • There are paid apps and free apps, just like iOS, although apparently you can only submit 5 free apps per year before you have to pay an additional fee - presumably this is to stop shovelware, so may not be a bad thing.
  • Like Apple with iAds, Microsoft are running there own advertising network. Currently this feature is only available in the US, although is set to come to other countries in early 2011. However, it ONLY supports Silverlight apps, not XNA, so isn't much use to me anyway. Mike confirms that it is unlikely XNA ads will ever be supported, although he points out that other networks are allowed, so if Admob want to add XNA/WP7 support, they can. Will they? Who knows.
  • Games have a 2-tier system where the big studios are able to have Xbox Live branding and support, such as achievements, and indie game are not. I understand why they have done this, but as an indie it does put you at a disadvantage to the big boys.
  • Paid apps support a trial mode, which I think is a really good thing for both users and developers. Users can try an app out before they buy it without the need for the developer to create a separate "lite" version. You just specify which features should work in trial mode or how long the trial should last. This does create a bit of a dilemma for a game developer though. Many Flash and iPhone games (e.g. Cannabalt) have a play time of just a few minutes. If you are able to get this full game experience from the trial mode, there is no incentive to buy the game. And with no ad network support at the moment, I don't see any way to monetize a short-form game. The way to make a profit would seem to be to make a long form game with a very engaging/adictive first few minutes as a trial mode.
  • In terms of fee-for-service work, the Silverlight side is likely to be dominated by existing .NET/Silverlight developers, of which there are many. I think it is unlikely that day-rates for Windows Phone 7 development will reach the enviably lucrative heights of iOS. As the market leader, iOS apps are in very high demand from paying clients. At the same time, the superficial strangeness of Objective-C and requirement to use a Mac reduces the developer base and greatly limits supply. This creates a perfect storm of high developer costs that I doubt we'll see in the more abundant world of .NET developers, on a new platform with many fewer potential customers. Gamedev, of course, is really a quite a different set of skills, which many Flash developers have in abundance, so if a market did emerge for branded games, this could be a good area for Flash developers to look into.
Taking all this into account, I think the opportunity for Flash developers who want to branch out into the WP7 space will be to bring their creative and gamedev skills to the paid games market, but it would have to be with long-form/multi-level games like Angry Birds, Trainyard, Warlords etc. And coming up with killer game ideas like those, while implementing on a brand new system, isn't going to be easy. Windows Phone 7 seems like a decent phone platform with good developer support. Like with any platform though, the killer idea needs to come from you, and for now, I'm still trying to think of mine.

In part 2 of the series I will be testing rendering performance by porting BunnyMark to Silverlight and XNA!

Display list vs. blitting - the results!



To get some actual evidence for my opinions on the joys of the Flash display list, I created two demos that I'm calling "BunnyMark", a test of rendering small bouncing bunny pngs with alpha transparency. Since first posting, lots of readers helped by testing on different browsers and operating systems, and I have updated this post with their results.

The results were quite interesting, and not quite what I expected. Blitting was really fast, although actually a little bit slower than I expected, but gave a consistent rendering speed across all platforms. Bitmaps were also pretty fast, although in Safari on Mac performed really badly. I emailed Tinic from the Flash player team about this issue, and he has said he will look into it. Ok so here are the results:
  • The display list demo could render 4000 bunnies at 30 fps on my PC without slowing down. This was replicated by readers on all Mac and Windows browsers except for Mac Safari, where it was down to 10-20 fps. Based on this interesting blog post from Tinic Uro (suggested by Richard Leggett), this seems like it may be something to do with the recent adoption of the Core Animation APIs in Safari. The demos has a lot more layers stacked up than you would need for most games, so this performance drop is unlikely to affect a real game - although I will be following up with a new benchmark to test that hypothesis. Bitmaps faired very badly on Android - it couldn't even render 10 bunnies at 30fps.
  • The blitting demo could render 6000 bunnies at 30 fps without slowing down on my PC, and people with faster machines have reported up to 11000 bunnies at 30 fps. Blitting was also much more effective on Android, where it got up to 600 bunnies at 30 fps, certainly enough performance for an arcade-style game. (Thanks to Philippe Elsass for the Android tests).
So in this example, blitting is about twice as fast. But as I hope you can see, realistically 3000 bunnies is still a lot more than you are going to need in most situations. You can download the source code and see if you can improve the performance of either demo. A couple of readers have recommended performance optimisations, for example suggesting I use a fixed-length vector and using lock() and unlock() on my bitmapData, but neither strategy noticeably improved performance on my machine.

I also wondered whether switching the wmode in the HTML can fix the Safari issues - it doesn't. If you want to try them: Opaque, Transparent, Direct, GPU (both Direct and GPU give 5 fps in Chrome on Windows!). This post from way back in 2008 may possibly shed some light on this topic:
"Just because the Flash Player is using the video card for rendering does not mean it will be faster. In the majority of cases your content will become slower." - Tinic Uro
Just a final note - I ran a similar test to this 2 years ago in Microsoft XNA and was able to get something like 50,000 bunnies going at HD resolution, and 60 fps. I think molehill is going to make this discussion somewhat irrelevant next year - GPU blitting will annihilate both of these approaches. The question will then be, can the display list also be speeded up by the GPU, or is it just too wacky and different to what graphics cards are designed to handle?

In defense of MovieClips, Sprites and the display list (...the case against blitting?)



“This is why I always run a raster pipeline. The DisplayObject API is a trick played on the gullible and the trusting…” — @bengarney
Ben Garney is a very smart game/engine developer with a background in C++ and known for developing the Torque engine, who has now moved into the Flash world with Pushbutton Engine and games like Social City. I come from the complete opposite direction. I’m a Flash guy with a background in quick turn-around, design driven creative Flash projects, who now focuses on game development. This difference in backgrounds, and dare I say *ideologies* is why I thought I should write a response to Ben’s recent post about blitting, and stick up for the display list a bit. If you haven’t read Ben’s article, I suggest you go do that, but for the sake of clarification, blitting is basically using copyPixels to manually draw your graphics to a single bitmap data object that you display via a single Bitmap object on the stage.

Firstly, there is a lot of truth in what Ben says. Here are the advantages I see for blitting:
  1. Renders faster if you have thousands of sprites.
  2. Although Ben didn't mention this, if you use the Flixel, Flashpunk or Pushbutton engines you get some other game engine functionality for free, although most of the benefits of e.g. Flixel are nothing to do with the fact that it uses blitting.
  3. Erm...
Now here are the advantages for using MovieClips, Sprites and Bitmaps in the native Flash display list:
  1. You get rotation, scaling, alpha, filters and colour effects for free. Want to add a glow or blur to something? It’s one line of code, and adds no filesize to your app. If you use blitting you have to somehow prerender all these effects, either as pngs that will increase the filesize of your game, or prerender at runtime, which will add a lot of complexity to your code and add to your development time, and in the cutthroat world of Flash games, time is money. If you combine the display list’s built in effects with an engine like TweenMax, you can make amazing animated effects in just a few lines of code.
  2. You can work easily with interactive designers. Most creative agencies have designers who are experts at using the Flash IDE to create beautiful layouts and animations that you can easily breathe life into with ActionScript. If you are working from flat PSDs for all your assets, you will spend a lot of time laying screens out in code, which is something you never really want to do. The reason Flixel etc are never used on advergames, e-learning games or other client projects is that there is no workflow for designers to add their branding magic.
  3. You get mouse events. You can easily create buttons and more complex interactive elements with complex hit areas. Now in a game it is very possible to use blitting on your gameplay area but still use the display list for all menus/gui, and I would definitely recommend this option over blitting *everything* like Flixel does. However, sometimes you want to have interactive menus and buttons inside the gameplay area, in which case it will be much easier for you to use the display list in your game rather than recreate all that functionality from scratch inside your blitted area.
  4. You can nest things inside other things. This is very useful for things like menus, but is also very a great way to create dynamic animations that can be altered at runtime. For example, if you have an animated character holding a weapon, if the weapon is a sprite inside the character sprite, you can easily swap out the contents of the weapon sprite to change weapons. If you are using blitting, this feature will be time consuming to recreate.
  5. It’s not as slow as people think. If you are just moving Bitmap objects around in the display list you will easily be able to have hundreds of sprites on screen, in a typical game. And as only displayObjects within the viewable stage area are drawn, you can actually have a game play area with thousands of sprites, so long as you can only view hundreds at a time. Turning off mouse interaction for the display objects (mouseChildren = false, mouseEnabled = false) makes everything run significantly faster too. I have a demo with 40,000 tiles scrolling on the display list smoothly at 120fps – as Flash only renders those tiles inside the viewable area of the stage. You can also use a hybrid blitting / display list approach by having a Bitmap objects on the display list which you animate by changing the value of the bitmap.bitmapData property. This is very fast and you still get all the advantages of the display list effects. The best of both worlds!
So ultimately it becomes a question of how much rendering speed ya needs versus how much development time ya gots (read that last sentence in the style of the Clint Eastwood). From what Ben says about Social City, it looks like a poster child for blitting – it’s a scene with thousands of sprites drawn at once (although Ben’s claim that his display list tests were running at less than 1 frame per second suggests to me that he had not correctly optimised by turning off mouse interaction). Either way, display list *will* always render slower for a thousand sprites. But pretty much every Flixel game I have seen would have run perfectly using the display list. Ben says that the display list is the darkside of the force. In equally mischievous tone, I propose that blitting is for people who don’t actually like Flash, and they see everything that makes it unique and interesting, like the excellent Flash IDE and the vector display list renderer, as a negative. I will get some benchmark demos of both approaches up soon. Of course display list will lose, but it won't be as bad as people think. Comments appreciated!