Nothing wrong with A5's sub bitmaps I guess,the performance loss is minimal i too, it's just that an extra data structure is needed to hold positions and size.

I thought a lot about offsets before, and i think it could be completely eliminated, the sprite should be placed on the frame including the offset. This is how it's generally done I believe, (but of course this wastes the most space).

Otherwise, again the loader could generate the offsets too and place it in the .ani,then the problem is solved again. (I have not yet figured out how to mark the offsets in the frames though...)

Ok...if we wANT to use sprite offset data, basically we will probably need a hard set magic color for the background I'm afraid, unless I come up something better. I will think about this...

Anyways to understand how the loader/.ani-generator works, just assume that it can generate offsets and position and frame count for the .ani and it can remove the unwanted pixels from the input bitmap to save some space too.)

That's what I thought. So using the big bitmap as the source would be better?
(just wanting to make sure i understood correctly)

I already have a data structure which contains the frametimes. Adding the offset data would be no problem. Not is size nor in performance.

If we want to support animations with different frame sizes we have no choice.
We have to use offset data.

The data structure is currently used to store the frametimes of each frame. This has to be stored somewhere beacuse you can't store that into a bitmap.
The offset has to be stored as well if we want to use only the main bitmap.
A reference to the main bitmap wouldn't be enoguh because you have to know WHERE on this big bitmap the frame is located. This info needs to be stored somewhere too.
Using this solution no sub bitmaps would be created.

Some of this feature are already supported as well already.
But when I have some more time I will have a look at it. Thanks

I didn't use xml on purpose.
Using xml would require an aditional dependency.
When I started to write this I set myself the goal that this animation addon will work only with standard c and allegro 5.
No additional libs and no c++ stuff. And currently I don't think it's that bad.

Ok, new version.

New stuff:
- offsets now supported
- loading animations from one big source bitmap.
The animations can be placed anywhere in the bitmap and one frame could even be used for multiple animations.
- new draw_animation method

TODO:
- more error checking
- more drawing options

Like always, first how to use it

1) Usage

A) an animation created from multiple bitmaps
(changed a little, so showing it again)

B) Now the new bitmap

2) File formats

3) The code

Ok.. with the code in the code tags the post is too big
Will attach the files

Yea, the code in the attached source files is all thats needed do to the above things(loading, updating, drawing an animation either from multiple bmps or from one file).
So all the features I mentioned already work.

The ani file structure is not put in any structs.
The loading methods just assume that the file is in the specified format and loads the values in the specified order.

Are you speachless because you like it or because you don't like it/you expected more?

Hmmm, it seems like we are getting moved...anyways...

...I was speechless because I did not expect you've written all that already.

It looks pretty good to me so far. Some thoughts / questions:

1) Do we really need and extra struct for ANIMATION_INSTANCE? All this could fit into ANIMATION itself, or are you thinking of having different instances of the same animation? I don't see too much use of this but u tell me...

2) I would like to see some identifiers in the ANIMATION structure, like a "char *name" string & "int id". This very handy when loading or drawing animations can be referred to by their names for example. If you have multiple animations of characters on a bitmap for example. The .ani should contain these strings for each sequence so when it's loaded they'll get a nice name & id.

3) Please, please, can we not do things like this:

ANIMATION_FRAME *f = new ANIMATION_FRAME;

4) It would be nice to provide some function to load individual frames.
Maybe like so:

ALLEGRO_BITMAP* get_animation_frame(ANIMATION_SET *set, char *animation_name, int frame_index);
ANIMATION_FRAME* get_animation_frame(ANIMATION_SET *set, char *animation_name, int frame_index);
ALLEGRO_BITMAP* load_animation_frame(const char *path, char *animation_name, int frame_index);
ANIMATION_FRAME* load_animation_frame(const char *path, char *animation_name, int frame_index);

I'm working on the bitmap loader so I will post it.... It should conform to whatever you have so far.

...Nice photo's...what linux distro do you use ?

"I don't see what this would produce? It would only contain an empty animation without any data since nothing is loaded from a file (since no file was specified)"

I was trying to ask you NOT to use "new", I think you misread... Or did you not code this , it's from your animation.c ?

ANIMATION_SET* load_animation_set(const char *path)
{
  ALLEGRO_BITMAP *bitmap = al_iio_load(path);
  ANIMATION_SET *set = new ANIMATION_SET;  //<- HERE
  set->bitmap = bitmap;
  return set;
}

....;) That's funny ...ok I'm glad we are over that bump...by the way there is lot more of those in the code...

So the "name" thing is kinda neat, if let's say you wanna have a game editor, or you have a bitmap with animations of different objects. It just helps to work with them outside your program. I don't know if I'm making sense, but it's very useful

Hello dude.
Good working with animations...
I have done something like your work here with animations, and I will give you some tips about how I have done my animation class an so... (just to share).
I have done a class called spritePack, its like a class with a vector of BITMAP*...
but in each bitmap a put an offset for each sprite, and 2 fields for identification purposes, group and group_id. each frame has its group and its gorup id...
you can a name too...
I have an animation class too... this animation class is made of a vector of frames...
a frame have a group and a group_id of the sprite to display, a delay time, a mirroring stuff, and other minor effects, and an field called true id... it stores the true id of the sprite in the spritepack.
And finally we got an AnimationHandler class, it's a class that receives the animation obj and the spritePack obj...
this class have the frameOn field, and a timeOn field.
you pass the animation and the spritePack to it, so the first thing it does is to optimize the animation finding the correct indexes to each frame in the animation...
I don't know if what I'm saying here will help you, give you more ideas... but I'm trying

with this concept, you can have a obj with all your sprites and a lot of animation obj that uses a lot of sprites in this pack, you can use the same sprite a lot of time, and you will never have to allocate space for the same bitmap...

When I said vector and classes my intention was to generalize them...
you know. good work dude... perhaps[off] do you know why my game topic was closed?[/off]

Chris, I'm making the offset coding now ...I was debating whether to have negative offsets also or not, but i think for now I'm going to include it even though it makes it all a lot more complicated and it's seemingly useless. All offsets will be relative to upper left corner of the sprite's always.

Also ,I'm not sure exactly what set_pos_x in your frame struct refers to ?

I see so I guessed it right then.

(Ok, I'm eliminating negative offsets, there is really no need because their effect can always be emulated by using larger positive offsets in the frame set. Done...)

Chris, I found a small oversight in your code, you are allocating too much space for frame pointers...

Same thing later in create_animation_multi()...

Also Here this is not C:

  if (anim_instance->animation->type == ANIMATION::MULTIPLE_BITMAPS){} /* <-crime scene, this is C++*/

I got a super busy week at school, so I'm still working on the bitmap interpreter, I'm probably 50% done with it,hopefully by the end of the week it should be done.

Yes I would say get rid of enum and use #define. It's only a couple of different defines anyhow so make it an int I guess.

Thanks !

One more thingie...

for( int i = 0;... <- this is not allowed i believe either

int i; for( i = 0;... <- this is OK