Jump to content
  • Advertisement
Sign in to follow this  
celf

A question about animated sprite timing

This topic is 908 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am a little mixed up about something. First of all I am trying to workout the concept of smooth animation. So after some research, I have come up with a question about something I might not have understood correctly. Please let me describe the situation first.

 

I have a walk cycle that is a spritesheet of 8 frames. This is just a walk to the right, or it can be flipped to walk to the left.

 

If I were to place the sprite on screen, let's say at coordinate x:100 y:50 and I wanted the character to move to the right lets say to x:200, then

I understand that I "can" cycle the spritesheet 100 \ 8 times which would give me 12.5 or approximately 12 repetitions. Now that would be extremely fast, so I have to pace the cycle.

 

My questions is this, I did not mention the size of the sprite, so it was a hypothetical reference. Let's say I have a sprite that needs to walk to the right and according to it's size it would take 2 cycles of the sheet. Should the sprite only appear on screen when it reaches each frame? or should the last frame stay and the sprite continue to move to the right and just cycle through it without a break? I don't have a working program, but I am guessing, that it would not flicker if there is a gap in the distance between frame changes. I would like to eventually try this with Windows GDI and also with SDL2, but I have no experience with this.

 

In the past, I created what looked like a sprite sliding from left to right and it was very troubling. It both flickered and every single pixel it moved was blurry. I don't mean tearing or rendering artifacts, I mean simply very bad motion.

 

So perhaps I have two questions. The goal is to get smooth motion in a point and click style, like the original "King's Quest I" or even similar games today. I need the motion to be comfortable for the eye, but I don't think I need high performance graphics acceleration for this.

 

What can you guys suggest, or what can you tell me about what I am trying to do. Any pointers would be great. If you have example code, that would be fine, I should be able to look at most languages as pseudo code, but my target language, that I am learning at this time is C/C++ and as I am asking, my next project is an animated sprite sheet and a left to right walk.

Share this post


Link to post
Share on other sites
Advertisement

" It both flickered and every single pixel it moved was blurry"

 

Double buffering -- you draw to the offscreen buffer and then swap them over.

 

"smooth motion in a point and click style"

 

To do this you'll need a way of expressing the "state" of a sprite; what animation frame it's on, when to change the coordinates and so on.

 

The complexity of this varies massively. In the olden days, you'd have 4 frame animations -- so every 4th frame, you check to see what keys are pressed and decide then whether the figure is still walking (keep on this sequence) or stopped (flip to the "standing facing that way" animation or flick to front-facing) or jumping (give the character a Y velocity and switch to the jump animation).

 

These days they get hugely complicated and you can use things like stacks of state objects to manage logic in more compact ways.

 

 

 

Have you considered just picking up an off-the shelf sprite engine for this? It'll save a lot of grief.

Share this post


Link to post
Share on other sites

From what I gather you're trying to time your sprites in a way that the feet don't "slide" along the ground?

 

You'll need to keep track of the time passed between frames(delta)

 

Delta can be calculated by subtracting the current system time of the previous frame from the current system time of the current frame.

 

Each frame in the animation will cover a certain range 0-25 ms, 26 -50 ms. 50 - 60 ms, ect.. You can either assume the time is uniform or assign different lengths to each frame, but keep track of the total time the animation takes to play out. In this case 60 ms (totalAnimationTime).

 

Steps:

1. Each time the sprite is updated pass in the frame delta. Keep track of the total delta time the sprite has been in the animation(deltaTotal).

2. Find the local delta (how far you're into the animation loop. (localDelta = deltaTotal % totalAnimationTime ) modulo finds the remainder.

3. If local delta is 0-25 ms render the first frame. 26-50 render the second, 50-60 ms the third, ect.

Edited by GameGeezer

Share this post


Link to post
Share on other sites

take into consideration also that the sprite cycles have to be linked, in one way or another, to the game cycles, e.g. if the game has few graphical load, you can be in need of show more than a game cycle the same image.

In order to synchronize the animation with the game you can also wait for the current vertical retrace to end, this way it runs at a constant speed, no matter the device. But nowadays with the several engines or even libraries (SDL/SFML...) that matter is mechanized

 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!