Thread: Decoupling animations from timers

  1. #1
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001

    Decoupling animations from timers

    How do most of you render your animations? Do you use the timer for the animation within the animation class or do you decouple them?

  2. #2
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    I'd say avoid hard coding the timer in the animation class. Make a timer object a parameter and the animation can have default or something.

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Well what I have so far is a very scaled down version of what I've normally seen.

    Initially I had this complex timer class but then thought about it. All I need is a start time and an ending time to determine duration. So instead of passing the millis in from my other code, each timer handles it.

    1. Sets m_IsRunning to true
    2. Gets current tick count and saves in m_StartTime

    1. If timer is running:
    2. Gets current tick count and saves in EndTime
    3. Computes diff time and multiplies by 0.001f (GetTickCount() resolution)
    4. Returns diff time
    5. Sets StartTime to GetTickCount()

    1. Grabs current frame from animation using m_AnimID which indexes into AnimMgr vector
    2. Sets texture according to animation object texture ID
    3. Grabs texture from TexMgr class using value from animation object as texture ID
    4. Optionally scales, rotates, etc.
    5. Renders.

    Threaded class
    1. Starts timer
    2. Sets m_IsPlaying to true

    1. Calls Timer::Elapsed to get interval since Timer::Start() was called
    2. Computes FrameAdvance (FrameAdvance = m_MSPerFrame / elapsed)
    3. Increments current frame by FrameAdvance and wraps if needed

    Since animation classes never touch the primary buffer it is easy to multi-thread them. The sprite class is the only thing that renders and relies on an animation object which then relies on a timer object. All animations and timers are stored in their respective containers. In essence my animation class is just incrementing an index into a vector that contains the actual texture IDs. This is a very lightweight thread process.

    So the class architecture is:






    Any pitfalls I'm missing here?
    Last edited by VirtualAce; 12-08-2007 at 10:33 AM.

  4. #4
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Well here is the final result with some modifications to the original design.
    Last edited by VirtualAce; 03-12-2011 at 11:41 AM.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Don't games usually keep a single, global time, and thus a time delta since the last frame? I'd base my animation on that.
    All the buzzt!

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    I don't know how most games do it but in mine each sprite is passed fTimeDelta in it's update function. Sprite animations are essentially nice neat collections of images with frames per second info and millis per frame info. Other than that they contain no timer information. That is relative to the sprite. This allows me to load animations into memory once and use them as many times as I need.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. timers in c
    By steve1_rm in forum C Programming
    Replies: 10
    Last Post: 02-24-2009, 12:34 PM
  2. Threads and Timers
    By scioner in forum C Programming
    Replies: 8
    Last Post: 03-22-2008, 07:56 AM
  3. switch cases and timers
    By soranz in forum C++ Programming
    Replies: 5
    Last Post: 10-02-2005, 06:43 PM
  4. Timers, Timers, Timers!
    By Stan100 in forum Game Programming
    Replies: 9
    Last Post: 01-24-2003, 04:45 PM
  5. Timers
    By Mox in forum Windows Programming
    Replies: 2
    Last Post: 11-09-2001, 04:34 AM