Allegro.cc - Online Community

Allegro.cc Forums » The Depot » ALLEGRO_ANIMATED_BITMAP

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
ALLEGRO_ANIMATED_BITMAP
count
Member #5,401
January 2005

Quote:

.gif Import

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.

1ANIMATION* load_animation(const char *path)
2{
3 ALLEGRO_FS_ENTRY *ani_file = al_fopen(path, "r");
4
5 char *line = (char*)malloc(300);
6 line = al_fgets(ani_file, 300, line);
7 int amount = atoi(line);
8 
9 ALLEGRO_BITMAP **bmps = (ALLEGRO_BITMAP**)malloc(amount*sizeof(ALLEGRO_BITMAP*));
10 float *times = (float*)malloc(amount*sizeof(float));
11 
12 
13 int i = 0;
14 while(line!=NULL)
15 {
16 line = al_fgets(ani_file, 300, line);
17 if (line!=NULL)
18 {
19 char *filename = line;
20 bmps<i> = al_iio_load(filename);
21 line = al_fgets(ani_file, 300, line);
22 float time = atof(line);
23 times<i> = time;
24 i++;
25 }
26 }
27 
28 ANIMATION *anim = create_animation(bmps, times, amount);
29 
30 free(times);
31 free(bmps);
32 free(line);
33 al_destroy_entry(ani_file);
34 
35 return anim;
36}

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?

Alianix
Member #10,518
December 2008
avatar

It's none of my business but i would say something like this does not belong in A5, it's too high level and too specific. What i would suggest is a simple function to load an array of bitmaps, like in A4 , from a bitmap file. The bitmaps could be simply stored in the file with some magic colors indicating the boundaries of the bitmaps. This way sequences could be stored in one file instead of loading each frame from a separate one. But again even this is probably too much to ask of the API.Maybe an addon?

Thomas Fjellstrom
Member #476
June 2000
avatar

It's none of my business but i would say something like this does not belong in A5, it's too high level and too specific.

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Peter Wang
Member #23
April 2000

Please don't use the ALLEGRO_* or al_* prefixes, though.

count
Member #5,401
January 2005

@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?

Thomas Fjellstrom
Member #476
June 2000
avatar

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

Find a host some place, possibly SourceForge, BerliOS.de, or GNU Savannah.

But if necessary I wouldn't mind hosting some basic sites for a5 addons at strangesoft.net, could host svn at svn.tomasu.org as well.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

count
Member #5,401
January 2005

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

Thomas Fjellstrom
Member #476
June 2000
avatar

think of it as the official allegro addon repository

the Official addons are in allegro's svn any others are unofficial.

But putting links to all addons on the wiki, and/or the website would be good.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

ImLeftFooted
Member #3,935
October 2003
avatar

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

If people have lost interest the addon probably deserves to disappear. Means its no longer supported and SHOULDN'T be used.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

ImLeftFooted
Member #3,935
October 2003
avatar

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?

Thomas Fjellstrom
Member #476
June 2000
avatar

Really? so its page disappears, and it never re appears, and you think its still viable? I don't it means its DEAD.

Why work to filter something there are none of?

Thats just it, we'd have to work harder to put together a common repo for 3rd party addons, and support it. If YOU want to do that, go right ahead. I doubt any of the devs will.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

ImLeftFooted
Member #3,935
October 2003
avatar

Someone else might want to take over the project.

Thomas Fjellstrom
Member #476
June 2000
avatar

Someone else might want to take over the project.

Then they likely already have a copy.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Alianix
Member #10,518
December 2008
avatar

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)

count
Member #5,401
January 2005

Do you want different animations with different sizes in one bitmap? Or do you want to support animations where each frame of ONE animation have different sizes?

If the first then the solution I think about will support that do (without the borders but with some minimal input from the user).
If the second I initially didn't plan on supporting this because when the frames have different sizes you need some more infos. For example the offset of each frame to the position of the animation. It's something to think about what would be more usefull and still stay useable.

Alianix said:

...Could avoid multiple files and .ani file

The ani file would still be needed. Otherwise you would have no place where you specify the frame times.

Good work!

Thanks! Happy to hear you like it

Alianix
Member #10,518
December 2008
avatar

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...

#SelectExpand
1/* 2Here's one of the ideas i had on the bitmap layout. 3magic_color1 = 0 (could be white) marks the bounding box 4magic_color2 = 1 (could be black) marks the outside corners of the frame 5 6A Bitmap holding 4 frames of two different animations of different size frames: 7 810000000000010000000000000000 <- 2 Animation frames for first sequence 90XXXXXXXXXX00XXXXXXXXXXXXXXX0 (Only pixels of X-s are part of frames.) 100XXXXXXXXXX00XXXXXXXXXXXXXXX0 110XXXXXXXXXX00XXXXXXXXXXXXXXX0 120XXXXXXXXXX00XXXXXXXXXXXXXXX0 130XXXXXXXXXX00XXXXXXXXXXXXXXX0 140000000000010XXXXXXXXXXXXXXX0 15 0XXXXXXXXXXXXXXX0 16 00000000000000001 17 181000000000001000000000000000000 <- 2 Animation frames for 2nd sequence 190XXXXXXXXXX00XXXXXXXXXXXXXXXXX0 200XXXXXXXXXX00XXXXXXXXXXXXXXXXX0 210XXXXXXXXXX00XXXXXXXXXXXXXXXXX0 220XXXXXXXXXX00XXXXXXXXXXXXXXXXX0 230XXXXXXXXXX00XXXXXXXXXXXXXXXXX0 240000000000010XXXXXXXXXXXXXXXXX0 25 0XXXXXXXXXXXXXXXXX0 26 0XXXXXXXXXXXXXXXXX0 27 0000000000000000001 28 29 30Sorry this sucks these should be square. 31 32New line of bitmaps marks new sequence (animation). 33 34The .ani file should have info about the name of the animations also. 35 36Then maybe like: 37*/ 38typedef struct ANI_FILE{ 39 char bitmap_file[]; // the file containing the animations 40 char *name_list[]; // possible list of names of the animations 41}ANI_FILE;

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

count
Member #5,401
January 2005

To be honest I dont like the bitmap border idea.
What if one animation has a transparent (read magic pink) background, another one has a black, another one a white, red, green.... background.
What colours do you want to choose for the borders then?
In my opinion this is too limiting.

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.

Also if you don't want the user to make the dirty work hacking numbers into a file I would take it one step further.
Don't let the user do the dirty stuff in the bitmap editor as well.
What I mean is that it would be possible to write an editor where the user can create the animation and the editor will save the ani file with the needed information and the huge bitmap with all the needed frames.

That's the way I would like to go. Much cleaner in my opinion because it's not so limiting (border colour problem) and better load performance. And the editor will deliver a nice enduser experience

If you disagree please continue to post
Didn't want to talk your idea down. Just wanted to share my ideas. Maybe you like them or maybe you havzze some points for your idea I didn't got yet and in the end your idea will be better.

Alianix
Member #10,518
December 2008
avatar

"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.;)

count
Member #5,401
January 2005

On the train so only short reply from my mobile.

I still see the problem if you want to add an animation which has the background color that you are currently using for the magic colors. Then you would have to change the borders in the whole bitmap.
I admit that this is a rare case. But it still makes me feel uneasy.

Quote:

reading pixels of it would be pretty fast

Maybe it's fast. But not needing to do it at all is faster
And if you want to save multiple animations in one file it can get bigger than 64x64 easily. So you would have to chack many pixels.
Loading is a onetime process. So maybe it doesn't even matter that much. But I could imagine that when loading much animations or a big file it will be noticeably slower when it needs to check many pixels.

About the editor:
I didn't mean to write a bitmap editor but an animation editor.
You create the single frames with the tool you like and then use the animation editor to load your bitmaps and create the animation with it.

There is one thing I need to think about. If multiple animations are stored in one bitmap would it be faster to create small bitmaps for internal use or should all animations work with the big file. If the solution with one big file is better (which I could imagine becuase I read that graphic cards like one big file better than much small ones) than the freeing of the bitmap could not be done when one animation is deleted because the other animations created from this bitmap would still need it.
So the bitmap could only be destroyed when the last animation gets destroyed. I have something in my mind but I need to think about it a little more.

Alianix
Member #10,518
December 2008
avatar

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 ?

count
Member #5,401
January 2005

If you use the big bitmap how can that be discarded? The animations would only contain a pointer to this big bitmap and additional info where to find the frame.
So I don't get what you mean with discarding it after processing is finished...

[EDIT]
What I mean was this

If multiple animations are stored in one bitmap would it be faster to create small bitmaps for internal use or should all animations work with the big file.

So I want to load the big bitmap once and then only use this. Using this solution the bitmap couldn't be discarded because it is the only source for the animations.
I think your solution sounds more like creating mcuh small bitmaps out of the big bitmap and then discarding it.

Which one makes more sense was the question I had. I didn't mean to load only a part of the big bitmap.
[/EDIT]

I also don't get how your loader works when the border/corner has the same colour as the background. How would you determine the end of one animation or frame when the border is no longer existent?

Maybe I misunderstood something

And one more question.
I still don't get how you want to solve the offset problem without the ani file?

And with your solution I think the different animation frames are besides each other and the different animations are one below the other.
It would not be possible to align them freely in the file. Which would make sense if you have some space unused somewhere. Would be good to use it and place different animation besides each other as well.

Alianix
Member #10,518
December 2008
avatar

"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

count
Member #5,401
January 2005

Alianix said:

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 don't know if it is better. I just said, that we have to figure out what is better.
a) loading the big bitmap, create lot of small bitmaps, discard the big bitmap
b) load the big bitmap, use this as the blitting source.

The reason why I asked this was this:

which I could imagine becuase I read that graphic cards like one big file better than much small ones

If the big bitmap isn't used internally what is the benefit of puttin all animations in one file?

---

Alianix said:

You mean the offset of the sprites ?

Yes. The offsets will require the most work/pixl counting. When the border bitmap solution doesn't solve this problem I don't see the that much of a benefit because the hardest work would still be done manually (and the border maybe make it even harder to calulate the offset by hand).

---

Quote:

Honestly I would hate to have to edit some file to enter correct pixel info and counting pixels manually.

Yea see your point here :) Totaly agree. It would be a pain.

---

Quote:

Actually My loader code could be used to actually create an .ani file [...]

Sounds interesting. But then there would be still the problem with the offsets which couldn't be generated out of the bitmap file...

Neil Walker
Member #210
April 2000
avatar

Alianix said:

Otherwise do you want to have to use sub bitmap blitting in AL5 ?

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

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

 1   2   3   4 


Go to: