I'm sure someone else has done this already, but I just wanted to demonstrate something that many Flash programers might not know about.
When developing games, performance is usually one of the most important elements. This is especially true in action games, as user interaction needs to have almost a "real time" feel. In action games, there is typically a frame loop somewhere that does the processing. This handles things like getting user input, updating the users position, moving enemies, scrolling the background, etc. You want these frame loops to execute as fast as possible, for obvious reasons.
There are 4 basic ways that I know of to create a frame loop. There may be more, but they are probably more complex and slower than what I'm going to show you...
I've created a simple movie, 100x100, with just a circle on the stage named "circle_mc." I'm moving the circle to the right 1 pixel every frame until it reaches the right border, then resetting it to be on the left. This repeats until the movie is closed. The document is set at 20 frames per second.
In the movie, I've also set up a basic frames per second counter, to compare performance of the 4 different frame loops I'm going to illustrate. Every frame a variable is incremented, and then the frames per second is displayed via the trace function. For the most part, the code looks like this:
circle_mc._x = (circle_mc._x + 1) % 100;
frames++;
// we use add instead of + because it performs a little better
trace("fps = " add frames / getTimer() * 1000);
In no particular order, here are the results:
1) Placing code on the circle_mc movie:
onClipEvent (enterFrame) {
_x = (_x + 1) % 100;
frames++;
// we use add instead of + because it performs a little better
trace("fps = " add frames / getTimer() * 1000);
}
This seems to stabalize at around 19.15 frames per second.
Changing one line looks like this....
onClipEvent (enterFrame) {
setProperty(this, _x, (getProperty(this,_x)+1)%100);
frames++;
// we use add instead of + because it performs a little better
trace("fps = " add frames / getTimer() * 1000);
}
.... and this method seems to stabalize at around 19.22 frames per second.
2) Placing the code on the main timeline:
circle_mc.onEnterFrame = function() {
_x = (_x + 1) % 100;
frames++;
// we use add instead of + because it performs a little better
trace("fps = " add frames / getTimer() * 1000);
}
The above yields around 19.20 fps.
Doing the same test and changing the one line to be the "Flash 4" way yeilds roughly 19.17 fps.3) Placing the code on frame one, and a "gotoAndPlay(1)" on frame 2. The code is roughly the same:
circle_mc._x = (circle_mc._x + 1) % 100;
frames++;
trace("fps = " add frames / getTimer() * 1000);
This gives around 19.26 fps. Changing to the "Flash 4" (set/get for circle location) yields around 19.60 fps.
4) This last method is total old skool Flash 4. Extend the movie to be 10 frames, and on the first frame keep the code the same, but on frames 2-10 put a "call(1)".
The first way (accessing the properties directly) yields around 19.20 fps. Changing to the "Flash 4" way yields roughly 19.81 fps.
Take all of this with a grain of salt. These tests are by no means scientific, and I'm sure results will vary from computer to computer. From the above, it just reinforces the already known fact that game development is faster with Flash 4 style code. Of course, readability is generally sacrificed which isn't always a good thing - but you have to weigh what's most important for you as a developer.
I can't wait to try this again when the newest Flash Player comes out. The stats floating around about it look very promising. I'm hoping the "MX" way of doing things (circle_mc.onEnterFrame) will perform just as well as the Flash 4 methods... Can we have our cake and eat it too?
myVar = Math.floor(frames/getTimer() * 1000)
//this will get rid of that long decimal