quote:Original post by ZadrraS More surfaces.... My Ping-pong had 8 surfaces, is it normal to have LOTS of surfaces ? If a game is a more advanced 2D game it should have LOTS of surface if done that way you described...
A question I, too, would very much like to see answered: Allocating potentially very large numbers of surfaces (whether one deals with, say, SDL or DirectDraw) would certainly be much easier; should one go with this approach or be worried about overhead?
you dont need to use vectors to make animations. in fact, i dont see a direct reason too, but i could be wrong, i never worked with vectors yet but i understand the concept. its just a STL lib which calls new and delete for you so you can have expandable/shrinking arrays, without the hassle, correct?
anyway, i have a system similar to cone3d''s. there system seems very clever, instead of having ALL of the frames inside your main class, you make a class called SpriteBase which holds all the frames for you. then you make a pointer to this spritebase and load it into the appropriate sprite. i actually liked cone3d system a lot, it gives you full control over everything, down to how many milliseconds you want to pause for even a specific frame. its also very OOP oriented, as in, you have "sprites", which have bases. i dunno, i can just visualize that system all in my head, like you have "sprites" which have sets of frames, i thought it was a good system.
im not using it, though. well, i did something similar. i have a Base class for all of my Entities, this base loads in all the frames for a specific entity. i only hard-coded the loading of the frames into SpriteBase, instead of reading in a file. the file reading system is much more easier to work with/ less sloppy, but i havent quite grasped how to read/write to files, and i dont like to copy and paste things from tutorials. you dont learn anything that way. so i hard-coded that part.
whoa, i just sort of rambled for awhile, anyway, back to helping you:
dont bother with a vector (unless you like using them, in which case this will work with either one). if you have 4 images, each a frame of a person walking, then make an array of SDL *Surface person[4]. now load in each image to each element of the array. NOW, start out by making something called int frame_count. now use SDL_GetTicks() and get the current time. after a certain number of milliseconds pass (however fast you want the person to walk) you increment frame_count. then you draw by doing
Draw(person[frame_count])
now, after x amount of milliseconds passed, the next image will be drawn. then the next, etc etc. be sure to have something like
I have a Base Class called Animation which handles all the common taks such as loading frames from files and organizing them all in order.
Each animation in the game that i have is derived from Animation class. For each animation i have, there are X number of associated image files (1 per frame), and a very simple config file that lists, in order, each image filename and the duration of play for each frame. The animation class parses the config file and loads all images as seperate SDL surfaces. Each frame is now stored in an ordered vector. There is a seperate but syncronized vector that also lists the play time for that frame. you might refer to them as:
frames[x] --> an SDL_Surface* frame of animation times[x] --> The length of time that frame plays (integer).
Each animation class has a function called Poll(int time). If the object is polled with the time, it blits the *appropriate* image for that chunk of time.
That's pretty much it. I'll leave the internals for you to figure out.
[edited by - leiavoia on March 21, 2004 5:12:05 PM]
The way i have done it is create one image file which holds all relevant info. For example, a trees.bmp would hold all of the trees, and characters.bmp would hold all of the character images. Each "line" or "row" of the bmp which holds a certain object holds the animation frame, and each frame is a standard size, maybe around 16x16 or 32x32 or something, and a standard number of frames, say around 4. so, if "[x]" is an animation frame, the image file might look like this: [1][2][3][4][5] //default sequence [1][2][3][4][5] //object two [1][2][3][4][5] //object three
Then to set up the objects in the game, you create a base class which holds an array of SDL_Rect''s which represent the current animation frame, and a function called Animate() which increments the animation based on the time. In the constructor you initialise the animation array to the first row, which is some default animation sequence. But this class does not know about any images. it just knows that there are 5 frames of animation, each of which are nXn size, and at a cetain y value, and that after n time it should increment the frame.
After all that is done, you can derive from the base class and all of your animating objects you create will have these methods and members, so all you need to do is call Animate() and it takes care of everything else. All you would need to do in the derived class is Change the poition the Animation start point (or the "y" value) and it does the rest. (Remember what animation is: changeing images based on time. so all you need to do is move through a series of images when a certain amount of time has past. The base class already does this for you though. That is why we created it.)
Since the object class doesn''t care about loading objects, it shouldn''t care about destroying them either. That functionality rests with the main application. The main app loads the image files, and tells the objects in the game where they should be looking (ie pointers)to get their render images from. Then at the end, the main app closes after destroying everything, nobody tries to access a null pointer, and everybody is happy.
What makes this system good is that it allows you to make anything in the game animate. all you would need to do is inherit from the base class and call animate from the inheriting class. Lets say for example that all of your "people" in the game animated and looked cool. But their is a problem. The water flows, the "animals" move, but the trees stand rigidly still. No movement in the leaves from wind or something. SO you inherit the base tree class from the AnimationBase, create and set the animation textures, and you are good to go. Now the trees animate.
this is kinda long. i can post some code if you like though...
------------------------------------------VOTE Patrick O'GradyWrite in Presidential CandidateThe Candidate who Cares.
