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?
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?
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.
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.
Timer::Start()
1. Sets m_IsRunning to true
2. Gets current tick count and saves in m_StartTime
Timer::Elapsed()
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()
Sprite::Render()
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
Anim::Play
1. Starts timer
2. Sets m_IsPlaying to true
Anim::Update()
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:
-ITimer
--TimerImpl
-IAnim
--AnimImpl
-IAnimMgr
--AnimMgrImpl
-ISprite
--SpriteImpl
-ITexMgr
--TexMgrImpl
Any pitfalls I'm missing here?
Last edited by VirtualAce; 12-08-2007 at 10:33 AM.
Well here is the final result with some modifications to the original design.
Last edited by VirtualAce; 03-12-2011 at 11:41 AM.
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!
CornedBee
"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
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.