Just the first version of the code.Tested with allegro 4.9.8. Worked.The destroy method is probably not doing all it should (destroying the bitmaps?) and the create methid could need some error handling.

With what respect do you want us to comment? If by the AD forum, you mean included as part of A5, then I say no. This is something that is hard to abstract away. To do it right, you need a complete framework, which really isn't the same thing as a library (add-on or not).

With what respect do you want us to comment? If by the AD forum, you mean included as part of A5, then I say no. This is something that is hard to abstract away. To do it right, you need a complete framework, which really isn't the same thing as a library (add-on or not).

Yea, I was looking for that kind of comment. But not only.Comments about the code are welcome too, or ideas I missed like SiegeLord did.

Would you care to elaborate why this wouldn't fit in a library - or better - why this would need a framework?I hoped due to the simple update mechanics it was able to be used outside of a framework. Not wanting to change your mind. Just want to know what problems you see.

I'm not going to try to define fuzzy terms like "framework," but the point is that there are many ways to do an animated bitmap. To me, the things that should belong in Allegro 5 core or first class add-ons are things that are a) very complex (playing sound) or b) easy to agree on a standard method (loading a PNG file, getting clipboard data).

As soon as one person submits his version of animated bitmaps, somebody else is going to want to submit his own version. Then you have to decide which is better, when in reality they may just be different (and incompatible).

Essentially, I think it's just too high level of a concept. I think that it's something that people will find useful if they like your methodologies, but I think we should be careful about adding all sorts of things like this to Allegro just because we can.

Essentially, I think it's just too high level of a concept. I think that it's something that people will find useful if they like your methodologies, but I think we should be careful about adding all sorts of things like this to Allegro just because we can.

I agree.

Which isn't to say you can't provide something like that in the form of a third party addon. That would be good. We like third party addons.

Here is the datafile for the sprite, located at datafile.txt for a nice reference (shown below).

1

Angel.walk_right.frames.[+].url=tod/walk_right.1.gif

2

Angel.walk_right.frames.[].width=15

3

Angel.walk_right.frames.[].height=26

4

Angel.walk_right.frames.[].ttl=125

5

Angel.walk_right.frames.[+].url=tod/walk_right.2.gif

6

Angel.walk_right.frames.[].width=15

7

Angel.walk_right.frames.[].height=26

8

Angel.walk_right.frames.[].ttl=125

9

Angel.walk_right.frames.[+].url=tod/walk_right.3.gif

10

Angel.walk_right.frames.[].width=15

11

Angel.walk_right.frames.[].height=26

12

Angel.walk_right.frames.[].ttl=125

13

Angel.walk_right.frames.[+].url=tod/walk_right.4.gif

14

Angel.walk_right.frames.[].width=15

15

Angel.walk_right.frames.[].height=26

16

Angel.walk_right.frames.[].ttl=125

17

18

Angel.walk_left.frames.[+].url=tod/walk_left.1.gif

19

Angel.walk_left.frames.[].width=15

20

Angel.walk_left.frames.[].height=26

21

Angel.walk_left.frames.[].ttl=125

22

Angel.walk_left.frames.[+].url=tod/walk_left.2.gif

23

Angel.walk_left.frames.[].width=15

24

Angel.walk_left.frames.[].height=26

25

Angel.walk_left.frames.[].ttl=125

26

Angel.walk_left.frames.[+].url=tod/walk_left.3.gif

27

Angel.walk_left.frames.[].width=15

28

Angel.walk_left.frames.[].height=26

29

Angel.walk_left.frames.[].ttl=125

30

Angel.walk_left.frames.[+].url=tod/walk_left.4.gif

31

Angel.walk_left.frames.[].width=15

32

Angel.walk_left.frames.[].height=26

33

Angel.walk_left.frames.[].ttl=125

34

35

Angel.up_right.frames.[+].url=tod/up_right.1.gif

36

Angel.up_right.frames.[].width=15

37

Angel.up_right.frames.[].height=26

38

Angel.up_left.frames.[+].url=tod/up_left.1.gif

39

Angel.up_left.frames.[].width=15

40

Angel.up_left.frames.[].height=26

41

42

Angel.hover_right.frames.[+].url=tod/hover_right.1.gif

43

Angel.hover_right.frames.[].width=15

44

Angel.hover_right.frames.[].height=26

45

Angel.hover_left.frames.[+].url=tod/hover_left.1.gif

46

Angel.hover_left.frames.[].width=15

47

Angel.hover_left.frames.[].height=26

48

49

Angel.down_right.frames.[+].url=tod/down_right.1.gif

50

Angel.down_right.frames.[].width=15

51

Angel.down_right.frames.[].height=26

52

Angel.down_left.frames.[+].url=tod/down_left.1.gif

53

Angel.down_left.frames.[1].width=15

54

Angel.down_left.frames.[].height=26

When the sprite starts walking right the display switches to walk_right at the first frame. After 125 milliseconds the next frame is shown and so on.

The system needs to be smart enough to accept events that cause a frame to start over at frame 0 and loop from there. You also need to be able to "run once" and quit.

Another thing to consider: What if the game pauses? In certain cases the animations should pause as well. Also, what if the computer goes to sleep for some length of time and returns? This last one is a harder problem that I think is mostly safe to ignore though an easy solution would be worth considering.

For those interested, I'm going to ramble on about animation libraries.

Will have a look at this. Thanks!

Quote:

Another thing to consider: What if the game pauses? In certain cases the animations should pause as well.

If the game pauses then it shouldn't call the update methods for any of its containing objects. Not doing so causes the animation to pause too.

Quote:

Also, what if the computer goes to sleep for some length of time and returns? This last one is a harder problem that I think is mostly safe to ignore though an easy solution would be worth considering.

After such a case the delta time would be huge updating the bitmap accordingly and correct. Or I misunderstood you here.

Quote:

You also need to be able to "run once" and quit.

I will add nonlopping animation today after work. What do you mean with quit?That the animation gets destroyed?

Quote:

You should to it in spirit of A5 - emit an event when an animated bitmap is updated.

Ok. Will have to look into that.When should the event be emitted? When the update method is called? Or when the animtaion is switching to the next frame?The second thing seems more logically.What happpens if the delta time is so huge, that the animtaion is skipping one frame. Should only one event be emitted? Or should the amount of events be similar to the skipped frames?

EDIT:

Quote:

I think you should have ALLEGRO_ANIMATION to which you can load an animation file.Then an ALLEGRO_ANIMATION_INSTANCE with functions for playback of an animation.

Thus you can use the same animation at different speeds and loop settings at the same time.

Don't think I get what you mean here. Could you explain a little bit more?

Most games needs much more than just sprite number + duration on each frame.Some examples:- character dimensions, for axis-aligned bounding box.- sprite offsets- collision flags (think a Street fighter animation : which parts of character are hitting, which parts are vulnerable)- position of "attachments" (character holding an object: which Shield sprite do we display, at which coords.)- a function pointer, to handle anything.

Each game has different needs, so the best system for a tactical RPG isn't going to be good for a VS fighting game or a platform shooter.

What I don't see is how a variable frame rate would be possible with this.But I think that wasn't your goal to show with this approach.But I already have an idea how to solve the varialbe frame rate thing.

Look at the AnimBase::AdvanceTime function to see what I did for it. All you have to do is store the frame rate in seconds per frame and store the residual time accumulated so far. When it exceeds the frame rate, advance by the correct number of frames using division and then assign the residual time a new value using modulus and the frame rate.

I am currently coping with bitmap animation as well. Ideas spread by you guys around the forum helped me a lot, thank you all. In my opinion Trezker's idea is very interesting. Keeping bitmap sequences and animation instances separate makes stuff more flexible. Keep them in two data structures in some animation manager object and you got everything simple and under control.

You should include a check and a destroy_animation call into destroy_animation_instance.

Maybe I'm just being stupid, but why in the hell would you want to destroy the ANIMATION when you're just freeing the ANIMATION_INSTANCE? Other ANIMATION_INSTANCES could be using that ANIMATION at the time, or you may want to use it again after the call to destroy_animation_instance.