Thread: U,V animation or not?

I'm still debating my animation algo as to whether or not I should change it.

Originally I used 1 ID for 1 frame of animation or 1 texture. Ideally I would like to simply scroll u,v's but that presents another problem. In order to scroll u,v coords I must lock the vertex buffer and write the new u,v coords to the buffer and then unlock it. However using U,V animation techniques allows me to reduce the number of SetTexture() calls while increasing the number of vertex buffer locks and unlocks. Catch 22 it seems.

Code:

class CAnimFrame
{
  protected:
   DWORD m_dwTextureID;

   float m_fUCoord;
   float m_fVCoord;
   float m_fUSize;
   float m_fVSize;

   ....
};

So now instead of just having an ID, I have 1 ID to indicate which texture to use and 4 floats to determine where in that image (maintained by the texture manager) the current animation sequence is.

So I guess my question is which is faster?

UV animation

• Requires locking/unlocking vertex buffers
• Reduces the number of SetTexture() calls
• Reduces the memory footprint of textures since many animations can be stored in one large texture

Single image animation

• Increases the number of SetTexture() calls
• Does not require locking/unlocking of vertex buffers
• Increases the memory footprint of textures

Haven't you been doing some sick nasty stuff with shaders? A shader that alter's uv's is cake.

Eh....I guess I could use a shader for animation. But then where's the proper fallback for earlier hardware? Course I reckon this space game won't run on anything that does not at least support shader model 1.0