Optimization Tips

[adityadennis]

Alright, I thought I'd make a thread on Optimization tips.
I've started it, please feel free to add:

Avoid using 'for' loops in (enterframe)
Use masks
Dont scale the movie (dont make it larger)
Use removemovieclip
Get the FPS counter from www.moock.org

[Squize]

What the heck a good thread like this is long overdue...

Avoid using dynamic text boxes.

Outlines 'round your vector images have a performance hit.

while performs quicker than for in most cases ( Although for in is the quickest of the lot ).

Not all code has to run every frame, use flip flops for non-100% time critical things ( Even collision detection ! )

Try to use as few enterFrames as possible.

a=b=c=0 is quicker than
a=0
b=0
c=0

Define things like parent in mc's as a local variable, ie var p=_parent, it reduces the time taken for looking it up.

When using an if statement with an else use
(condition to check ? true action : false action)

Skip this. in mc's where possible.

That's me spent for the time being ( And I'm sure PrED32 can prove me wrong on at least some of the above )

adityadennis could you elaborate on a few of your examples ? Like "Use masks" and "Use removemovieclip" ?

Squize.

[PrED32]

mc.setMask()'s dont help speed up.. At least in the test's I've done.. I'd like to beleive they do, but I havent seen proof. I've seen them as being slower, cause flash draws the entire MC, then masks it out.

Squize, you got most of it not much to elaborate on..

I found that the more Key.isDown(Blah)'s you use it can slow it down... Strange that...

(condition ? action : else) I dont beleive is faster, I think when you compile it breaks it up to flash's native if statement..

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.

Setup collision arrays instead of having 1000x enterframes, or having to evaluate a string 1000 times. You can use them like this:


for(i = 0;i < collisionArray.length;i++){
if(hitTest(collisionArray[i])){
//OMFG IM DEAD?!?#!
break;
}
}


I might work a tutorial to do that, its ALOT faster than any other method IMHO..

for in is quick, but you have to sort out what you want to use.. it doesnt differentiate between variables, arrays or mc's.. so you have to do it for it..

I gotta go to work.. I'll think of some more.

[BlinkOk]

consider flashes dictionary lookup time vs checking yourself.
this code that looks through all objects within a movieclip
and calls the function render() for each movieclip;

for (i in mc) {
 if (typeof(eval(i)) == "movieClip")
   mc[i].render();
}

the code would cause flash to lookup the dictionary twice for each movieclip and once for other objects (the condition). i can code the same thing, omitting the check like this;

for (i in mc) 
   mc[i].render();

this will have the same effect as the first code fragment however now there is only one dictionary lookup per object. when flash discovers that the object is not a movieclip, it just does nothing.

[DuMan]

What about converting graphics into .png, .gif, or .jpg. Which one of those is best btw?

[PrED32]

Fairly sure that all the image types are the same, gif transperancy of course takes a little longer, and PNG alpha transperancy takes even longer than that...

Im sure calling mc[i].render(); ,even on objects which dont have a render function would still be slow, flash would still have to put the object on the stack and see if it has a render function.. just my opinion, I'm known to be wrong... all the time =)

[Squize]

I'm sure Tomsamson said jpeg was quicker in a recent post but to be honest I'm not sure, I just go for png for sprites / tiles and jpg for larger bitmaps ( Purely for filesize issues rather than performance reasons ).

I know it's going to cause a load of groans, but the old Flash4 syntax is quicker than the dot syntax ( I must admit I use dot syntax )

tellTarget is a lot quicker than with

Don't move gradients around and use _alpha as little as possible.

The length of var names isn't that much of a killer. I've seen so many code snippets posted where something really vital like "score" is just shortened to "s" ( And not just locally for the sake of a loop ). Don't scrimp on var names, when you look at the code in just a weeks time to rip out a cool routine for a current project you're just going to have a headache.

Wherever possible avoid "and" and "or" in an if statement. The majority of the time one of the statements won't be valid and you are causing Flash to retrieve and test all the data every time. Use seperate if statements when possible ( Also if you've got a lot of if / else statements try and put the one most likely to be meet first. In real life that's not always possible but... )

Speaking of which

(condition ? action : else) I dont beleive is faster, I think when you compile it breaks it up to flash's native if statement..

I'll try running that through FLASM later.

For some strange reason key constants ( eg "SPACE" ) are slower than using raw keycodes.

Storing built in functions in vars can speed things up, eg
var Mpi=Math.PI;
'cause it saves 2 look-ups

Precalculate whenever you can, eg
var rad=Mpi/180;

Something else you see a lot of, and we've all done it a million times, is not use values in a smart way,eg

Nearly everyone has written a player sprite routine with a keyboard reading routine. So you check the keyboard, and move your _x and _y blah, blah, blah.
Then further down the code you do your player-2-background collision checks, where you check left/ right/ up/ down.
You already know which direction you've moved in and yet you still have to check all directions, so in effect you are checking something twice.
Store all your collision checks in seperate functions and in your keyboard routine ( After you know which key has been pressed ) set up the var collisionFunction=directionToCheckFor then further down the code just call collisionFunction();

( I hope I've explained that ok )

That's more than enough from me...

Squize.

[PrED32]

Yeah, Nice work squize eheh.. Shame my memory isnt as good as yours.

Somone proved that having say:

thisisanobsenelylongvariablename = 1;

is alot slower than:

shorter = 1;


Umm.. this might be trivial.. but flash 4 syntax also includes using AND and OR instead of && and ||... If history repeats itself, than flash 4 should be faster... but then again, the reason nobody uses flash 4 syntax is its terrible.


and as squize said, in an if statement, if say your checking if the key is down, and the alpha of it is > 50.. figure out which of those is MORE likely to be false and put that first, so say its more likely the key will be up do it like:
if(Key.isDown(blah) && _alpha > 50){
}
It saves a bit of time, especially with REAL long if statements, which if broken up would take 10 or 15 lines >=) (we've all had them)


If you have a object thats going to be at 0 alpha for a while, just _visable = 0; it, 0 alpha's still get drawn.


If you have say, bullets.. and your doing it the crappy "give them all enterframe methods" (which EVERY one is guilty of), try not to give the attached clips many variables.. Ive noticed the difference of say giving them, x, y and speed with giving them x, y and having a standard speed.. over time its more things for flash to store,
oh and obviously, if the projectiles are using Math functions which need deg->rad, keep the variable with the value of 180/Math.PI OUT of the clip, thats just more space which isnt needed.

Marg.. Im sure there are plenty more.. But I have uni in 6 hours and I need sleep..

[Squize]

I'm really suprised at this ( Sorry about the byte code )

PHP Code:

/*
if (score==500){
    trace("true");
} else {
    trace("false");
}
*/

    push 'score'
    getVariable
    push 500
    equals
    not
    branchIfTrue label1
    push 'true'
    trace
    branch label2
   label1:
    push 'false'
    trace
   label2:


/*
(score==500 ? trace("true") : trace("false"))
*/

    push 'score'
    getVariable
    push 500
    equals
    branchIfTrue label3
    push 'false'
    trace
    push UNDEF, UNDEF
    branch label4
   label3:
    push 'true'
    trace
    push UNDEF, UNDEF
   label4:
    pop


Why does Flash push UNDEF on the stack and then pop it back off ? ( I tested it with defining var score=50 and it still produced the same output ).

Is it just a Flash quirk or am I being really stupid ? It seems strange that (condition ? action : else) generates more ( And from the looks of it, junk ) byte code than the long hand way ?
OK, you can edit it by hand and save the "NOT" statement, but...

Squize.

[mbenney]

pretty sure all my tricks have been covered! great thread tho

[adityadennis]

squize, what I meant by RemoveMovieClip was pretty self-explanatory:
if you're making a game which involves shooting etc... remove the bullets once they have left the stage.
Hope this helps

[Squize]

I kinda thought that's what you meant, I just wasn't a 100% ( Sorry, I've got a cold out of no where and I rattle with the amount of Beechams in me, so I'm a bit thick headed at the moment ).

To be honest I hardly ever use removeMovieClip(), I just hide baddies / bullets off screen.

I know removing the mc gives you back some CPU power, but if I need 7 baddies on screen at once then I like to know may game can handle it without slow down. By always having them present ( Without running scripts in / for them ) I know the game's processor load is fairly evenly spread, so in the worst case ( ie all 7 baddies flying / running around ) it won't start dropping frames.

I also find that baddie init code is usually quite drawn out, ie picking the frame, number of hits, attack wave, postion etc. that adding an additional attachMovieClip on top seems like another burden for the Flash player, rather like the attach method of scrolling compared to the gotoAndStop method.

Perhaps it's just me, I come from assembler coding on the Amiga where everything had to fit in 50fps with no slow down, that I think that way ?

Sorry if this seems like some sort of rebuttal to your post, it's really not meant to be / come across that way.

Squize.

PS If this is just a ramble it's 'cause I'm smacked out of my head on decongestant

[adityadennis]

Yeah, thats what I used to do too, but I found my games to be a bit faster when I used RemoveMovieClip. I have the annoying habit of liking a lot of stuff to be on-screen at once, so every bit counts...

[chuckles]

this is a good thread for game n00bs like me....keep it going, some things need a little elaboration.

also, i'd like to see a tutorial on hitTest array (i think it was squize who said that)

[Squize]

i'd like to see a tutorial on hitTest array (i think it was squize who said that)

No 'fraid not, it was PrED32.

If there's anything I've been vague on then just ask and I'll try and explain it a bit better.

Squize.

[Squize]

I've been looking into the if/else compared to ? method, and I've realised I've been really stupid.
The (condition ? action : else) is not a quick hand replacement for if/else and should only be used if you want a value returned for it.

I couldn't figure when looking at the previous byte-code example I posted why Flash was pushing and popping stuff from the stack, but it's because I wasn't using the syntax correctly.

Yet more byte-code I'm afraid:

PHP Code:

/*
if(score==500){
    trace("true");
} else {
    trace("false");
}
*/
    push 'score'
    getVariable
    push 500
    equals
    not
    branchIfTrue label1
    push 'true'
    trace
    branch label2
   label1:
    push 'false'
    trace
   label2:

/*
trace (score==500 ? "true":"false");
*/
    push 'score'
    getVariable
    push 500
    equals
    branchIfTrue label3
    push 'false'
    branch label4
   label3:
    push 'true'
   label4:
    trace


So if you need a value returning from an if/else statement then use the ? syntax, otherwise stick with the usual way of doing things.

Squize.

[PrED32]

Well thats kinda the reason for (? syntax.. Its for returning values..

say you have a text box:

textbox = "state of variable = " + (y > 5?"good":"bad")

So its only for quick return statements is why you use it.

[Squize]

I didn't realise, I always just thought it was a short hand version of if/else

My bad.

Squize.

[PrED32]

Well it is a shorthand.. but its usually for one statement if's.. And generally that means that something needs to be returned:

if(toggle == 0){
toggle = 1;
} else {
toggle = 0;
}

toggle = (toggle == 0?1:0); (to change from 1 to 0, or 0 to 1)

hmm.. bad example.. you can always go toggle = !toggle but still, you get my picture.. I don think its possible (I havent tried, Im probably wrong) to do:

(blah == something ? { do(); this(); } : { do(); that(); })

[Squize]

I'm going to try and make up for being stupid over the "?" syntax

I don't know if anyone has a long row of if statements, like

PHP Code:

if (health==1){
   ...
} else if (health==2){
   ...
} else if (health==whatever){
   ...
}


If so it's quicker to work out if the value is greater than half the end value and split your statements up that way.

For example if you want to check if health is equal from any value from 1 to 10 do this:

PHP Code:

if (health<6){
   ...Check from 1 to 5
} else {
   ...Check from 6 to 10
}


So if the value is 6 you only have to do 2 conditional checks to find out instead of 6.
I know it's a common sense thing but it might help someone...

Squize.