Hello. I dont know if this is the correct forum for this question but my game is a tile game and this question would be encoutered in some form in most tile games (i assume), so... I''m at the point in the scrolling shooter (2D) I''m making in C++ where I need to store the rects for alien animations(ie different animations for different enemies). My list of enemies is stored in a linked list which is looped through. I want to use an integer identifier for differnt alien types. For each enemy to be displayed I want to access the animation currently being performed (different Number of animations for each Alien type) and the frame that needs to be drawn, or a rect on the offscreen surface. (different number of frames for each animation). I can''t think of a data structure that will enable me to do this efficently. All the values of the rects can be given in the code (ie I shouldn''t need dynamic allocation). At first I thought of a 3dimensional array but with the last 2 dimensions being variable (ie undeclared). Is this possible (i can''t get it to work)? Has anyone got any ideas? How do most people handle referencing the different frames of badguys (ie in comercial games)? Anything at all anyone at all has to say on the topic would be good.

I am going to have to do the same thing too, and was going to use adjacent arrays, but adjacent arrays are messy.
Instead, just create a structure to keep all the information about each frame you need and create an array of them.

typedef struct{ int x,y; int width, height; int nextframe;}frame;frame frames[NUM_FRAMES];

Each alien type could have its own array of frames, or you could have a 2-d array of frames

frame frames[NUM_ALIENS][NUM_FRAMES];

Just try and build on that.

Ok this could get messy and long, just to warn you.

Here is what I'm doing (and it's working nicely). Let's use your example of an alien. Firstly I have something I call a drawable. An alien is an example of a drawable, a box is, the superhero is, the background is, etc. Everything that can be drawn is a drawable. Intrinsicaly anything that will be drawn to the screen is a drawable.

From a high level what happens is we have an array of all the drawables in the game and we cycle through the array calling each drawable's draw function. I'll leave image position data up to you to figure out.

Now each drawable has what's called animation sets. Actually it has one or more animation sets. The animation set is nothing more than a container for animations cell indices (indices referencing individual pictures.) When we talk about a cell not being animated we are talking about an animation set with only one animation cell.

A drawable object can have multiple animation sets because we may have multiple animations for each character. A jumping animation, a running one, a walking one, etc. This means that the drawable needs to keep track of what state it is in. Now if we had a separate array of program data that managed drawing states and pointed to their drawables we could do one pass through that array where these objects updated their drawables doing things such as telling them that they are now running instead of jumping. Then after the updates have been made we'd make the drawing pass through the drawable array.

The animation set is an object that contains a list of global cell indices that refer to the actual bitmaps in memory as well as an indicator of whether the animation set is in use. This way multiple animation sets can share the same images but retain their own "during animation" position information. You could actually have the drawables share animation sets but then your character's would share the same movements at the same time.

Now here comes the complex part. Each animation set registers itself (a IncrementAnimationCellNumber callback function) with an animation clock that continually runs in its own thread watching the system clock. This animation clock with notify, via this callback function, the animation set that it needs to switch which cell is to be drawn. Each animation set is then free to request different frequencies of notification. It should be noted that the animation set can turn off notifies as well and in fact this should be done if the animation is not currently being used.

Note: with this method your animations will have skips in them if your frame rate drops. You can add something to your clock and animation set to ensure that you don't skip cells.

Now what happens when the drawable calls its draw function is it asks the animation set that it is currently drawing or is going to draw what animation cell it should draw (remember the global indices?) The animation set returns the global image cell index value. Then the drawable draws that image in the location that it wants it.

Now you should be able to implement this because I do and it is working fine. What I actually do is add another layer of complexity. What I am doing is actually drawing animations as textures onto polygons. OpenGL has a texture mechanism that will store texture objects in memory so this is where my global image cell array is located. So my Animation sets actually return index's to texture objects. Then I bind the texture to the tile I want and vioala. It's working beautifully up to now. We'll see what happens once I add the clock. I don't forsee any problems.

While I'm not "In the industry", I am a professional programmer and I am working on a game on the side and this is the route I am taking. With this mechanism drawing animations for buttons is the same as drawing the animations for ships in tiles is the same as drawing text in a window.

Another issue from way above. I don't have to worry about conserving video space in memory and making things contiguos because OpenGL handles that in it's texture objects but I do have to watch my texture memory usage. I think these are acceptable tradeoffs.

One thing I didn't mention is how to handle the list of drawables. You aren't always going to tell all the drawbles to draw. This is up to you to figure out. I have my own way but it adds even more bloat. Basically it comes down to everything that is drawable is actually a window in a tree. It gets messy.

Hope this has been a help. It's probably too technical but you asked what would be done in a commercial situation and were my game commercial (maybe if we get it done it will be one day) this is what I'd do and am doing. And no, there doesn't seem to be a performance hit running on my 333 celeron with 128 megs ram. It redraws fine using double buffering.

RandomTask

Edited by - RandomTask on February 8, 2001 1:23:00 AM

RandomTask has done a thorough job of organizing stuff in talking to the next level. You''ll have to sitr down with a piece of paper and work it out.

One thing that didn''t come up was duplicate images. Let''s say you''ve got a dozen orcs attacking. You would only need one set of images.

What I do is give in each orc the same list of frames but stores in the orc data the current position.

ZoomBoy
Developing a iso-tile 2D RPG with skills, weapons, and adventure.
See my old Hex-Tile RPG GAME, character editor, diary, 3D Art resources at
Check out my web-site

Thanks for your replies, I sussed it out in the end. Thanks random task, your advice was by no means too technical and although implimenting your method would have involved rewriting much of my original code, I''m gonna keep it in mind for my next game, I''m planning it already!) Thanx.