4 Replies Latest reply on Feb 19, 2009 2:39 AM by blake_

    FrameRate vs. Timers

    blake_
      I'm used to, well, non-Flash-derived environments and so certain things that Flex has are anomalous to me. I'm trying to build a game (and adapting to the absence of threads) and trying to figure out how to time the animations.

      Normally I'd put the logic and game engine in a separate thread that would sync up every hundredth of a second or so using a timer. But Flex has this FrameRate thing and the EnterFrame event. I notice that it's common for Flash/Flex games to work off of that, and use the timer to figure out the elapsed time between frames.

      I guess it doesn't matter much, except that it seems to me that if I'm only rendering the screen when it matters--i.e., when a frame needs to be output--that makes more sense than going off an arbitrary timer that isn't related to screen refresh rates.

      Anyone know what's going on under the covers well enough to put me a clue?
        • 1. Re: FrameRate vs. Timers
          Level 7

          "blake_" <webforumsuser@macromedia.com> wrote in message
          news:gnbe2d$dlb$1@forums.macromedia.com...
          > I'm used to, well, non-Flash-derived environments and so certain
          > things
          > that Flex has are anomalous to me. I'm trying to build a game (and
          > adapting to
          > the absence of threads) and trying to figure out how to time the
          > animations.
          >
          > Normally I'd put the logic and game engine in a separate thread that would
          > sync up every hundredth of a second or so using a timer. But Flex has this
          > FrameRate thing and the EnterFrame event. I notice that it's common for
          > Flash/Flex games to work off of that, and use the timer to figure out the
          > elapsed time between frames.
          >
          > I guess it doesn't matter much, except that it seems to me that if I'm
          > only
          > rendering the screen when it matters--i.e., when a frame needs to be
          > output--that makes more sense than going off an arbitrary timer that isn't
          > related to screen refresh rates.
          >
          > Anyone know what's going on under the covers well enough to put me a clue?

          You need to understand the Flex invalidation model. Look in the help under
          commitProperties or updateDisplayList.


          • 2. Re: FrameRate vs. Timers
            blake_ Level 1
            Well, I read everything I could find on commitProperties and updateDisplayList (though I didn't find dedicated entries for them in the local help) and I don't quite see how it relates to my question, except tangentially. It seems like the actual updates are still governed by the frame rate. (Which perhaps does answer my question, i.e., that no matter what frame rate is the controlling factor.)
            • 3. Re: FrameRate vs. Timers
              Level 7

              "blake_" <webforumsuser@macromedia.com> wrote in message
              news:gne17l$mi4$1@forums.macromedia.com...
              > Well, I read everything I could find on commitProperties and
              > updateDisplayList
              > (though I didn't find dedicated entries for them in the local help) and I
              > don't
              > quite see how it relates to my question, except tangentially. It seems
              > like the
              > actual updates are still governed by the frame rate. (Which perhaps does
              > answer
              > my question, i.e., that no matter what frame rate is the controlling
              > factor.)

              This is true, but when you use the invalidation model, then you only update
              the screen when necessary, which I thought was what you were asking...?


              • 4. Re: FrameRate vs. Timers
                blake_ Level 1
                quote:

                Originally posted by: Newsgroup User
                This is true, but when you use the invalidation model, then you only update
                the screen when necessary, which I thought was what you were asking...?



                No, not really, though that was interesting. I was asking about the relative usefulness of timer events versus enterFrame, particularly in designing a real-time game. In a regular office app or a turn-based type game, you update the application state, and how and when the repaint occurs is of minimal concern. In a "real-time" type game, you have to balance your game logic against a constantly refreshing play field.

                I've just opted for using enterFrame for now.