Enter Frame vs. Timer

Better or more efficient to use a timer listener and an enter frame listener, or to have just an enter frame listener and a variable that stores the number of frames till next use.

An example is that you always shoot every second. Is it better to use a timer event listener to shoot, or to encorportate it with the enter frame listener and skip the timer event listener?

In general, you want everything to be based on the same system. Either have all events based on time elapsed, or all events based on number of frames. Don’t have a mix.

If there is a performance difference, it’s so minimal as to not be worth worrying about.

I personally base it not on performace, but on which seems more fair.

In a fast paced action game, where reactions are what matters, I would go for the timer way, so people cannot lag their computer in order to have it easier. However, in games where it does not matter too much, I would rather go with the enterframe, so people on slower computers don’t suffer too much.

I am still new to do this but actually gave this some thought in my own design. I actually use both Timers and enter frames. My thinking is this, a Timer event is used when you want something to happen at a certain interval of time. A frame event happens on every frame refresh of the screen which is NOT based on time. What I mean by this is that even though you typically don’t the frame rate is NOT a measurement of time and can be changed by a programmer at any point. So, I don’t think of it as (there are 20 frames per second so therefore one frame represents a 5 milliseconds). Utilizing the thought pattern that I have no idea how many frames per second seemed to make me design better. So, if I am doing a task that needs to happen on frame refresh such as drawing something then I do it there. If I have something that I need to happen over a set interval of time then I use a timer event.

SImple EG:
I have a gun that fires every 1 second. So I create a timer even that sets a flag canFire at 1000 milliseconds. And then in the frame event if canFire is turned on I turn it off and instantiate the bullet in the correct spot.

Sounds like a pain because I am relying on two events but I am seperating my logic for when I can fire and when the screen will draw the bullet itself. Actually kind of poor example because most obvious critisicm here is that my bullet actually won’t fire every second it will be allowed to fire every second but only actually fire once the frame reeappears after the second causing a slight delay. I was just trying to come up with something that incoroporates both. However, if there is something that isn’t time based but should be redrawn on every frame then I use a frame events. Something on time I use time events. In general most things make more sense with timer events especially if you don’t want to clutter you frame event.

I prefer frames. I’ve got two problems with timers:

1) If your game gets lagged, the timers keep on going. So your player can can killed in the game while the screen is frozen. How annoying is it when that happens?

2) If your frames and timers are out of sync, you can get an unpleasant juddering effect. I had a timer counting down seconds with one decimal place in a game I wrote. At 24 frames/sec the last digit on the timer stopped on some numbers noticeably longer than others, and it was painful to watch.

That said, it’s all down to your personal coding preferences and they’re both usable.

Dark Orbit was a good example of the situations created by splitting the timing method.

Shooting your cannon was frame limited
Enemy spawns were time limited

A ton of folks had a really hard time getting the hard badge, and couldn’t figure out why. Dropping the quality made it much easier to play, as you were getting more shots off per each enemy wave. It didn’t appear to be lagging at higher quality, but the proof was in the pudding. Lowering the quality got you the badge.

Okay so I think the way I do stuff is different from any answer here.

First of, like BigBen said, don’t mix the two approaches unless you know what you’re doing.
Second, don’t base the timing of your games on frames. Thats the worst thing you can do. If you do it you’re making life harder for players with slower computers as they can’t play the game in the original speed.
But, don’t get me wrong, use the ENTER_FRAME event. I know this may sound a little paradoxal but hear me out:
Make a singleton class that handles time. This is the only class that listens to the ENTER_FRAME event. Next thing you do is make it boradcast a tick event when it handles an ENTER_FRAME event, using the time elapsed since the last event as a parameter of the tick event. This could be done using the function flash.utils.getTimer().
Now all classes should listen to this tick event to perform their jobs. All movement etc should be done based on the time elapsed, given on the event parameter.

This solution keeps your game time-based using frames and lets you do neat things such as changing the game speed. Say the time elapsed since the last frame appeared was 1 second. You can build the time event with 0.5 as the parameter and your game will be slowed down by a half. It’s nice for some effects.

How would I solve that delay problem about the fire rate on one of the first posts?
For that we would just need two simple functions on that singleton class, a getTimeStamp() and a timeElapsedSince(timestamp). That way, after catching a LEFT_CLICK event, if the time elapsed since the last shot was higher than the fire rate, then shoot. It could be implemented with an uint.

what bLasT suggest can still be done with just a timer and no enter_frame… you just have to updateAfterEvent(). And it looks prettier that way too.

But I personally still like using frames, unless the game really depends on the timer. Otherwise, like CuriousGaming says, sometimes the browser just likes to lag, and during the lag you can just die.

and hehe I was the one to find that problem in dark orbit :)

Originally posted by jonathanasdf:

and hehe I was the one to find that problem in dark orbit :)

Thanks for that then, I couldn’t get the badge and it drove me nuts till I heard.

what bLasT suggest can still be done with just a timer and no enter_frame

Whatever pleases you. You couldn’t handle “asynchronous” events tho, unless you had multiple timers. And multiple timers suck.
Edit: actually you could. Like I said, whatever pleases you.