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!
“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).