Sep 112010

I’ve gotten a bit of feedback on my performance posts from a few different sources. Enough to make a new article on the subject! See part 1 here, or jump to part two here.

The Source Code

So people can take a look at how I’m doing things, or what exactly the base code is up to, I’ve packaged up the source code for SolarCraft.  Remember: this was a two-hour hacked-together-from-scratch bunch of code. Don’t judge me too harshly! I think it’s a decent testbed for performance because it has a basic game-style logic loop and a few iterations through large arrays… But most of all, isn’t designed to be “perfect” or “most efficient”; this is to test real-world game-performance, not theoretical performance maximums.

Download the source here.

Rotating bitmaps by 90 degrees

User areagle of the FlashGameLicense forums asks if rotating bitmaps by exactly 90 degrees provides any sort of performance boost, since the math for doing so is much easier and less intensive on the CPU. Decent enough question! Let’s get some baselines first.

1000 collectors on-screen, .cacheAsBitmap true: 48.0 FPS

Adding +.01 rotation per tick: 14.0 FPS

Changing to +90 rotation per tick: 13.2 FPS

Changing to +180 rotation per tick: 14.5 FPS

Changing to +360 rotation per tick: 48.3 FPS

Well, it looks like the rendering engine is smart enough to know that a 360 degree rotation won’t affect speeds, which is nice; now I know that simply setting the .rotation property isn’t enough to cause a performance drop. 180 degree rotations were a smidgen faster than smaller increments, but that may  have been luck; I’m willing to call this one potentially true, but for game development’s sake, doesn’t matter.

Different loop styles

This one was brought up a few times in different places (twitter, forums, blog comments) and I can’t help but think people are missing the point. People are saying I’ll see a significant performance difference between the different loop styles.

Now, I will believe that a while loop might be a bit faster than a for loop. But compared to game logic and rendering times, I’m betting this speed difference is going to be less than a single percentage point. I’ll bet I can’t pickup the difference from the background noise. I believe loop speed differences are only useful to people crunching through massive amounts of data (like, one-million-entity-arrays or something).

Since I have my code open anyway, why not appease the masses?

There are two main game loops, both updated in the Update() function in (line 68); the first loops through a vector of 1000 collectors, removing any dead entries (there are no ways to die in this version, so no action is taken); the second loops through each collector and runs their respective .update() functions.

Baseline: Using two FOR (var i…) loops, 46.7FPS.

Converting both to be FOR EACH (var entity…) loops, 47 FPS.

Converting both to WHILE loops: 47 FPS.

Without getting too in-depth here I’m thinking my hunch was right: Loops might make a big difference in big data sets, but in games it simply doesn’t matter.

Debug vs. Standalone vs. Browser

Different Flash players get different performance values. I noticed this while performing other tests for this series of articles, and I know there is definite value here.

Using the standalone Flash 10 Debug Viewer – which I do my sole development in – I get 27 FPS with 2000 collector’s on screen. I kind of assume this is the performance that people will get when they play the game on the web; let’s test:

Using the Chrome & Firefox Flash Plugin Viewer, I get nearly 50 FPS in the same environment!

Using the Internet Explorer ActiveX Debug Viewer, I get 19 FPS in the same environment!

Out of curiosity, I downloaded the standalone Flash projector (non-debug) and maxed out at 60 FPS.

So there we have it. All debug viewers are nearly half the speed of their counterparts, and the web plugin is definitely slower than the standalone version of the player. Keep this in mind! If you do all of your development and testing in a browser-based debug viewer, you are essentially simulating a slower computer.

Multi-app same-page performance differences

Back in my last performance post I toyed with how the target FPS might affect performance (it didn’t). A few people said that this actually is a real issue even for us game devs, but the problem only crops up when an .SWF is hosted on an HTML page that has a bunch of other flash things playing — such as the portals we deploy our flash games on.

One side of the argument says that aiming for a higher framerate than what you can achieve, can actually tax the SWF player and produce a lower FPS than intended. Another side of the argument says the SWFs “compete” for slices of the timing pie when several instances are launched, and the more resources you demand – the more resources you get.

Seems like a perfectly reasonable assumption, and is indeed well worth testing out. Let’s give it a go.

For this test I’m going to use a baseline build of 4000 collectors running at a target of 30 FPS (using the non-debug browser player). I’m getting 21 FPS on (uploading my game but not ‘publishing’ it).

No matter what I set the target FPS to, the value is not wavering, despite there being flash ads and Kongregate’s achievement/chat interface on my screen.

Just out of curiosity, I opened two tabs (one set at 30 FPS and the other at 60 FPS, both hosted on Kongregate) and played each flash game tiled on my screen. Performance still did not waver from a solid 21 FPS for either copy.

Looks like I can’t replicate any web-based test conditions! I’ve now tested this “Target FPS” thing a dozen of ways and can’t seem to make it affect performance at all. I’m thinking that in the majority of cases for actual game development, this will not be a concern: set your FPS to whatever you feel is best and the game will perform as best it can. Why limit things? Set your FPS to 120 for all you care! (Note: Flash Player 10 does indeed limit max frame rate to your screen’s maximum possible refresh rate, so it’s not possible to ‘waste cycles’ doing this)

Off Screen Rendering

A curious thing I noticed in my performance graphs when playing things in tabs: flash skipped rendering cycles if the viewable area of the game was physically not visible on my screen. If my game ran minimized, was in another tab, or was scrolled off the edge of my monitor, my performance maxed out pretty quickly. It looks like Flash only bothers rending when it’s open or active (for the browser plugin, anyway)!

Good to know: Don’t do performance tests if the window isn’t open, front and center!


Throughout all of my testing, I’ve really only concluded one thing: The only place you can possibly optimize your game is in appropriate use of bitmap graphics. Any other “tweaks” you can make either have such little effect as to not be relevant to game developers, or have no effect at all.

  2 Responses to “Performance Testing: Round 3”

Comments (1) Pingbacks (1)
  1. The off screen rendering thing is new to Flash 10.1. It’s one of the optimizations they did… Can’t wait for Flash 11! It’s supposed to come with a 3D API, maybe some hardware acceleration for graphics… (praying…).

Sorry, the comment form is closed at this time.