Optimization Tips

[tomsamson]

hey there siriuss,welcome on board
this line does the same as a normal while loop,just with the difference that it runs a bit faster (+ operator acts slower than - operator,that´s why i used the minus way round)

[siriuss]

Ok, but where's the check i.e.

while (i>0)?

Sorry if I'm appearing a bit thick.

[JediMind]

When it comes to using pics (if its in the .swf)

I dont have much experience with png so i cant speak for that format,
but you can (for a small pic) use a .gif with less than 255 colors and much smaller size, and still beat the .jpg quality that has to me much larger in size, and heavier. if the pic is small enough.

I like to hear more about what kinda pic format and any other pic optimizing tips

[Kirill M.]

A repost of my code for a linked queue of objects. Sorry for the intrusion I was asked to post here, as well.

Just thought I'd give something out and see if it helps anyone. This is an implementation of a queue of objects (I primarily used it for MCs).
You could use it for any situation where you need to manage a collection of objects. For example in the technique that Squize described several MCs are attached at the begining and then instead of attaching MCs again you could take one from the ones you already attached. This linked list handles the management of that collection of MCs.

//A node in a linked list containing an object and a pointeter to the next node.
//parameters:
// Any object.
function lNode(mc){
	this.mc=mc;
	this.next=null;
}

//Head of the linked list.
function hNode(){
	this.head=null;
	this.tail=null;
}
//Enqueues an object 'mc' to the list.
//parameters:
//  An object to store in the list.
hNode.prototype.free=function(mc){
	if(head){
		tail.next=new lNode(mc);
		tail=tail.next;
	}else{
		head=new lNode(mc);
		tail=head;
	}
}
//Returns and removes the 1st object from the list;
hNode.prototype.alloc=function(){
	var tmp=head;
	if(head){
		head=head.next;
		if(!head){
			tail=null;
		}
	}
	return tmp.mc;
}

Here's an example of how to use it:

var pool=new hNode();

for(var i=0; i<10; i++){
 this.attachMovie("LinkName","mc_"+i,i);
 this["mc_"+i]._visible=false;
 pool.free(this["mc_"+i]);
}

//Get an MC. <=> attachMovie()
var temp=pool.alloc();
temp._visible=true;

//Make temp do something.

//Return temp to the manager. <=> removeMovieClip()
temp._visible=false;
pool.free(temp);

//

You could of course easily accomplish something like this with the Array object using shift() and push(), but that would be slower because the Array would have to shift all the elements down by one everytime you do a shift. Plus when the array outgrows its bounds it would have to copy all it's elements into a bigger array, which is also slow.

[io::pred]

Agreed. Linked lists == fast.

[siriuss]

If you are doing a tree (say mapping stations on the underground) would it be best to define a kind of 'branch' node or use a linked list as an element of a super-linked-list? If that makes sense.

[Squize]

Kirill:
You already know that I think that code is cheeky

siriuss:
Not ignoring you mate, to be honest I don't know the def answer.

JediMind:
I don't think differing graphic formats have any sort of impact, unless you've got alpha in your png or you have smoothing turned on.

As far as I know the Flash player stores all bitmap data in a chunky format as opposed to planar, so having less colours in your bitmap ( Say a 8 colour image which would only take 3 bitplanes in a planar system ) won't give you a performance saving, just a filesize saving.

I'd like to know a 100% though, anyone ?

Squize.

[siriuss]

If you can read C there's a good set of articles on L-Lists here that I have found.

I imagine complex path finding would have to use such lists but I have yet to try it.

[Kirill M.]

Yeah, linked structures are a good way to represent data. Not very memory efficient, but with todays memory amounts that's not too much of a problem. BTW does that complex Tree recursion problem seem simple to anyone else or just me?

Edit: You'll probably have to explain your problem in more detail, sirious. I'm not quiet sure what you mean by branch node. If you're making a tree then you don't really need any other nodes aside from the ones that the tree is made of. Each node in your tree would have a collection of pointers to its children that you could store in an array. So I don't really see what you'd call the branch node in this setup. Do you mean that instead of an array of pointers to children you keep a linked list containing pointers to the children?

[JediMind]

WIth the pics, i ment optimize the quality versus the size of it.

[siriuss]

Krill M:

Basically I was thinking back to my Comp Sci days when we were presented with the problem of developing a ticket program in C++ for the underground, that found the shortest route between any two underground stations that were stored in L-Lists. Now those days I was more intent on socialising than learning and so stuck to doing the uinterface, whilst keener players in the group worked out the algorithm. However, a few years on I am getting interested in serious programming and want to tackle L-Lists, and I think this is a good problem to have a go at.

The problem is: if you have ever seen a map of the London underground, it's a complex beast with lines that interlink all over the place. Before even considering the path-finding algorithm I need to be able to clearly structure the lists of stations, and this is where I get a bit stuck. When I get some time I'll have a real go at the problem, but as you brought up L-Lists I thought I'd ply as much info out of you people as possible!

[apologies for straying OT]

Cheers,
Siriuss

[Kirill M.]

I don't think linked lists or trees would be sufficient to represent the subway system. It would be better to use a general graph for that and a lot of pathfinding algorithms are based on graph theory. Good luck with your research.

[Squize]

"WIth the pics, i ment optimize the quality versus the size of it."

This thread is more for optimizing at a code level rather than a quality vs filesize thing ( Usually faster code is bigger code ).

In saying that the general rule is jpeg for photographic images and gif/png ( I opt for png 'cause it seems to compress better for me ) for everything else.
I guess a small photograph converted to grey scale could compress to a better size under png / gif than jpeg and with the better quality that affords ?

It all depends how you are using the images. For instance if you have a background image you can run a blur filter over it to give it a sense of depth and that'll compress really well with jpeg ( The theory being that the player won't notice the lack of quality 'cause they are playing your game in the foreground ).

Squize.

[Squize]

I thought I'd post the FLASM optimised version of pred's hitTest routine.

Change the action script to:

function removeClip(obj) {
    if (FLASM==true){
        $include ("pred_hitTest.flm");
    } else {
            ... 

(As covered in the tut thing). NB I've only done the actual removeClip() function. Then copy and paste the following into notepad and save it as pred_hitTest.flm

        push 'hitTestArray'
    getVariable
    setRegister r:0        //r:0 = 'hitTestArray'
    pop

    push 'obj'
    getVariable
    setRegister r:1        //r:1 = 'obj'
    typeof
    push 'number'
    equals
    not
    branchIfTrue label1

    push r:0
    push r:1
    getMember
    push 1, 'removeClip'
    callFunction
    pop
    branch label4

  label1:
    push r:0
    push 'length'
    getMember
    setRegister r:2        //r:2 = 'hitTestArray'.length
    pop

  label2:
    push r:2
    decrement
    setRegister r:2
    push -1
    subtract
    not
    branchIfTrue label4

    push r:0
    push r:2
    getMember
    push r:1
    equals
    not
    branchIfTrue label2

    push 1
    push r:2
    push 2
    push r:0
    push 'splice'
    callMethod
    pop
    push '', 1
    push r:1
    push 'removeMovieClip'
    callMethod
    pop
  label4: 

I did this pretty quick so if I've screwed anything up please let me know.

Squize.

[BlinkOk]

squize,
1. your last two posts deal with substituting registers for variables. is that the only form of optimization you can do or am i jumping the gun?
2. you use the $include statement to include byte code into your .fla. is it possible to physically include the bytecode rather than use the $include statement?
btw: the tutorial is great! prolly the most valuable posts i've seen in quite a while

[Squize]

Thanks blink, coming from you that means a lot.

1. It's one of the main ways. Putting a value on the stack and using the "dup" instruction is quicker than registers but it's so easy to screw up the stack handling ( And that may go undiscovered for a while. It's not a blatant slow down or crash ). Also putting values onto the stack isn't that flexible in that you have to be very specific with the order you put values on there.
The offical site touches more on how to use the stack to speed things up but to be honest I didn't want to go outside the scope of what I was trying to do. There are a lot of concepts there that will be totally new to a lot of people reading it. I was just trying to help people get their toes wet with it and then decide if it was worth their while or not.

Another less obvious way to speed up your code is with the branch instruction. If you look at pred's function you'll see that label3: is missing. A lot of generated code will look like:

   branch label3
   ...
label3:
   branch label4 

So the first call can be altered to point to the correct label directly thereby saving a wasted branch call.

Personally I just use FLASM on small functions that are run every frame and normally have a loop in them. It seems to give the best return for the effort.

Robert Penner has posted a fair few FLASM examples (Is there anything he's not good at?) so I'll try and hunt down the links ( I'm only posting fairly simple improvements, when you see code done by someone good with FLASM it'll just blow you away ).

2. You can use the FLASM macros and embed the code directly ( As in the tut. ). I see what you mean, if you could just drop in some macros in the middle of your code to set a register quickly instead of having to $include a seperate file, but I'd imagine that'd mess up really quickly 'cause you wouldn't be a 100% sure how Flash would compile the code when publishing.

With the way I use the $include tag ( Within an else statement ) it means that if you are increasing the size of your swf ( If you use update with FLASM the action script is not run and therefore junk ) and so that should be removed in your final fla.

----

I'm toying with the idea of writing a util that'll automate some of the process, like removing the wasted branch instructions etc. ( I've not looked into it too much, but most compilers generate code in "patterns" which you can speed up automaticaly, so for example a while loop will always look pretty much the same ).
Don't know how much call there would be ( Or even if it's feasable ) ?

Squize.

[random10122]

Ok, this thread is getting waay too complicated!

Quick question, does removeMovieClip take a lot of CPU? Because i am currently using removeMovieClip() even when the MC might no be there, if it is slow would it be quicker to check whether the MC is in the movie first? And if so how can this be done?

Cheers,

[leif0]

I don't KNOW, what is faster, but i think the remove should be... since if-statements are really slowing down. Best would be to KNOW by logics if a movieClip is there or not.
You can check the existence of a mc by checking its properties. For Example i use mc._width in such a case.

[AJ Infinity]

Using removeMovieClip() speeds up stuff for me. I'll upload an SWF demo if you want. It also decreases the amount of RAM Flash Player is using.

[adityadennis]

Ok, this thread is getting waay too complicated!

mmm-hm. It's just because it's filled with everything from flasm to hittest, though