Animation in SDL

I'm doing it like this: I've got a sprite sheet with 6 frames of a dude walking. I take an SDL_Rect and use it "cut" the frames out of the image and display them one after the other. Couldn't sound simpler and when I got it working and saw how ridiculously quickly he was animating I thought "that's ok, I'll fix it in a minute".

6 hours later and I've still got it wanked.

For the life of me I can't figure it out. Each object has a HandleInput() function which takes one arg, the time difference between the last frame and the current one. I'm using this value to move but I've got no idea how to use it to get my animation to sync (or whatever).

Here's my HandleInput for the said sprite:

Code:

---

void TL_Vamp::HandleInput(int dT)
{
    _sendableMessage._id = M_MOVE;
    _sendableMessage._arg1 = MOVE_LEFT;
    _sendableMessage._arg2 = dT;

    if (InputHandler::GetSingleton().KeyStillDown(SDLK_d)) {
        _currentFrame++;
        _srcRect.x += 55;

        if (_currentFrame >= 6) {
            _currentFrame = 0;
            _srcRect.x = 0;
        }

        if (canMoveForward) {
            _dstRect.x += dT;
        }

        if (_dstRect.x > (GameSystem::GetScreenWidth() / 2) - 55) {
            GameSystem::FireMessage(&_sendableMessage, GameSystem::GetObjectByName(std::string("TL_Background")));
            canMoveForward = false;
        }

        canMoveBack = true;
    }

    if (InputHandler::GetSingleton().KeyStillDown(SDLK_a)) {
        if (canMoveBack) _dstRect.x -= 2;
        if (_dstRect.x < 20) canMoveBack = false;

        canMoveForward = true;
    }
}

---

Just ignore everything else for now.
Everything I find online is about as clear as mud to me and my humble -Z in mathematics.

Maybe, this will help? Here

Nope I've been reading that over and over all day, I can't see how he's doing it.
Explain it to me like you're talking to a 12 year old :)

Can't you do something like:

Code:

---

if (dT>=250) //in ms?
  _currentFrame++; //change frame every ~1/4 second

---

Maybe I don't understand the problem :confused:

I've output dT every frame and it's always 13. Here's how I've calculated it:

Code:

---

Uint32 lastTime = 0, thisTime = SDL_GetTicks(), dT = 0;

// Once each frame
lastTime = thisTime;
thisTime = SDL_GetTicks();
dT = thisTime - lastTime;

---

EDIT: I'm a turd. :(

Dump the SDL ticks and use GetTickCount() from Win32

Done.
Now what?


I hate animation.

There's no point in exchanging SDL_GetTicks() for GetTickCount().

SDL_GetTicks() will automatically decide which is the best to use: GetTickCount(), QueryPerformanceTimer() or timeGetTime().

Oh ok.
But how do I actually use this dT to... get animations to... work....

?

God damn I sound like a retard, I know. It's probably obvious to everyone else (hence the plethora of replies focused on the thing that is the least of my worries) but I've spent more time on this than I had thought.

Bugger it. Maybe game programming isn't my thing. Well it is - it's more interesting than programming other things but getting stuck on a problem like this is so kick you in the crotch spit on your neck painful.

I'm not sure, I'm definetly not a pro but maybe it would help to add somewhere in the code a sleep function, maybe for 1000ms?
I haven't used c++ so much but it works fine in my animations in Java.
Like this;

Code:

---

while(){
sleep(1000);
}

---

Not sure if it works

Code:

---

void TL_Vamp::HandleInput(int dT)
{
    _sendableMessage._id = M_MOVE;
    _sendableMessage._arg1 = MOVE_LEFT;
    _sendableMessage._arg2 = dT;

    if (InputHandler::GetSingleton().KeyStillDown(SDLK_d)  ) {
        _currentFrame++;
        _srcRect.x += 55;
        // I've been calling SDL_Delay(1000) here but ...

        if (_currentFrame >= 6) {
            _currentFrame = 0;
            _srcRect.x = 0;
        }

        if (canMoveForward) {
            _dstRect.x += dT;
        }

        if (_dstRect.x > (GameSystem::GetScreenWidth() / 2) - 55) {
            GameSystem::FireMessage(&_sendableMessage, GameSystem::GetObjectByName(std::string("TL_Background")));
            canMoveForward = false;
        }

        canMoveBack = true;
    }

    if (InputHandler::GetSingleton().KeyStillDown(SDLK_a)  ) {
        if (canMoveBack) _dstRect.x -= 2;
        if (_dstRect.x < 20) canMoveBack = false;

        canMoveForward = true;
    }
}

---

... it slows the whole damn game down and makes it all jittery.

I suppose you could keep a static variable in your function:

Code:

---

void TL_Vamp::HandleInput(int dT)
{
  static int timeElapsed = 0;
  timeElapsed += dT;
  //...
  if (timeElapsed>=250)
 {
  _currentFrame++;
  timeElapsed = 0;
  }
  //...
}

---

Which is what I really meant before...

Quote:

---

Originally Posted by ahluka

Oh ok.
But how do I actually use this dT to... get animations to... work....
.

---

I don't really have a lot of animation in my game, but here's
how I handled the one thing I do have

Code:

---

void cl_BoyTorso::Update()
{
        const float UpdateInterval = 0.20f; //update 5times / second
        static double SecondsSinceLastUpdate = 0;

        if(SecondsSinceLastUpdate >= UpdateInterval)
        {
                //unimportant code that decides the CurrentFrame

                SecondsSinceLastUpdate = 0;
                UpdateState = CurrentFrame;
        }
        else
        {
                SecondsSinceLastUpdate += cl_Clock::Global().GetDeltaTime();
        }
}

---

Just add keep adding dt to a variable until it's above the
interval you want between frames.

//edit: Which is pretty much exactly what Jawib said while I
was replying. :D

Thanks guys :)





*manly hugs and kisses*

EDIT: Collision detection is the next thing I'm not looking forward to. I know how to do it just not when to do it. I guess the best idea would be to define an SDL_Rect the same dimensions as the screen, then check when an enemy is inside it. If he is then also check for his collisions (about the only thing they'll collide with is the player). Would that be "ok" for a side scroller?

Don't tell me I have to do all this BSP-type crapola...

>Don't tell me I have to do all this BSP-type crapola...

You only need that if its too computationally expensive to check for a collision between everything and everything else. In a simple 2D side scroller haveing a bounding box around collidables and checking for one box intersecting with another should be just fine.

I'm just using BSP's in 3d. I didn't even know you could use them in 2d!?! ;)

Of course you can. AFAIK it's just splitting up a large area into a tree.
I don't fully understand it but I guess you can apply it to 2D.

Quote:

---

I don't fully understand it but I guess you can apply it to 2D.

---

Sorta like, oh, I dunno, DOOM?

Oh yeah.
DOOM used raycasting right? I was reading an article about that and Wolf3D the other day.

EDIT: That being raycasting and I know it has nothing to do with BSP. Meh.

Animation is just changing textures in a quad at a certain rate. That SDL code looks hideous compared to actually just using ID3DXSprite or coding your own.

What you need:

CAnimFrame - a class to wrap one frame of animation
CAnimSeq - a class to wrap one full sequence

Each CAnimSeq resides in an array. You will need an object factory of sorts that can return a new instance of CAnimSeq so you can have as many objects using the same animation as you want and yet they won't conflict. Your animations act as a template that can be used anywhere in the game and on any poly, be it a quad, triangle, or something else.

Hopefully that might break it down better for you.

I use a system of ID's where the ID represent the index into the array for CAnimFrame's and for CAnimSeq's. If you take this approach animation can be done like this:

Code:

---

void CAnimSeq::Update(float fTimeDelta)
{
  m_fTimeElapsed+=fTimeDelta;

  int iNumFramesToAdvance=static_cast<int>(m_fTimeElapsed/m_fFrameTime);

  m_iCurrentFrame+=iNumFramesToAdvance;

  if (m_iCurrentFrame>m_iMaxFrames)
  {
    if (m_bLooping)
    {
        m_iCurrentFrame-=m_iMaxFrames;
    } else m_bActive=0;
  }
}

void CAnimSeq::Render(void)
{
  ...
  if (!m_bActive) return;

  DWORD dwTextureID=m_pFrames[m_iCurrentFrame];

  m_pDevice->SetTexture(m_pTextureMgr->GetTexture(dwTextureID));
  ...
  //Draw the quad
}

---

Not sure about the data type cast there and haven't tested this as is, but I'm sure you can figure that part out.

Now if you want to make the textures accessible w/o having to call the texture manager then just use a method by which you get pointers to them (CAnimFrame's), and/or their actual textures (IDirect3DTexture9) at run-time. Then instead of calling texture manager you just do an array access inside of your render and it should work. So keep and array like this:

Code:

---

...
 IDirect3DTexture9 *m_pFrameImages;

---

You can also bypass CAnimFrame since it's really just an ID in the texture manager's array, but you may want to keep it around to add functionality to frames later on.

I'm not sure what SDL is doing there, but according to that website, it's more of a hassle than just coding your own in pure D3D.

Also, GetTickCount() seems to work just fine for me but I've also used QueryPerformanceCounter().

I'll give you the vertex structure you will need for simple textured quad's with color support at the vertices.

Code:

---

//MSVC 6 style
#ifndef AnimVertex_h
#define AnimVertex_h

#include "d3dx9.h"

#define AnimVertexFVF D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_TEX1;

struct AnimVertex
{
  D3DXVECTOR3  Pos;
  float RHW;
  D3DXCOLOR Diffuse;
  float u,v;

  AnimVertex(float x,float y,float z, D3DXCOLOR _diffuse,float _u,float _v):Pos(&D3DXVECTOR3(x,y,z)),RHW(1.0f),Diffuse(_diffuse),
u(_u),v(_v) { }

  AnimVertex(void):Pos(&D3DXVECTOR3(0.0f,0.0f,0.0f)),RHW(1.0f),Diffuse(0),u(0.0f),v(0.0f) { }
};

#endif

---

Use #pragma once for MSVC .NET 2005 instead of that #ifndef gobbly gook.

Thankies.

The way I'm doing it in SDL isn't that bad but I don't really like it either. I load the animation sheet into a surface then move an SDL_Rect across it in increments equal to the width of each frame.

I'm going to drop SDL starting from today and start over with D3D.

Then I can use DirectInput too, which I like but it has problems with SDL (or SDL has problems with DI). SDL input is really crappy.

Quote:

---

Originally Posted by ahluka

Oh yeah.
DOOM used raycasting right? I was reading an article about that and Wolf3D the other day.

EDIT: That being raycasting and I know it has nothing to do with BSP. Meh.

---

Wolf3d used Raycasting. Doom didn't. As far as I
know, anyway. I could be wrong.

Apparently DOOM did but the engine is more advanced, allowing for different height walls of arbitary shape.

DOOM used heightmap based raycasting but it was still raycasting. More like voxels than anything, but not true voxels. It heightmapped walls to produce layers and the did floor and sky mapping to fill in the gaps between the heights. This is how they got steps in the floor or indentations in the floor. Notice in DOOM when you look up or down the view really begins to fall apart.

The only complete 3D 6 DOF heightmapped engines I've seen are from Novalogic's Delta Force 1, 2; Armored Fist 1,2; and Comanche 1,2. How they got 6 DOF in a heightmapped voxel engine is beyond me. They probably made use of vertical ray coherence as well as a host of other tricks to get it to look right. But it does look right and it looked good for the day it was made in. Outcast tried to do this type of engine but in my opinion failed as it's framerates are not good, visuals don't look nearly as good as Novalogic's, and it's res is limited to a very odd size.

I believe Descent 1 was raycasted but I'm not sure of the method. Dark Forces 1 from LucasArts was also raycasted using a more DOOM-like technology. The non-ortho raycasting is done via line-segments representing walls and doing a ray to line intersection test. The BSP is used to weed out all of the lines in the world that are not in the frustum. Otherwise the thing would crawl.

It's a simple test by taking 2 equations of a line, making them equal to each other, eliminating knowns since you have 2 unknowns (can eliminate x or y depending on casting type since you know the cellsize of your world), and solving the equation both for x and y. You can also raycast using tangents.

Gamedev has a paper about non-ortho raycasting.