Do you mean so that a gif can be converted to an allegro animation?
Sounds interesting. Would have to look into the gif format though.

EDIT:

Ok. It took some time but I was busy with other things.
Today I did a first try at a loading method.

Usage now would be

...
ANIMATION* anim = load_animation("test.ani");
ANIMATION_INSTANCE* anim_instance = create_animation_instance(anim, true, true, 2.0);
...

The ani file should look like

2
bmp1.bmp
0.5
bmp2.bmp
0.5

I'm not good with file stuff, so feel free to comment on the loading method.
And currently there is NO error handling. Comments on what should be added are welcome too.

Some issues I really would like to here some comments about:

1) The line can only be 300 chars long, so if a path is passed which is longer theere would be a problem. Solutions?
Maybe:
ANIMATION* load_animation(const char *path, int max_line_length) ?

2) When using the create_.. method the user creates the bitmaps and passed them into. He would be responsible to destroy them. Or in other words: it would be wrong to destroy them in the destroy_animation method because the user may uses them for different things.
But when using the load method the load method creates the bitmaps and it would be wrong to force the user to destroy them.
Maybe a second method destroy_animation_with_bitmaps?
Or should it be forbidden to use the create methos manually? So the load method would be the only option and the destroy_animation methods destroy the bitmaps as well.

3) Because I us al_gets the file has to end with a emempy line.
This will work

frames/newline
bitmapname/newline
time/newline
bitmapname/newline
time/newline

This won't

frames/newline
bitmapname/newline
time/newline
bitmapname/newline
time

Is this a problem?

Its not going to be included in the core. It most likely wont make it into the addons directory either. But we do HIGHLY encourage 3rd party addons.

@Alianix
Loading an animation from one file is on my list. Still some things I need to plan out.
But I won't use magic colors to set the borders though.
I would just allow only frames that are all the same size, than it will be possible to load the single frames without a visible border.

I removed all al_ or ALLEGRO_ prefixes after it was said that it doesn't belong in the lib.
I just didn't edit the first post.

I have no clue though how a thid party addon would be distributed.
Any hints?

EDIT:
Btw, no comments about the 3 point in my previous post?

I have a site where I could host it.
But I think if the different addons are cluttered on many different sites it will be hard to find them and probably most people won't download them then.

I think if the addons could be found on one site (think of it as the official allegro addon repository ) it will be much easier for people to have an overview about which addons exist.

That doesn't necessary mean that ALL addons have to be accepted. The site owner or the dev team could vote for addons... Or just accept them all. Details which are only interestin if something like this should exist

Good work! A cool add-on indeed.

I also agree a central add-on website that stays up is a great idea. Indie websites for specific add-ons tend to disappear when people lose interest.

That is just silly. I whole-heartidly disagree with this mindset.

No sense losing things for no good reason. And besides, there <strike>aren't even</strike> barely any add-ons now. Why work to filter something there are none of?

Someone else might want to take over the project.

Chris,

I've long wanted to work on such an addon I mentioned earlier. Maybe we could put it together and save some time for each other hopefully. However, i think it should be flexible enough to interpret an array of bitmaps of different size, this way it will always work, whether they are the same size or not. There are situations when it's just a waste of space to have all the same size bitmaps. It does make coding it more difficult though. Let me know if u are up to sharing ideas on this.

...Could avoid multiple files and .ani file with using the memfile and zip loaders from the API.(I don't know if it's complete yet)

I guess if it has different animations on one bitmap the .ani file is justifiable, and in either case it should be able to support varying size frames for the particular animation. This could be easily implemented with some border color coding, or it could be stored in the .ani file. I prefer the use of the .ani file as little as possible. The reason is that it's easier to organize frames on a bitmap in a drawing program, and then have the loader sort it out. This gives flexibility while designing graphics. Otherwise much time will be spent on manually counting pixels and entering data into the .ani which is prone to error not to mention tedious. Let the machine do the tedious work...

All other data can be figured out from the bitmap layout.

"To be honest I dont like the bitmap border idea."

A: All pixels within the bounding square would be part of the frame like it says in my diagram.

"What colours do you want to choose for the borders then?"

A: The bounding square's two magic colors could be any colors actually, just tell the loader that the first two pixel colors in the bitmap are the magic colors.:), (and like i said all else within the square is part of the frame regardless of it being a magic color or not. I will post the code here soon if's not clear how this algorithm would work, and the good thing also is that it shows clearly the boundaries of the frames while u are editing which is nice so you can clearly see the pixel offsets of the sprites.)

"Another reason I don't like it is because the loading would be slow. Getting pixel information is not the fastest thing. So for me it is also a performance issue."

A: I don't know what you are referring to being slow. Once you load the bitmap into memory reading pixels off it would be pretty fast especially if it's a memory bitmap. Say you have a 64x64 bitmap u will read about 128 pixels before you can determine the size of the frame. I can hardly see this as a performance problem.

I'm open and flexible on the frame storing issue if you don't like it for some reason it's not a big deal, we can change that.

However I firmly against having to write an editor to save some bitmaps image just so you can have .ani., it's too much work for so little gain and there are plenty of graphics editors out there and I don't think we should need another one. Also most people want to use editors they are used to rather then having to learn another one just to make some animation frames.;)

You can use any color you want as long as it is consistent throughout the bitmap. So the color issue is not really there. Each bitmap can have it's own different border color code.
The loader would recognize that whatever colors u chose as the first two pixels are the border markers. So obviously don't use the same color for borders as your background, mainly because its hard to see the difference. From the loader's point of view it would not matter even if you chose the same colors.

It would be interesting to check if it would be faster in your method actually. Reading formatted input from a file actually takes a while. I'm not sure if it's even faster then reading some pixels from memory. We could test that i guess. But in any case I don't think you would gain or loose significant performance, maybe less then a percent.

(surely, if you have a bunch of large size frames this is not true...but we are not designing a new hd video codec here are we ...? most sprite animations are pretty small less then 100 pixels dimensions.)

I think going with the one big bitmap is the way to go for the same reasons you mentioned.
Also Usually when loading animations they will go into some bitmap_frames array. Once they are all processed in this way the containing bitmap and file could be discarded. Why would you want to load only part of your animations ?

"If you use the big bitmap how can that be discarded?"

It should not be needed since the frames will be used individually as part of a new bitmap array. Otherwise do you want to have to use sub bitmap blitting in AL5 ?

"I think your solution sounds more like creating mcuh small bitmaps out of the big bitmap and then discarding it"

Yepp that's what i was thinking... You would need an extra structure holding the position and size info with your method, then do sub bitmap drawing...I don't see why this is better...

"I also don't get how your loader works.."

I will post some code for this, but if you look at my diagram closely u can see that i use two magic colors one is the corners (1) and (0) is the border...

"I still don't get how you want to solve the offset problem without the ani file?"

You mean the offset of the sprites ?

And yes, with my method there may be some wasted space. It's hard to avoid that if you have different sized frames with either method.

Yes, I see the advantages of your method, I don't see a seamless implementation of it however, without the mentioned editor...::) Honestly I would hate to have to edit some file to enter correct pixel info and counting pixels manually.

Just had an idea !
Actually My loader code could be used to actually create an .ani file , and then the frames could be loaded with the help of the .ani or optionally maybe with the loader. Basically the loader could read the bitmap info, create an .ani file, then get rid of the borders and the magic colors. I think maybe this is the solution to avoid the editor...:) Of course the .ani file is not created at runtime but is made with a small .ani creator executable.

Like: makeani.exe input.bmp output.ani output.bmp

Is that a negative statement saying there's something wrong with sub-bitmaps in A5, or just a general question?