In all 3 directions, the animation is 12 FPS. That I am pretty sure.
Now, if the animated speed is constant, but travels at 3 different speeds, does that mean I must have 2x more frames for north than west and 1.5x frames for north-west or do I have to reuse the frames? In the latter case though, for 2x slower (north) speed, there is no problem because it''s a complete loop. But for 1.5x slower (north-west), the animation doesn''t complete a loop. So the animation is forced to stop, and will look odd and bad. Or is that an O.K. thing to happen? What if it''s a running animation. The sprite travels relatively fast, but if it only travels a grid, he will just lift his leg and quit animating. Isn''t that odd? Is the baton touch, if you will, between sprite animation (for example, from walk to run, run to standing still, standing still to attack, etc) is allowed to be intermittent like this?
Ugh, I''m so confused. Someone help me! Please! ;(
Oh, and there''s one more thing that I would like to ask.
When I save sprites for a character in strips and save them in one big file, you need to know the size around the sprites, that you use to take the sprite from the file and load into memory. Where should I save this information? Should I have something like a sprite class and have it save this information along with all the sprites for the character? What about for tiles? They also need information like this.
Thanks for your time and support!
Help with details of sprite animation
Author
Ok, I know there are topics with similar discussions, but I''ve read most of them, and still am confused with all the details of FPS and sprite animation. The problem is that I don''t understand what I really don''t understand.
In my game, I want to use 12 FPS for all the sprite animation. So the animation is updated every 83.3333... ms. Let''s say I have a walking animation of a zombie consisting of 10 frames. I want to move him to the adjacent tile in the north-west. My tile is 64x31 pixels, isometric. When I move him, I must move him 32 pixels west and 16 pixels north. When I move him to the North, its 32 pixels north. For West, 64 pixels.
There is a big difference in the length traveled depending on the direction he chooses. Correct me if I am wrong, I''m not too sure about it -- Because the view is 2:1 isometric, the zombie must travel 2x slower in north than traveling west. 1.5x slower in north-west than in west. So 3 different speeds. At this point, I am trying to figure out *how* to animate and move the zombie in each direction. Unfortunately, this is where my brain stops working. So I have these questions, if anyone can understand what I am talking about and can answer the questions, please take the time and help me out.
In all 3 directions, the animation is 12 FPS. That I am pretty sure.
Now, if the animated speed is constant, but travels at 3 different speeds, does that mean I must have 2x more frames for north than west and 1.5x frames for north-west or do I have to reuse the frames? In the latter case though, for 2x slower (north) speed, there is no problem because it''s a complete loop. But for 1.5x slower (north-west), the animation doesn''t complete a loop. So the animation is forced to stop, and will look odd and bad. Or is that an O.K. thing to happen? What if it''s a running animation. The sprite travels relatively fast, but if it only travels a grid, he will just lift his leg and quit animating. Isn''t that odd? Is the baton touch, if you will, between sprite animation (for example, from walk to run, run to standing still, standing still to attack, etc) is allowed to be intermittent like this?
Ugh, I''m so confused. Someone help me! Please! ;(
Oh, and there''s one more thing that I would like to ask.
When I save sprites for a character in strips and save them in one big file, you need to know the size around the sprites, that you use to take the sprite from the file and load into memory. Where should I save this information? Should I have something like a sprite class and have it save this information along with all the sprites for the character? What about for tiles? They also need information like this.
Thanks for your time and support!
In all 3 directions, the animation is 12 FPS. That I am pretty sure.
Now, if the animated speed is constant, but travels at 3 different speeds, does that mean I must have 2x more frames for north than west and 1.5x frames for north-west or do I have to reuse the frames? In the latter case though, for 2x slower (north) speed, there is no problem because it''s a complete loop. But for 1.5x slower (north-west), the animation doesn''t complete a loop. So the animation is forced to stop, and will look odd and bad. Or is that an O.K. thing to happen? What if it''s a running animation. The sprite travels relatively fast, but if it only travels a grid, he will just lift his leg and quit animating. Isn''t that odd? Is the baton touch, if you will, between sprite animation (for example, from walk to run, run to standing still, standing still to attack, etc) is allowed to be intermittent like this?
Ugh, I''m so confused. Someone help me! Please! ;(
Oh, and there''s one more thing that I would like to ask.
When I save sprites for a character in strips and save them in one big file, you need to know the size around the sprites, that you use to take the sprite from the file and load into memory. Where should I save this information? Should I have something like a sprite class and have it save this information along with all the sprites for the character? What about for tiles? They also need information like this.
Thanks for your time and support!
I don''t understand your problems but you should make your animations looping manually. Also change of animations are pretty complex but you should work out one yourself so it works for your game.
However, I do have the solution to the last problem. You save such information in a text file. Say for example you have a tiletype class.
class TileType
{
int height;
int width;
string bitmapname;
LPDIRECTDRAWSURFACE7 image;
string tiletypename; //kinda optional
};
This tiletype is not actually the ''tile'' so it doesn''t have xy coordinates. So you just read in height, width, bitmapname and tiletypename from a textfile and then load the surface.
Also, this would be a good time to use a overload of the << and >> operators so that you could load and save textfiles easily.
However, I do have the solution to the last problem. You save such information in a text file. Say for example you have a tiletype class.
class TileType
{
int height;
int width;
string bitmapname;
LPDIRECTDRAWSURFACE7 image;
string tiletypename; //kinda optional
};
This tiletype is not actually the ''tile'' so it doesn''t have xy coordinates. So you just read in height, width, bitmapname and tiletypename from a textfile and then load the surface.
Also, this would be a good time to use a overload of the << and >> operators so that you could load and save textfiles easily.
I don''t understand your problems but you should make your animations looping manually. Also change of animations are pretty complex but you should work out one yourself so it works for your game.
However, I do have the solution to the last problem. You save such information in a text file. Say for example you have a tiletype class.
class TileType
{
int height;
int width;
string bitmapname;
LPDIRECTDRAWSURFACE7 image;
string tiletypename; //kinda optional
};
This tiletype is not actually the ''tile'' so it doesn''t have xy coordinates. So you just read in height, width, bitmapname and tiletypename from a textfile and then load the surface.
Also, this would be a good time to use a overload of the << and >> operators so that you could load and save textfiles easily.
However, I do have the solution to the last problem. You save such information in a text file. Say for example you have a tiletype class.
class TileType
{
int height;
int width;
string bitmapname;
LPDIRECTDRAWSURFACE7 image;
string tiletypename; //kinda optional
};
This tiletype is not actually the ''tile'' so it doesn''t have xy coordinates. So you just read in height, width, bitmapname and tiletypename from a textfile and then load the surface.
Also, this would be a good time to use a overload of the << and >> operators so that you could load and save textfiles easily.
The number of frames per direction should never change. So you have 10 frames for the east direction have 10 frames for the north east direction etc.
All you have to worry about is moving the dude the right distance. To make it easy do all your movement calculations on a flat plane. I call this real space.
Then when you draw the dude you make the transform to view space. In my system when I want to draw something I leave x as it is and divide y by 2 as I use 64 X 32 tiles.
Hope this helps.
All you have to worry about is moving the dude the right distance. To make it easy do all your movement calculations on a flat plane. I call this real space.
Then when you draw the dude you make the transform to view space. In my system when I want to draw something I leave x as it is and divide y by 2 as I use 64 X 32 tiles.
Hope this helps.
for storage of tiles and/or sprites in a single bitmap file, i use extended graphical templates.
as for your animation problem, the problem is that you are equating pixel movement with "actual" movement.
In actual movement, you are moving one unit (from one tile to another) in 12 frames. The amount of actual pixel distance can be different for each move.
When using a "standard" 64x32 iso tile, moving north or south is a vertical offset of 32 pixels, moving east or west is an horizontal offset of 64 pixels, and moving in a diagonal direction is a vertical offset or 16 and a horizontal offset of 32. If you split this up into 12 frames of animation, then moving north or south will cause y to change by 32/12 (2 2/3) pixels per frame, moving east or west will cause x to change by 64/12 (5 1/3) pixels per frame, and moving a diagonal direction will cause x to offset by 32/12 (2 2/3) and y to offset by 16/12 (1 1/3) pixels per frame.
If you plan on using integers for everything, you might want to chop down the animation frames to 8 per direction, since that will divide out more easily, or keep an array of offsets for each of the animation frames for each of the directions.
as for your animation problem, the problem is that you are equating pixel movement with "actual" movement.
In actual movement, you are moving one unit (from one tile to another) in 12 frames. The amount of actual pixel distance can be different for each move.
When using a "standard" 64x32 iso tile, moving north or south is a vertical offset of 32 pixels, moving east or west is an horizontal offset of 64 pixels, and moving in a diagonal direction is a vertical offset or 16 and a horizontal offset of 32. If you split this up into 12 frames of animation, then moving north or south will cause y to change by 32/12 (2 2/3) pixels per frame, moving east or west will cause x to change by 64/12 (5 1/3) pixels per frame, and moving a diagonal direction will cause x to offset by 32/12 (2 2/3) and y to offset by 16/12 (1 1/3) pixels per frame.
If you plan on using integers for everything, you might want to chop down the animation frames to 8 per direction, since that will divide out more easily, or keep an array of offsets for each of the animation frames for each of the directions.
Author
Thanks for the help guys,
TANS, your link was very helpful. I think I will go with the same design.
TANS, you mention a 64x32 standard iso tile with your example.
The problem is that I can''t seem to create a iso. tile of 64x32. My iso tile is 64x31. Here are the pictures:
Does this mean your calculations (32/12 (2 2/3), etc) won''t apply to my tile? Does it have to be 31/12? That makes the calculation indivisible. Should I change my tile size to 64x32?
If so, how do I create an iso tile of 64x32? I honestly can''t create a 64x32 iso tile.
Thanks!
TANS, your link was very helpful. I think I will go with the same design.
TANS, you mention a 64x32 standard iso tile with your example.
The problem is that I can''t seem to create a iso. tile of 64x32. My iso tile is 64x31. Here are the pictures:
Does this mean your calculations (32/12 (2 2/3), etc) won''t apply to my tile? Does it have to be 31/12? That makes the calculation indivisible. Should I change my tile size to 64x32?
If so, how do I create an iso tile of 64x32? I honestly can''t create a 64x32 iso tile.
Thanks!
Author
Hrm, is it correct to think that, if I want to move my character faster than 1 grid per second, it will have to travel more pixels per frame?
Let''s say I want to make my character run (2 grid per second), instead of walk (1 grid per second). Then it will be, assuming it''s a 64x32 tile, 16 FPS, 16 frames per animation:
North/South: 32 / 16 = 2 pixels vertical (1 grid per second)
64 / 16 = 4 pixels vertical (2 grid per second)
East/West: 64 / 16 = 4 pixels horizontal (1 grid per second)
128 / 16 = 8 pixels horizontal (2 grid per second)
Diagonal: 16 / 16 = 1 pixel vertical,
32 / 16 = 2 pixel horizontal (1 grid per second)
32 / 16 = 2 pixel vertical,
64 / 16 = 4 pixel horizontal (2 grid per second)
Am I right? If this is the case, the running animation will complete its loop only when the character travels 2 full grids.
If I only travel 1 grid, only half the animation will be played.
I assume this is not really a problem?
Let''s say I want to make my character run (2 grid per second), instead of walk (1 grid per second). Then it will be, assuming it''s a 64x32 tile, 16 FPS, 16 frames per animation:
North/South: 32 / 16 = 2 pixels vertical (1 grid per second)
64 / 16 = 4 pixels vertical (2 grid per second)
East/West: 64 / 16 = 4 pixels horizontal (1 grid per second)
128 / 16 = 8 pixels horizontal (2 grid per second)
Diagonal: 16 / 16 = 1 pixel vertical,
32 / 16 = 2 pixel horizontal (1 grid per second)
32 / 16 = 2 pixel vertical,
64 / 16 = 4 pixel horizontal (2 grid per second)
Am I right? If this is the case, the running animation will complete its loop only when the character travels 2 full grids.
If I only travel 1 grid, only half the animation will be played.
I assume this is not really a problem?
Well, may be the problem is with me but i don''t know what is this all about? what are these calculations and displacements and divisions? i think it''s simpler then that...
You want to make the character run? Ok, so simple:
1) Keydown(right)
2) start the sprite animation of the running event with any frame rate you like (running animation is the animation of running in place while standing still)
3) now you want to move the character with the speed you like? all you have to do is to specify the velocity you want (2 pixels for moving, 5 for jogging and 8 for running), this is for the x values similarly with the y values but with different ratios... ok...
4) Keyup()
5) stop animation.
what i mean is to keep both the frame rate for a sprite and his velocity (x,y positions in the screen) totally isolated!
did i miss anything?
You want to make the character run? Ok, so simple:
1) Keydown(right)
2) start the sprite animation of the running event with any frame rate you like
(running animation is the animation of running in place while standing still)3) now you want to move the character with the speed you like? all you have to do is to specify the velocity you want (2 pixels for moving, 5 for jogging and 8 for running), this is for the x values similarly with the y values but with different ratios... ok...
4) Keyup()
5) stop animation.
what i mean is to keep both the frame rate for a sprite and his velocity (x,y positions in the screen) totally isolated!
did i miss anything?
Even though your tile only takes up 64x31, it is indeed a standard 64x32 tile. in a standard 64x32 tile, the bottom scan line of the image is empty. The reasoning for this is that the 64x32 area has to twice the pixels of the tile itself in order to mesh properly (the tile has 1024 pixels, and a 64x32 image contains 2048, also, for y offsets you use the number 16, which is 32 divided by 2. i''ve done a WHOLE LOT of analysis on this particular tile shape, and trust me, its a 64x32 even though it only looks like its 64x31). Similarly, a 72x36 tile would look like a 72x35.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
