OK, I have stumbled across many examples of AS and I have seen some programmers put an “.onEnterFrame” on movie clips, and I have seen programmers put call the movie clip through a for loop. For example:
[AS]
mc.onEnterFrame = function() {
// do stuff
}
[/AS]
or
[AS]
for(var i:Number = 0; i < 50; i++) {
// get the mc and do the stuff
}
[/AS]
isn’t one method slower than the other? Which one is it? Thanks
I think in your second example you are talking about having a main enterframe loop that will call a function on all the sprites to update? Otherwise that look will just run once.
So if you have a single enterframe loop, which has a ‘for’ loop (like your second example) to iterate all of your sprites and call a function. You could just ditch the for loop and tell your sprites to update individually (or iterate over groups of sprites). This way you have better control over the order in which your sprites update, also you can easily pause the loop. (eg. if(!paused){ …} )
You can also stage your code, check hits, respond, draw effects, etc. in an order. This would be less exact if you had enterFrames on individual movieClips, as things might happen a frame late.
[quote=gregmax;2332056]OK, I have stumbled across many examples of AS and I have seen some programmers put an “.onEnterFrame” on movie clips, and I have seen programmers put call the movie clip through a for loop. For example:
ActionScript Code:
[LEFT]mc.[COLOR=#0000FF]onEnterFrame[/COLOR] = [COLOR=#000000]**function**[/COLOR][COLOR=#000000]([/COLOR][COLOR=#000000])[/COLOR] [COLOR=#000000]{[/COLOR]
[COLOR=#808080]// do stuff[/COLOR]
[COLOR=#000000]}[/COLOR]
[/LEFT]
or
ActionScript Code:
[LEFT][COLOR=#0000FF]for[/COLOR][COLOR=#000000]([/COLOR][COLOR=#000000]**var**[/COLOR] i:[COLOR=#0000FF]Number[/COLOR] = [COLOR=#000080]0[/COLOR]; i < [COLOR=#000080]50[/COLOR]; i++[COLOR=#000000])[/COLOR] [COLOR=#000000]{[/COLOR]
[COLOR=#808080]// get the mc and do the stuff[/COLOR]
[COLOR=#000000]}[/COLOR]
[/LEFT]
isn’t one method slower than the other? Which one is it? Thanks[/quote]
But is there a difference in speed? Does it slow down the flash player any (that is what I am trying to ask)? Because on one hand you can prevent it to loop through all the enemies (if the game was paused), and the other it is still doing an onEnterFrame for each MC.
I have read somewhere before, and I pretty sure it was here on Kirupa (because everyone here really knows Flash extremely well and has more years experience - EXCEPT me, haha), that having too many “onEnterFrame” functions could slow down flash. But again, I have seen some programmers, mainly the “Italian Programmer”, always attaching onEnterFrame functions to each of the MC’s he attaches on stage. And all of his stuff seem to be running fast without any noticeable slow downs 
.
Either way it is just a function call, whether it is you calling it or the events system. In older versions of flash the speed of iterating through an array could be slow you down (a little) but that is tiny. Id be thinking that onEnterFrames would be just as fast - as the player is probably iterating all the movieClips and checking if onEnterFrame is set anyhow (thats a guess) - anyone else?
In AS3 however you will most likely be using external classes, which can obviously extend MovieClip, and listen for ENTER_FRAME events. We find it neater to separate each sprites functionality into classes. Then listen for custom tick events dispatched by the main game loop.
In AS3 as the event system works by registering a class for events (such as the ENTER_FRAME event) it most likely works by iterating an array of attached events and calling the function bound to the event… very similar to what you would be doing if you called a function directly yourself… so performance should be on par.
Also, most people would use setInterval for that nowadays…
Even for AS2 you should be using classes and extending MovieClip and calling the the enter frame from inside of the class.
You should only put code inside of it that needs to be executed every frame, so ask yourself do I need the code to be executed every frame, could I use something else instead.
Also you shouldn’t be using a timer for everything to, that is just as bad as throwing all of your code into a enter frame call.Because timers execute on a specific time they are great for things that you need executed on a specific time interval, but should only be used again where applicable and makes sense to use them.
Coding on movieclips itself freaking horrible, but I guess you already figured that out. I don’t use onEnterFrame anymore, at all, intervals suit me better.
I definitely prefer method 2. Not only do you have the ability to manage and loop trough arrays better this way, but also because you can manage your functions a lot better. I kinda dislike the whole flash way of handling things anyways 
well. there are always intervals, and timers.
Quite simply, the second method you posted isn’t an onEnterFrame method. You can’t make things move with the second one, it’s just a one off loop.
Thanks for the feedback fellas. I agree with you Armored Sandwich, putting onEnterFrames on the MC itself is very sloppy and it isn’t that controlling. So it seems that the method 2 I was this whole time is the preferred way. GOOD! haha, I didn’t want to find out now this whole time I was doing it the harder way or the more inefficient.
You guys also have me pondering on using intervals for animation. I have not heard or thought of using this method before. Again, from a lot of examples I have seen, they do the animation through a “game loop” function and use the intervals for timers. I can see that if you set the intervals to execute every 50 milliseconds, that is like achieving 20 frames per second, correct? Hmm… I will need to look into this method in the near future. It might be the best method to go through for my next big project 
In general, neither way is “better” than the other. Individual enterFrames will probably be a little slower because of the function overhead for each action, but you’d have to be dealing with thousands of movie clips to notice (though possibly less depending on how much work each enterFrame is doing). At that point, if you’re not doing a particle system or something where all your movie clips are doing the same thing or showing the same behavior, you’re most likely going to need to call individual “enterFrame” functions for each movie clip to get them to do what you want them to do in a loop anyway. So at that point, the loop approach would be no more the better. Loops are also a little less encapsulated. If you want to eliminate the enterFrame event (or reduce it to 1) in your application, you’re going to have to have a controller (our loop) that dips its little claws into all your objects making any part of that app dependent on that controller and less modular than it could be if it handled its enterFrame events on its own.
In general, if you’re dealing with a lot of clips that perform the same behavior (particle systems being a prime example) than a loop will give you the most bang for your buck. In most other cases, controlled use of enterFrame will suit you best.
Timers are a different beast all together and I wouldn’t recommend them for animation.
:: Copyright KIRUPA 2024 //--