Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working in Flash and a few things have been brought to my attention. Below is some code I have some questions on:

addEventListener(Event.ENTER_FRAME, function(e:Event):void
    if (KEY_RIGHT)
        // Move character right
    // Etc.

stage.addEventListener(KeyboardEvent.KEY_DOWN, function(e:KeyboardEvent):void
    // Report key which is down

stage.addEventListener(KeyboardEvent.KEY_UP, function(e:KeyboardEvent):void
    // Report key which is up

I have the project configured so that it has a framerate of 60 FPS. The two questions I have on this are:

  1. What happens when it is unable to call that function every 1/60 of a second?
  2. Is this a way of processing events that need to be limited by time (ex: a ball which needs to travel to the right of the screen from the left in X seconds)? Or should it be done a different way?
share|improve this question
up vote 3 down vote accepted

About your code: I think it's funny that you use anonymous functions for event listeners, it's something I don't see that often in ActionScript (it is more common with JavaScript). You should be aware that you can run into some garbage-collection issues if you add event listeners like that (because you're no longer able to remove them later on). As long as your event listeners stay up during the whole execution time of your app, it isn't an issue though.

Regarding your questions:

  1. An update step can take longer to execute than 1/60 of a second, even if you specified the FPS to be 60. It just means it won't go above 60, but can easily drop below 60 FPS. You can test this yourself by adding some dummy loop in your event listener, something like: for(var i:int = 0; i < 1000000; i++){ var tmp:Number = 1000.0/20.0; }. The Flash runtime will use as much time as required for a frame. That means it will try to run at the specified framerate, but it won't enforce it in any way (eg. stopping execution of code). An endless loop (while(true){}) will freeze your game on the first frame...
  2. I don't understand what you mean by "limited by time"? Are you asking whether or not to use/assume a fixed or variable timestep?

Update (regarding 2.): To make an object travel some distance in a given time, you could either use a tweening-library like tweenlite or implement it yourself like this:

// initalize this with getTimer() in your constructor or init method
private var _time:Number;

// how long the sprite should be animated.. here 3.5 seconds
private var _duration:Number = 3.5;

// event listener. needs to be bound to Event.ENTER_FRAME using addEventListener
private function handleEnterFrame(evt:Event):void {
    var t:Number = getTimer();
    var elapsed:Number = (t - _time) * 0.001;
    _time = t;

    _duration -= elapsed;
    if(_duration <= 0){
         // ensure that elapsed doesn't overshoot the duration 
         elapsed += _duration;

         // remove the event listener.. this will stop executing further updates
         removeEventListener(evt.type, handleEnterFrame);

    // the sprite will travel 200 pixels per second (in the x-axis)
    // so 700 pixels in total (200 * 3.5)
    _sprite.x += 200 * elapsed;
share|improve this answer

The question you need to ask yourself is: Is the duration of this motion related to the frame rate of the final swf? In the past the only to create motion was through the timeline or enterFrame making the framerate extremely crucial. Today you can create motion independent of the framerate. You will be surprised that most swfs today are set to a standard rate that works for video or audio imports on the timeline (30 fps). I would recommend you explore: fl.transitions.Tween.

share|improve this answer

This tutorial at 8bitrocket offers a good method of maintaining smooth movement and a fairly constant framerate, for many applications this is more than necessary, but built into it is a method of changing the framerate on the fly with a great deal of precision.

share|improve this answer

This is all known as the Elastic Racetrack.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.