Optimization Tips

Im interested in this if its gonna offer a preformance increase over onEnterFrame...

Are there any tuts anywhere? Its hard to decipher that when i havent had much experience with AS broadcaster.

lets say you have 200 of enemies in a game level. In order to make their AI intressting, you need to update information on every one of your enemies every now and then.
Now imagine that u have an object named enemyEvents inside of your enemy mc.
And when you created the 200 mc's (in a loop) you allso made every enemyEvents objects listeners to a enemyBroadcaster object

code:

---

//_root:



//making object global

_global.enemyBroadcaster= {}



//making object a broadcaster

ASBroadCaster.initialize(enemyBroadcaster);



//creating enemies



for(e=0;e<200;e++){

_root.attachMovie("enemy","enemy"+e,e);

}

///

//

//enemy mc:

enemyEvents={}



//listen for events calls from broadcaster

enemyBroadCaster.addlistener(enemyEvents);



//making an event function 

enemyEvents.onHeroLooseLife=function(){

trace("I smell blood");

}

///

//...listen on a different way for the same event...

//

//friend mc:

friendEvents={}



//listen for events calls from broadcaster

enemyBroadCaster.addlistener(friendEvents);



//making an event function 

friendEvents.onHeroLooseLife=function(){

trace("I will rescue you");

}







//

//

anywhere:



enemyBroadCaster.broadCastMessage("onHeroLooseLife  ");

---

the line:

enemyBroadCaster.broadCastMessage("onHeroLooseLife ");

replaces:

for(e=0;e<200;e++){
_root["enemy","enemy"+e].onHeroLooseLife();
}

not to forget the friend loop, as we made friend objects as listeners aswell for the "onHeroLooseLife" event that the enemyBroadCaster called.

and you can have as many events as you like, and if you make your broadcasters global, you can acces them from everywhere, your event functions will be out there listening and waiting in piece to be triggered.

for a real tute, check the actionscript forum, the sticky thread about asbroadcaster explained

i did a test. it does seem to be faster although the speed improvement would be marginal with a small (<30) number of mc's. but hey any improvement is good.
these tests are with 100mcs.
broadcaster;
http://www.nlc.net.au/~oceana/games/broadcaster.swf
loop;
http://www.nlc.net.au/~oceana/games/loop.swf
enterframe;
http://www.nlc.net.au/~oceana/games/enterframe.swf
.flas to check and see if i stuffed it up;
http://www.nlc.net.au/~oceana/games/broadcaster.zip
http://www.nlc.net.au/~oceana/games/loop.zip
http://www.nlc.net.au/~oceana/games/enterframe.zip
this is very interesting. results on my crapola pc;
broadcaster: 16
enterframe: 16
loop: 13.7
i did use a function in the loop benchmark so mabey that's what's causing the slowdown

I got
BroadCaster: 14.7
Loop: 18
EnterFrame:18.7

remember to run these without any other applications running

I've not played with ASBroadcaster enough and perhaps this is just a stupid post, but couldn't it be set up to give automatic hitTest detecting ?

If there was a way to add a listener for a collision event ( Via ASBroadcaster ) it would get rid of a lot of checks in your code ( ie to see if a collision was worth checking in the first place ).

I haven't played with listeners enough, is it actually quicker ( Performance wise ) to set up a key.listener than the usual method ? I've always thought of them as yet another "layer" on top of your script, in that they sit in the background listening out for a certain event all the time ( Like an interrupt routine ) when you may as well just do your keyboard check as normal.
I can kinda see them as being quicker when no key is being pressed than checking the normal way, but I would have thought they would be slower when a key is pressed, which would negate their use.

Thanks for posting those examples Blink :) Loop showed up fastest with me to.

Squize.

From those swfs that Blink posted, i cant see a huge performance increase, and to be honest i wouldnt really expect one. At a lower level the exact same thing is happening isnt it? Well.. i say that but possibly not with keyboard input. Because the keyboard creates an interupt at the processor level a 'listener' would probably detect this wherease the if(Key.isDown( would check everyframe. Im probably talking rubbish and no doubt one of you will have great fun putting me right - *looks at ripX*

I've been learning about ASBroadcaster from senoculars great tutorial, so when i saw this come up in this great thread, I thought i will put my 2 pence in :)

According to this and other things i've read this last week, listeners don't really sit in the background "listening", like the "interrupt routine" so called by squize. They are ( esentially, at least you can replicate their behaviour from, ) a for(in) loop, that loops through the list of objects that are supposed to listen to them, called a certain method to control that objects response to the event. E.g. a onKeyDown method attached to your custom key listener object. I would imagine, in the same example, that seeing as every OS ever already has ( probably these interrupt routines ? ) to detect keys anyway, that flash just uses that to fire the onKeyWhatever to all the listeners to the Key object. I.e., loops through them. So it's ( probably, but i've no idea for sure ) just more of an OOP thing to use a seperate object, in this example the Key object, to control a certain event. That's the whole point of OOP, to put things in nice contained boxes, like the real world. So i don't think that it would put another "layer" onto your code. But again, i have no techical knowledge of the flash player, but it would just seem illogical to do something that the OS does anyway. Besides, is not checking for a Key.isDown state every frame exactly the same as "listening" for a key. In the true sense. You are contantly checking, then doing something, "interrupting" ;), when the event occurs. With Key listener, you are only doing something when it happens. The "listening" part is done by the OS.

Anyway, bit of a mouthfull, but that's what i think i understand of it.

P.S. This thread rocks! :p

Phew Jon! You trying to steal my role as the person who writes too much ? ;)

I had a read of senoculars tut the other night but I was tired and nothing sank in.

I still don't get how listeners are quicker than just checking anyway, perhaps I'm just being really stupid here.

'Cause the player is a virtual machine I guess it runs it's own internal interrupt routines ( Check my ramble about Flasm for more on the virtual machine ). I doubt very much it uses an OS keyboard interupt, porting Flash6 to a Nokia would be made a lot harder with them having to write their own keyboard interrupt routines anyway.

So you have the "master" listener routine running a for-in loop for all the listeners put into the queue, keyboard etc. When a listener "hears" something it calls the relevant function.
So you are still having that code overhead ( Or "Layer" as I called it earlier ) of, well, listening. Yeah if no key ( I'll stick with the keyboard as an example ) is pressed then it's going to be quicker than:

code:

---

if (key=="a"){

...

} else if (key=="b"){

...

}

---

but surely if a key is pressed you've got the overhead of listening out for it and then running the same code anyway ?
When a key is pressed that we are waiting on we are making more work for the Flash player anyway ( ie press space to fire, you're then doing all your checks for a spare bullet, attaching it, setting it on it's way etc. ) so by just checking anyway we are spreading the cpu load out a bit more rather than giving Flash more to do when you need it to do other things.

I hope I've worded that ok ?

I'm not anti-listeners or tied to 5 syntax or anything stupid like that, it just seems a slightly slower way of doing things.

Please prove me wrong :)

Squize.

Lol, no i couldn't possibly compete with the writing "beast" that is squize ;) But I admit I did go all "tomsamson" for a while there, no spaces or paragraphs, hehheh :D

Quote:

---

I doubt very much it uses an OS keyboard interupt, porting Flash6 to a Nokia would be made a lot harder with them having to write their own keyboard interrupt routines anyway.

---

Is it me or does that sentence not make sense? That's exactly my point. Why write your own keyboard detection code for every OS that you will be supplying the flash player for ( Windows, Nokia, whatever ) when they will have their own built in anyway? But then you say you doubt they use the OS keyboard listeners. :confused:

Truth of the matter is, i have no knowledge what-so-ever about this kind of "low level" programming - physically detecting input devices. I know you've said before you used to do assembly, so you'll probably know better. So i don't know that if you create a Key listener ( keeping with the example ) whether the flash player adds it's own code listening for keys, or the OS fires the flash player to fire onKeySomething methods. I've been searching for flash player tech notes for over an hour before writing this and nothing, so maybe i'll email macromedia :D

I agree, that even if you do use key listeners then you still have to go through and check which key was pressed so you can do something about it, so it dones't make it any quicker to code, and probably not quicker actually running, it's just the more "OOP" way of doing things. Oh actually, one advantage ( if you need it ) that springs to mind is that you can, of course, add more than one listener. So if you wanted all mc's on the stage to go left when left key pressed, it'll for(in) through it's listener list and fire their onKeyDown event.

I personally take a middle approach anyway. On my site just about the only thing i've managed to finish is my key press tut. There i use a listener to update the press state of keys i'm interested in, but then store them in a variable and use them in if statements within an onEnterFrame loop or something. Not the best way to do it, i'm sure, but it is nice and simple when you're actually controlling what to do with the key states when using variables, instead of writing Key.isDown() stuff all the time. But, i'm still learning this stuff. We each have our own methods, and at the end of the day they do the same thing. But i guess the question is speed since this is an optomisation thread :p.

I would suggest that if there is only a few keys to be checked, use if (Key.isDown()). If there are lots and you need multiple objects to respond to the event, then use listeners. Just a trade off that will have to be experimented with depending on how much you need it.

:eek: bloody hell this is got to be a big post, i'll stop here! :D Probably completely undecipherable ramblings, so forgive me if it's confusing. I'm re-reading it and getting myself confused already! Sorry for intruding on your long-post pimping grounds ;)

Hi, this has been an interesting thread. I'm a bit late, but maybe someone is out there to answer this:

What if I have a movieclip that doesen't have "stop();" in its last frame? The clip has 1 frame with graphics. [I've noticed I seem to forget the "stop();" from 1 frame movieclips :p]

So there might be n+1 movieclips looping forever eventhough there might not be any visible effect. Does this slow the game/app/etc much if there's, let's say, 50 of them?

Okies, Im about to share one piece of optimisation that I discovered lately, this is really quite awesome, its quite a simple mod, and it can cut a fair bit of time off.

Say we have code for a player, and it has ALOT of Key.isDown's in it, say, if Up is down, and, if Up and Down, and, if Up and Left etc. etc.

Its just a way of getting the state of all the keys you need at the start of the frame, just by simple bitmasking, then you can do a simple bit comparison to get the state of the key you want. This saves about 65% vs normal Key.isDown's

Attached is some code.

Couldn't d/load it cheeky ?

All the bit operations are stupidly fast, and very few people use them. Whose gonna crack and write a tut and some nice easy prototypes for using them ;)

FlashedForGood I don't think a 1 frame mc needs a stop ( Performance wise ). I use a tile based approach to all my sprites in a game (ie. Have all the frames of animation for all the different baddie types in one mc ) and out of habit I use a gotoAndStop(1) when they are not running 'cause I noticed in the debugger that even if the mc _visible=false it still loops through the frames.

As a side note, there's a little bug with attached mcs with a stop() on the first frame. If you wanna gotoAndPlay(frameNumber) when you first attach it it wont. You've got to leave a frame pause and then do it ( This doesn't affect all our tile based engines because you just gotoAndStop(tileNumber) ). What fun I had trying to sort that little flash gem out ;)

Squize.

Hmm it downloads right here.

Got it this time. Either the board or me being lame :)

Also Andre has posted a ASBroadcaster based collision routine ( http://www.andre-michelle.com/ ), have a hunt around for it. Not tested it yet ( He posted it quite a while ago ) but you know it's going to be the dogs.

Squize.

iopred, that's a very good optimization. It's not the bitmasking itself that makes is fast but rather the fact that the Key method isDown() is not called multiple times. In fact, it is even faster if you use normal booleans instead of bitmasking:

normal: 748
bitmask: 535
booleans 473

(I have plugin version 7)

hehehe yeah very true, gotta say I didnt even try that, I came about this one because I was making a combo system for a fighting game, so i needed to be able to store the entire state of the keys in one integer.

Oh well.

Quote:

---

In fact, it is even faster if you use normal booleans instead of bitmasking:

---

:D That's why i use it in my tutorial :D But very nice idea iopred, saving it into one number.

Another obvious optimisation to this, but worth repeating, is to cut down the time used to look up the Key object.

code:

---

getKeys2 = function () {

	var k = Key.isDown;

	kLeft = k(Key.LEFT);

	kRight = k(Key.RIGHT);

	kUp = k(Key.UP);

	kDown = k(Key.DOWN);

	kSpace = k(Key.SPACE);

	kCtrl = k(Key.CONTROL);

};

---

Shaves a few millis off :) And using the direct number, instead of Key.KEYCONSTANT is quicker too. For the same reason.

Good stuff, once more in this great thread, keep 'em coming.

I dont understand...

The slow one is checking the state of the keys 10000 times yea? But the two bits of code that are supposed to be faster are only checking the state of the keys once! If the state changes in the loop then it wont be picked up.

Am i missing something?!

The state cant change in the middle of a loop, flash only sets its own key flags at the start of every frame.