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 Map.as (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 Kongregate.com (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!

Conclusions

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.

Following up on my previous article, I wanted to test a few more things. For the sake of generating clear numbers, I’m using yesterday’s 2-hour game SolarCraft as my testbed.

Throughout these tests I’m spawning 2000 collectors with cacheAsBitmap enabled, and running the test for 30 seconds and providing the average FPS (which will therefore include, but hopefully minimize, startup lag throwing the numbers off a bit). As I mentioned in my previous article, I’m trying to get real-world numbers (using believable in-game item counts) with other things going on (such as graphics and game logic loops).

Vector vs. Array

Vectors are new in Flash 10 and are, put simply, a typed array. Many claims have been made on the huge speed increases when using Vectors (I’ve heard 250%+); let’s test it out!

A 2000-length vector iterating twice per frame generates me an average of 26.5FPS.

Converting the code to untyped Arrays provides me an average of 26.0FPS.

That difference can easily be chalked up to various other things and is pretty much indistinguishable. It looks like, for the purposes of this game, Vector iteration isn’t much faster at all.

However, I still love vectors for being typed. Still worth using, no harm in it and your code will be easier to work with!

Loop Iterations

“Hey wait,” I hear you saying. “Why do you loop through the 2000-length vector twice per frame?

Good question! It was because I made sloppy code and thought it would be a good idea to simply loop through everything again rather than fix it (that’s how you make 2 hour games!).

For clarity, one loop is simply cycling through all game objects (in this case, 2000 collectors) and running their “update” function. This function calculates where the collector wants to go, runs a few randomization jitters, and does some simple coordinate translations to produce a vector. Then they “walk.” Nothing exciting, no big maths.

The other loop is just checking for dead collectors and culling them from the Vector (not that anything is dying in these tests).

As a baseline, we are currently getting 26.5 FPS.

So I’m curious.. let’s comment out the useless dead-check loops and see what kind of performance boost we get. Looks like 27.2 FPS. A slight increase, maybe even one worth sticking with; a single frame per second optimization in a few places might add up.

Let’s remove the walk-logic loop and see how that fares. Looks like 29 FPS. This one was to be expected; removing all the art movement and gamelogic from the game should very well speed things up. To be fair, the “current FPS” was locked at 30 for a long time, and we only got 29 FPS because of my 30-second-average including bootup delays.

Well, let’s play with this dead-check loop again. What happens if I make it run 10 times, thus iterating the game through 22,000 vector entries per frame? We get a result of 22 FPS. That’s a significant hit for a loop that doesn’t even do anything.

I think it’s safe to conclude that iteration through long lists – regardless of content or actions – is a big performance hit. But putting in a useless duplicate iteration 10x over? Not exactly a “big problem” in game design, I think. You’re better off ignoring this issue and optimizing what happens in the loop itself.

Playing with Target FPS

If you tell Flash to run 30 frames per second, it might run at 25 FPS thanks to your inefficient code. I’ve heard, however, that if you tell Flash to run 60 times per second with the same code – that 25 FPS might drop to 10FPS. Trying to over-achieve can actually hurt you!

I’m really interested to see if this holds true in my game.

I’m currently running at about 27FPS, on average, with a target framerate of 30.

Changing the target framerate to 60…  Has little effect! I’m averaging only 1 less: 26FPS.

Let’s crank the target framerate up to 120… Hmm. My monitor refresh is 60hz, I wonder if Flash can sense that and scale down my request? I’m showing a target of 60 still, and still hitting 26FPS. Oh well.

Just for kicks let’s drop the framerate down to 10 an see what happens: Wew, a solid 10 FPS. At least I know there wasn’t some weird overhead preventing me from hitting 30FPS before; it looks like my code really is a bit too slow (or I have too many dudes on the screen).