Optimization Tips

That is true Kirrill except for this one line:

Quote:

---

each outer if statement must not have anything else in it escept another if statement

---

Not block quoting an if means it only relates to the next line, so its perfectly legal to do:

if(true)
trace("");

Yeah, I left that out because I only wanted to relate it to those nested if statements. :)

Not sure if something like this has been posted here. I don't remember reading about it at least. But I ran this check:

code:

---

function f1(){

	return f2();

}

function f2(){

	return f3();

}

function f3(){

	return f4();

}

function f4(){

	return 1;

}



function g(){

	return 1;

}



var j=0;

var t=getTimer();

while((j++)<100){

var i=0;

while(i<4){

	g();

	i++;

}

}

trace(getTimer()-t);



var t=getTimer();

j=0;

while((j++)<100){

f1();

}

trace(getTimer()-t);

---

And for a limit as low as 10 iterations it produces very good results. So using a sequence of functions that call each other is much more efficient than calling those functions using a loop.

Edit: Actually, I thought the better time was because only 1 "f" function returned something and because a function had to be referenced from the array, so I fixed those, but it still runs better. In practice you probably wouldn't be calling g over and over you'd be calling different functions, but for this purpose I changed it to only call g.

Okay, so I only read half-way through the posts, so I'm not sure if I'm repeaing anything here - but I thought I'd try and sway the conversion back onto short snappy tips :)

* use magic computer numbers where possible (i.e. numbers that have an integer as a sq root ) - esp. if these numbers are used often e.g. as the width and height of your tiles.

* keep track of onscreen MCs in arrays (think io::pred touched on this). Loop through this to check for hitTest instead of leaving a running onEnterFrame

* don't forget to break loops if searching for a particular value

* pre-computer values, and create look-up tables. E.g. For tile engines, instead of finding the logical(array) position of a sprite, and then mutlipling by tile width and height, pre-computer a look-up table of all possible positions and then refer to this array( dimensions would obviously mirror logical map array )

* divide screen into a few larger blocks - only turn on AI for opponents when player is within same block

* 'smoke and mirrors' instead of real AI - sometimes using just Math.Random can create some seemingly intelligent behaviour

* not sure if it's still the case, but when an SWF runs on your computer, Windows allocates a certain number of CPU cycles to the Flash player. If you embed a second SWF on the same page, but doesn't contain or do anything, Windows should free up some more cycles for the Flash player - and hopefully you'll see the difference in the more intensive movie.

* suprised there are hardly any turn-based Flash games a la Laser Squad. Real-Time programming issues are less important. I aim to recify this :)


chopsticks

Hey Tom... isn't it time to clean out this threath?

Remove all posts and make a nice list of all usable stuff posted here...

SaphuA

Its already done mate, its on my site... it'd be horrible to clean out this entire thread!

*check signature*

BTW I just performed my optimization on my shooter and the results were really amazing. I knew it would run better, but I didn't think it would run so much better.

Correct me if I'm wrong (I haven't read through all this, so it may have been mentioned). When movies are compiled don't for loops get transformed to while loops?

I remember a while back I downloaded the trial of ASV (sorry I know I shouldn't have :D) I did notice that for loops were changed to while loops, or is it just the way that ASV formats it?

If the if contains a boolean check there is no need to check the state in the loop with: if (logged == true) you can just use the following:

Code:

---

// Traces the result as logged = true
logged = true;
if (logged) {
        trace("hello");
}

OR

// Doesn't do the trace check like != (not equal)
logged = true;
if (!logged) {
        trace("hello");
}

---

Trickman, in byte code a while loop is different from a for loop, hence the slight speed increase in using a while loop ( Although with 2.4k all bets are off ;) )

Kirill thats a cheeky little tip mate, I'll be giving that a go as I used a stupid amount of functions within a loop for the current game.

Squize.

I had code where I had a list of mcs and I went through all of them using a loop and called a function in each. I changed it so that the function of an mc would call the function of the next mc in the list, so eliminating the loop guard check and the counter variable. That's why, I would guess, it became so much faster. :)

hi,

I tried splitting up IF statements using the code in this thread:

Code:

---

function unrolled() {
        // unrolled
        timer = getTimer();
        var temp = 0;
        for (var i = 0; i<100000; i++) {
                if (i) {
                        if (i) {
                                if (i) {
                                        temp++;
                                }
                        }
                }
        }
        timer = getTimer()-timer;
        var_unrolled = timer;
        //trace("unrolled= "+timer);
}
function rolled() {
        // rolled
        timer = getTimer();
        var temp = 0;
        for (var i = 0; i<100000; i++) {
                if (i && i && i) {
                        temp++;
                }
        }
        timer = getTimer()-timer;
        var_rolled = timer;
        //trace("rolled= "+timer);
}

---

http://www.headland.nl/michel/ifs.html
(fla is in same dir, ifs.fla)
Click on the 'rolled/unrolled' text to start the functions.

I find that after repeated testing, it saves me only 200-300 ms. Is that such a big deal?


another point: in the beginning of this thread Squize asked how you deal with attributes if your tile-map is only one-dimensional. I haven't found a reply to that, and I'm really curious about that. Should you store the attributes in the frame with the tile(if you use a separate tile-movieclip)?

regards and thanks for the many tips in this thread!

300ms is definatly a good saving, this is flash were talking about! Even when that is itterated over 100,000 loops like you have there, when you consider that to have a FPS of 25 each frame needs to compute its code in around 45ms... a saving of only a few ms can increase the frame rate dramatically.

thanks! I tend to over-optimize, so I was just checking..

..not sure if this stills holds true, but in previous versions of Flash, it used to be the case that if you moved all content( mainly graphics ) off all frame 1s, you see noticable speed increases.

e.g. for mcCharacter.mcStand, leave first frame blank, and stick a stop(); action on frame 2 where the GFX is.

chopsticks

Using the empty frame to "turn off" an mc is a very good technique, because unlike _visible=false it leaves nothing in the mc to render, so if you have many such empty mc's there's no slow down unlike if you use the _visible method.

I thought this had other implications, i.e. Flash just doesn't like stuff lingering around on frame 1.

I wasn't talking specifically about hiding stuff, just moving it off frame 1.

I'm making this tank game, and there our separate parts to the tank, cannon, tacks, body etc..
I was wondering which is more optimized:
A)To do a hittest of the whole tank(The outer movieclip)
B)Use a while or for loop to test each part individually...

Thanks...

hi,
I've recently published an article with benchmark tests about actionscript tweaking. You can read it here: http://www.gotoandplay.it/_articles/...imizations.php

We run 2 set of benchmark tests under the flash player 6, using code compiled under MX and MX 2004. Results are pretty interesting :o

I was reading this thread yesterday and there's some great stuff in here, but it got me thinking about graphic formats, so I've run a quick test, but the results are unexpected.

The code was:

code:

---

var timer = getTimer();

for (var i=0; i<=800; i+=4) {

for (var j=0; j<=600; j+=4) {

graphic._x = i;

graphic._y = j;

}

}

trace ("time: "+(getTimer()-timer)

---

and the movieclip 'graphic' had a 72dpi 32x32 pixel colour image.

I replaced the graphic with a different file format and ran the test 5 times for each and averaged the results.

Here's what I got:

gif - no transparency - 883.4 m/s
gif - with transparency - 879.2 m/s
png - no alpha - 883 m/s
png - with alpha - 881.2 m/s
jpeg - low quality - 918.2 m/s
jpeg - high quality - 889.6 m/s
bmp - 878.6 m/s
bmp - with 'break apart' - 883.6 m/s
bmp - traced - 888.8 m/s

I would have thought that the traced bmp would be a lot higher, and that the png with alpha would be slower than the png without alpha.

...unless my test is just pants of course

has anyone else tried something similar?