How to implement sprite animation procedurally (non OOP)
Author
I am trying to decide how I should implement my sprite data structure and functions which change the frames of the sprites animation based on its state. Currently I am using four different arrays to store the player sprites frames. Each array contains a set of frames for each of the four directions the sprite can face. The game cycles through the frames at a certain rate depending on the direction the player is facing. This works fine for the player sprite but when I add a different type of sprite that has only one array for the frames it contains and the direction states dont apply to this sprite the function which I used to change the player sprites frames obviously doesn''t work for this sprite.
I could overload the function which updates a sprites frames for each different type of sprite I will be using but this seems like a bit of a pain to me. Is there a better way to achieve this? Perhaps my sprite data structure isn''t implemented properly? Any suggestions? What is the most common way of achieving sprite animation keeping in mind that one sprite may have many sets of frames to animate depending on its state and another sprite may have only have a single set of frames? Am I approaching the problem wrong?
Have one set of functions to update teh sprites and one to render. To update you just loop through each object and update the position/state/whatever. TO render just loop though and draw everything. The update should be called by a timer or the game loop
Atleats use a class though, I can''t stand programs with a million diffrent functions for everything
Atleats use a class though, I can''t stand programs with a million diffrent functions for everything
quote by Cybertron:
so, you use lots of gotos then or perhaps write the code out every time instead of calling a function, cause I have yet to see a large program(OOP and non-OOP) without a large number of functions,
the first part of your advice was decent
quote:Atleats use a class though, I can''t stand programs with a million diffrent functions for everything
so, you use lots of gotos then or perhaps write the code out every time instead of calling a function, cause I have yet to see a large program(OOP and non-OOP) without a large number of functions,
the first part of your advice was decent
Well SORRRRYY mr. Anoymous, I was refering to C style functions, where there are a million differnt functions for each litle thing
Thats one thing I noticed, people especially like to argue about programming style
Thats one thing I noticed, people especially like to argue about programming style
Instead of using arrays to store your frames and frame times, use a linked list. Have a linked list of each frame and the length of time before updating that frame.
It''s really shoudl be a fairly obvious solution. You know each set of sprites will have different number of frames and different refresh times, so just make it dynamic.
It''s really shoudl be a fairly obvious solution. You know each set of sprites will have different number of frames and different refresh times, so just make it dynamic.
Um, and exactly how does a class make it so that you don''t have to write as many functions? Cause I use classes and I have yet to find the secret you apparently have that allows programmers to write less code.
Either way, using a linked list, he should only need two functions, one to render and one to update, and some people would probably do both in one function. He might need some different rendering functions if he''s using a mixed 3d engine but he said sprites so I''m assuming 2d.
Either way, using a linked list, he should only need two functions, one to render and one to update, and some people would probably do both in one function. He might need some different rendering functions if he''s using a mixed 3d engine but he said sprites so I''m assuming 2d.
Author
I didn't explain my problem very well in my original post so I'll try again..
I was mainly wondering what the most common way is to implement a simple sprite data structure and more specifically how the frames of the sprite are represented in the sprite data structure. My sprite data structure stores the frames of the sprite in multiple arrays depending on how many different states the sprite has. So if my sprite has a walking state it stores the frames of the sprite walking in one array and if the sprite can jump it stores the jumping frames in another array. Then when I go to animate the sprite I check which state its in like walking or jumping and I select a frame from the array which contains the frames for that state. This would work fine if all my sprites had the same set of states but they dont. For example now maybe I want to represent a glowing key sprite. The walking and jumping states dont apply to it. I'd now have to add a new state which made sense for the key and a new array to store the frames for that state. As you can see after a while my sprite structure will have so many different states and corresponding arrays of frames which match the states it will get out of hand. There must be a better way to do this! Any suggestions? What is the most common way?
[edited by - jamez on May 4, 2002 1:19:47 AM]
I was mainly wondering what the most common way is to implement a simple sprite data structure and more specifically how the frames of the sprite are represented in the sprite data structure. My sprite data structure stores the frames of the sprite in multiple arrays depending on how many different states the sprite has. So if my sprite has a walking state it stores the frames of the sprite walking in one array and if the sprite can jump it stores the jumping frames in another array. Then when I go to animate the sprite I check which state its in like walking or jumping and I select a frame from the array which contains the frames for that state. This would work fine if all my sprites had the same set of states but they dont. For example now maybe I want to represent a glowing key sprite. The walking and jumping states dont apply to it. I'd now have to add a new state which made sense for the key and a new array to store the frames for that state. As you can see after a while my sprite structure will have so many different states and corresponding arrays of frames which match the states it will get out of hand. There must be a better way to do this! Any suggestions? What is the most common way?
[edited by - jamez on May 4, 2002 1:19:47 AM]
// psudeo codestruct spriteAnim{ int ***frames; // [ANIM_TYPES][NUM_FRAMES]; int *maxFrame; //[ANIM_TYPES]; // REQUIRED so you dont overrun the // bounds int numAnimTypes; // ditto rect bound_box; // self explainitory int type; // sprite type, useful to distguish firends and foe int curframe; // current frame to draw int curtype; // type of animation running int stateflags; // things that may efefct rendering such as // blinking when invisible, if the // sprite should face left or right, etc int health; int xpos, ypos;// ... and what ever else that your sprites may require// TYPES: refers to number of different animation sets,// jumping, crounch, etc.} the precedings snippet explains a good simple way fo laying out your struct for very dynamic sprites. just make sure you also store width and height. (this assumes bound box is equal to sprite image size). you will ahve to dynamically allocate frames. // more psudeo codeframes = (int***)malloc(sizeof(int**)*NUM_ANIM_TYPES_FOR_THIS_SPRITE);frames = (int*)malloc(sizeof(int)*NUM_ANIM_TYPES_FOR_THIS_SPRITE);for(i=0; i<NUM_ANIM_TYPES_FOR_THIS_SPRITE; i++) frames[i] = (int**)malloc(sizeof(int*)*NUM_FRAMES_FOR_THIS_SET[i]);for(j=0; j<NUM_ANIM_TYPES_FOR_THIS_SPRITE; j++)for(i=0; i<NUM_FRAMES_FOR_THIS_SET[j] frames[i][j] = (int*)malloc(sizeof(int)*sprite_width*sprite_height);// deallocation is the reverse// you free() image data (frames[j])<br></font><br><font color="gray">// then you free the frames_the_set (frames)<br></font><br><font color="gray">// thne you free the types (frames)<br></font><br><font color="gray">// make sure you iterate through everythign correctly<br></font><br><font color="gray">// otherwise you will have a massive memory leak<br></font><br><font color="gray">// also dont forget to free the maxFrames array<br></font><br> <br><br><font color="blue">this</font> should work well. the renderer should now not care what type it is, since all the info required is there. plus your not wasting mmeory on data your not <font color="blue">using</font> (ie a sprite with one set of animations, will only allocate <font color="blue">for</font> that one set). you may want to <font color="blue">do</font> soem research on multidimensional arrays, <font color="blue">if</font> your not comfortable with the psudeo code. only functions that update a particular sprite type need to worry about specifics.<br><br>your renderer that actual blits sprites will basically do:<br> <br><br><font color="blue">for</font>(i=0; i<numSprites; i++)<br>{<br> <font color="gray">// yep thats it<br></font><br> blit(sprites[<font color="purple">i</font>][<font color="purple">sprite[i</font>].curtype][<font color="purple">sprite[i</font>].curframe]);<br> <font color="gray">// you can add more here like:<br></font><br> sprites[<font color="purple">i</font>].curframe++;<br> <font color="blue">if</font>(sprites[<font color="purple">i</font>].curframe>=sprites[<font color="purple">i</font>].maxFrame[<font color="purple">sprite[i</font>].curtype])<br> sprites[<font color="purple">i</font>].curframe=0;<br>}<br> </pre></DIV><!–ENDSCRIPT–><br><br>that is pretty much what you need. btw, i know you like c and all, but you should still look at OOP theory. it will help you structure problems like this a bit better.<br><br>NOTE: this theory of sprite storage applies to ALL langauges. just in c++ things are broken up differently (thanks to polymorphism), though in the end it will look something like this to the compiler.<br><br><SPAN CLASS=editedby>[edited by - a person on May 4, 2002 4:01:18 AM]</SPAN>
Author
a person,
Wow that''s a lot of indirection! I try to avoid too much indirection because I find it hard to visualize what is going on in my head. I guess there''s no avoiding it if I want to allocate everything dynamically. You''ve given me a way to implement the sprite data structure more dynamically which is what I wanted. Now for the other part that bothers me is the function which change the sprites state. I''ll still need a unique function to handle each type of sprite, correct? I was wondering if there was some way to generalize the function that updates the sprite as you''ve done with the sprite data type. By the way my sprite data structure doesn''t actually waste as much memory as my previous post suggested. I actually broke my sprite data structure into two parts the first part is the Sprite type which stores all the dimensions, timing, etc.. which is common information for every sprite in the game. Then I create a new type for each different kind of sprite I require. So for my player sprite I have a type called Player which contains the Sprite type as well as the frame buffers it requires. So the memory waste isn''t so bad but I end up with many different sprite types which I thought was kind of silly. Another problem with this method is that I''ll need a different initialization function for every different sprite as well. Then my function which updates the sprite based on its state is overridden for each sprite type I have. Your method eliminates the need for multiple types of sprites but still requires multiple functions for changing the state of the sprite. So I was wondering if this could be avoided as well?
Wow that''s a lot of indirection! I try to avoid too much indirection because I find it hard to visualize what is going on in my head. I guess there''s no avoiding it if I want to allocate everything dynamically. You''ve given me a way to implement the sprite data structure more dynamically which is what I wanted. Now for the other part that bothers me is the function which change the sprites state. I''ll still need a unique function to handle each type of sprite, correct? I was wondering if there was some way to generalize the function that updates the sprite as you''ve done with the sprite data type. By the way my sprite data structure doesn''t actually waste as much memory as my previous post suggested. I actually broke my sprite data structure into two parts the first part is the Sprite type which stores all the dimensions, timing, etc.. which is common information for every sprite in the game. Then I create a new type for each different kind of sprite I require. So for my player sprite I have a type called Player which contains the Sprite type as well as the frame buffers it requires. So the memory waste isn''t so bad but I end up with many different sprite types which I thought was kind of silly. Another problem with this method is that I''ll need a different initialization function for every different sprite as well. Then my function which updates the sprite based on its state is overridden for each sprite type I have. Your method eliminates the need for multiple types of sprites but still requires multiple functions for changing the state of the sprite. So I was wondering if this could be avoided as well?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement