Optimization Tips

[Kirill M.]

Also if you have several repeating boolean expressions in the if statemetns or loops with very long conditions, you could evaluate them prior to either of those two, assigning them to variables and then evaluating the bigger expretions using the variables.

Edit: Also by playing around with Boolean Algebra you can reduce then number of operators you have to use, thus reducing the size of the expression.

The faster the movie plays the more bogged down the CPU gets, so there's a certain point up to which increasing the frame rate will make the movie smoother. Then it won't get any faster even if you continue increasing the FPS. In cases where you have several movie clips performing a lot of actions at one time it is better to decrease the frame rate instead of increasing it, because that will make the CPU do less work.

Also I've found that using the call action is faster than using functions, but of course you can do a lot more with functions than with call.

Edit: Using nested loops can slow down the movie. Most of the time you can get away with using only one loop.

When using arrays, it's better to specify the initial size and make it sufficient for your needs. Because when you append new elements to it and the size goes over the limit that it has set internally by itself anyway, it will have to copy every element from that array into a new and bigger one, that will accomodate the new element. So the less copying the better. Also using the shift method is a bad idea. When you need things like a queue or a stack it's probably better not to even use an array, but use a linked list instead, since appending and removing would be pretty trivial in that case and there wouldn't be any shifting of element going on.

[AJ Infinity]

Originally posted by PrED32
Keeping all your code in one place is not only good coding, but it can be faster, because code lookups dont have to go through MC's, plus you usually recycle more code that way.

Remember though, Flash supports only 64k of code per frame. Use #include's.

Try not to use vector graphics. This is like always CPU intensive. Use bitmaps (PNGs-the best are PNGs-, BMPs, PICTs or JPGs) instead.

If you want your game to be PC only and you use a PC in your Flash gamedev work, use SWFxxl to speed up framerates and run your Flash game in a fullscreen DirectX accelerated projector (www.swfxxl.com).

[adityadennis]

AJ : Are you aure about the vector thing? I thought bitmaps were SLOWER...

[io::pred]

Well, a filled square may be faster in vector than a green square in a bitmap.. but lots of lines/curves and gradients become ALOT faster in bitmap

[AJ Infinity]

Bitmaps increase SWF size, but they are faster for Flash to draw.

[Squize]

I think the rule of thumb is number of curves in a vector >= 10% of total number of pixels in the bitmap = slower.

Squize.

PS. I'll edit this tomorrow when I'm sober...

[adityadennis]

Wow, I have to try making a game using bitmaps now...

[AJ Infinity]

In a test I just performed, a bitmap performed faster than a vector graphic. Here's what I do.

1. I draw out my graphic
2. Resize the stage to fit the graphics coords
3. Export it as a PNG (24-bit, with alpha channel)
4. Import it back in
5. Make a movie clip and do each frame for it, exporting the graphic for each frame in the manner described above


The book Flash Game Design Demystified says bitmaps are better than vectors.

[Squize]

Also when you use bitmaps you can drop the quality setting to low without any noticeable effect.

Squize.

[adityadennis]

Most of my games used to run at 22fps max earlier, but : 30fps land, here I come! (Yes, It sounds gay, but I'm excited)

[leif0]

Hi there!
Thanks for the tips! Just about to optimize my actual project.
So here come some hints back:

- Scrolling a big amount of clips is faster, if you attach an onEnterFrame-Event to each of them doing the same transposition instead of moving them as a grouped clip.

- If you have a big amount of clips on stage and want to switch them on/off fastly you should use _visible true/false instad of attaching/removing clips. Overall it counts better, even if you just display about a half of the clips at a time. In my case i had a number of approx. 70 non-moving clips on stage.

- And an interesting rumour i heard: Leave some frames unscripted in CPU-intensive applications: Flash clears memory only if CPU-power is available. Otherwise you may run into lack of memory.

MX Player and PlugIn (in IE) seem to work different and thus achieve different performance. Is anyone experienced in optimizing for the IE PlugIn?

[Squize]

"- Scrolling a big amount of clips is faster, if you attach an onEnterFrame-Event to each of them doing the same transposition instead of moving them as a grouped clip."

Erm, I can't really see that to be honest. For instance in a scrolling engine it would be quicker for each tile to have an enterFrame and therefore movement code than to put them in a container mc ?

I hardly ever use removeMovieClip ( Mentioned in an earlier post ).

As for optimizing for IE, all the tips mentioned so far will speed up a swf, I don't think there is anything much you can do to improve the IE performance loss ( Aside from not embedding the swf, just put it in a pop-up window and don't allow re-scaling ).

Squize.

[Kirill M.]

Actually making your movie clips invisible doesn't speed up your game even if they don't do anything. When I began making my engine I used to make tiles visible and invisible when scrolling and it was incredibly slow. Now I just move one column or row of tiles over to the new spot and keep only 9 tiles at all times on the screen.

[leif0]

Yes. If your clips go off-screen or to another state in which they will not appear again, it is definitely better too remove them - and invisibilty does not gain performance. In my example i built a pinball game and the table held about 70 lights. These were there to be enligtened, blink, flicker or whatever. They did not change positions and went over to be displayed and flushed over and over again. I just compared removeMovieClip() to _visible = false and in this situation last one went faster.

[Squize]

In regards scrolling the visible method is slower than the gotoAndStop method ( There's a largish thread somewhere about this which I think pred started from memory ).

Where I use the visible as opposed to remove method is in regard baddies. I just see it as a false economy to have to attach baddie sprites every time you need one, it's better IMHO to just keep them inactive with the visible flag cleared. attach and remove aren't the quickest calls in the world and normally when you're setting up a new baddie you've just run a load of extra code anyway.

Squize.

[adityadennis]

Scrolling a big amount of clips is faster, if you attach an onEnterFrame-Event to each of them doing the same transposition instead of moving them as a grouped clip.

I made a platformer and the FPS changed from 24 to 30 after I grouped them together, so I dont think that's true. Here's something though: the FPS DOES go up if enough movieclips are off-screen and they dont have a lot of on(enterframe) code.

[leif0]

Against most logics i expected the opposite. This is why i posted it here...? In my case a vertically scrolling background of tiles running under a mask.

[io::pred]

squize: its a bit of a catch 22.

have all the enemies there, running through their enterFrames (checking to see if they are visible or not), being invisible when they are out of the screen.

or

attaching them when you need them.


Personally I dont think their is a right or wrong.. the last platformer I finished (finished being the word hehe) I attached them when needed, and I did see a performance boost.. I think flash still draws a larger area if there are invisible clips.. who knows.. maybe we can get an answer from macromedia...

[Squize]

I'm kinda set in my ways, it harks back to writing on the C64 and Amiga where you had a set number of sprites.

I still set up say 8 "sprites" which I just re-use ( I store the baddie graphix like you would a tile set so I just gotoAndPlay the correct frame for the baddie type ) and use a handler mc to do all the movement / active / shooting / dying etc.
That way the handler just shoves vars straight into the sprite mcs when they are needed.

You are right though, it's much of muchness.

Squize.

Link to the platformer ?

[io::pred]

www.squarecircleco.com/sped/sped.html

I wont lie when I say the engine is slow, its back in the day when _visible and gotoAndStop werent even thought of, its all attach/remove, even the enemies.

But it is alot faster than having every enemy hidden.