PDA

View Full Version : onEnterFrame vs interval...


drexle
01-28-2006, 08:32 PM
Greetings,

I may be off-base with this assumption, but I'm going to go out on a limb anyway. I bet you love onEnterFrame. I know I certainly do! But there's something that I don't love so much about it... onEnterFrame can really eat away at the speed of the movie (and of your computer's processor) if it's doing too many things, and if there are too many movie clips all doing an onEnterFrame at the same time.

Do the more advanced scripters still make extensive use of onEnterFrame, or do you use Interval instead? If you use interval, do you know of any tutorials or articles to help get you into the mindset of using intervals for things that you might otherwise use onEnterFrame? Is there another option that I'm overlooking?

senocular
01-28-2006, 08:36 PM
If you use setInterval at a timing that matches the frame rate, it would be no faster than onEnterFrame. onEnterFrame alone isnt slow, its what you do every frame that causes the problem. If you have something in an onEnterFrame that doesn't have to be calculated every frame, dont use it in the onEnterFrame. Otherwise, onEnterFrame is where its at.

drexle
01-28-2006, 09:01 PM
Well that's good to know!

So, let's say that it's something that needs to be calculated every frame, but only on *some* frames... like say if(theTruth == true). Even if it's 1000 lines long, will the fact that it has to ignore those 1000 lines every frame add any burden to the program at runtime if (theTruth==false)?

senocular
01-28-2006, 09:08 PM
ignoring code wont have any hits on performance. The only hit you'd have in that statement, assuming theTruth is false, despite all those lines, is the if check. Thats nothing. All 1000 lines would be skipped and you'd have smooth sailing. Of course it theTruth was true, those 1000 lines would be executed and you'll be taxing the CPU a little more.

fugitive123
01-29-2006, 06:44 AM
Actually, what makes a better timer for a game? As far as I observe, I would go for the 'onEnterFrame' as it goes with frame rate of the entire movieclips of the flash file. If the system is slow, the timer will synchronize accordingly. This is pretty safe. Am I getting it right?

senocular
01-29-2006, 02:49 PM
Actually, what makes a better timer for a game? As far as I observe, I would go for the 'onEnterFrame' as it goes with frame rate of the entire movieclips of the flash file. If the system is slow, the timer will synchronize accordingly. This is pretty safe. Am I getting it right?
Yes, at least for games where reaction time is important, like races or platformers. If you're dealing with games that involve problem solving such as question-based games or simple puzzles, you would want to use timer since problem solving is not dependant on the frame rate and you wouldnt want people with slower computers having the advantage (though usually for those kinds of games, there isnt enough going on on the screen to cause slowdown in the first place)

cancerinform
01-29-2006, 03:48 PM
Just one point with onEnterFrame. It is better in a long script to avoid referncing onEnterFrame to the main timeline. If done more than once only the last claimed one will be executed. there might be problems sometimes finding the error. What I do is place empty movieclips on stage and and refer each onEnterFrame to one movieclip.

senocular
01-29-2006, 04:09 PM
You can also use the OnEnterFrameBeacon in AS2 which allows you to add listeners to MovieClips which then recieve the onEnterFrame event

cancerinform
01-29-2006, 04:23 PM
You made my mouth waterrish. How does onenterframebacon taste?:D

But seriously, how come it is not listed in the flash helpfiles? I have 8.

senocular
01-29-2006, 04:52 PM
Its not in the help files for the same reason the Tween class isnt (or wasnt). In fact, the Tween class uses it to operate - thats how its able to tween objects by frame rate without depending on a movie clip. Though, in actuality, it is dependant on a movie clip since the OnEnterFrameBeacon class creates one movie clip in _root from which it is able to obtain an onEnterFrame event and broacast it to its listeners.

To use it you just call:

mx.transitions.OnEnterFrameBeacon.init();
once, and you're ready to go. MovieClip can accept listeners and all listeners added will recieve onEnterFrame events.

cancerinform
01-29-2006, 05:10 PM
Thanks, found by google an example.;)

fugitive123
01-30-2006, 03:23 AM
Yes, at least for games where reaction time is important, like races or platformers. If you're dealing with games that involve problem solving such as question-based games or simple puzzles, you would want to use timer since problem solving is not dependant on the frame rate and you wouldnt want people with slower computers having the advantage (though usually for those kinds of games, there isnt enough going on on the screen to cause slowdown in the first place)

Thanks Senocular.

CyanBlue
01-30-2006, 04:02 AM
I heard somebody mentioning that onEnterFrame taks more memory than the setInterval... What's your thought on that???

senocular
01-30-2006, 11:32 AM
I heard somebody mentioning that onEnterFrame taks more memory than the setInterval... What's your thought on that???
If it does, I wouldnt think much. onEnterFrame is just an event. setInterval creates an event and associates that event with a unique identifier that could be used with clearInterval - not to mention it too is dependant on the frame rate to operate (which is why it cannot be relied on for accurate time keeping).

astgtciv
01-30-2006, 11:52 AM
Could you explain that last statement, please, senocular? I always imagined that there is a queue of active setInterval requests, and that queue is checked at a fairly brisk rate which has nothing to do with the frame rate... Or do you simply mean that if the code executed onEnterFrame takes too long, then your setIntervals won't execute on time?

senocular
01-30-2006, 12:23 PM
setInterval is not an accurate timer - and this has nothing to do with the onEnterFrame event, thats separate. I dont know exactly how setInterval operates internally, but in the Flash player uses the frame rate assigned to the SWF as a means for controlling when setInterval intervals are fired. You can see variations of this easily enough by using a setInterval method that traces getTimer and running it at different frame rates. The intervals will vary in accuracy depending on the framerate used for the swf.

Generally, onEnterFrame is ideal as it runs synchronously with the refresh rate of the swf. For movement of objects, for example, you would want that - their movement to correlate to when the screen is able to display those movements. setInterval is better for timing outside the reliance of the frame rate and for things not depending on screen refresh. This also usually includes operations that you would want spaced out over a longer period of time compared to that offered by the frame rate and, given its nature, nothing that needs to be all that accurate. For accuracy, I think the best way you can go is onEnterFrame with getTimer. Since the player isnt refreshing faster than the frame rate anyway, getTimer can be checked every frame and you can have your event occur on the frame closest to the time needed as comparable to the system time by which getTimer is based.