You don't need to worry about locking any functions or data with Allegro 5, unless you're working with bitmap data directly, but there are functions for that.

install_int_ex doesn't do the same thing as al_create_timer. It installs a call back function that gets called every time the timer ticks. You can do the same thing in allegro 5 by doing this :

al_register_event_queue(queue , al_get_timer_event_source(timer);
//...
ALLEGRO_EVENT ev;
al_wait_for_event(queue , &ev);
if (ev.type == ALLEGRO_EVENT_TIMER) {
   /// Put the code from install_int_ex inside here for the same effect
   /// Eg...
   /// ++count;
}

This one is harder but can still be done using al_draw_soft_line. I can't give you the exact details though.

Check out these for some differences between the two library versions:

https://wiki.allegro.cc/index.php?title=Porting_from_A4_to_A5

https://www.allegro.cc/forums/thread/610896/964091

http://stackoverflow.com/questions/6418757/porting-allegro-4-to-allegro-5

I'm not sure if this is helpful, or rambling and confusing, so if the latter, feel free to disregard:

Basically, in Allegro 4, everything was double buffered (draw everything to a memory bitmap, and then when you're entirely done, blit that to the screen at the right time with vsync so it doesn't flicker) or page flipped. (Rare, everything is in video memory and VRAM-to-VRAM copied to a off-screen page of VRAM. Then when ready, change the videocard's "screen" to point to that new page. It uses two pages, and they are flipped between each other.)

I believe Allegro 5 is page flipped because modern Direct3D and OpenGL do that. Allegro is a thin layer over those. Whereas Allegro 4 had to "re-invent the wheel" with specific routines for everything because in general, there were no frameworks for that.

There are two ways to do things:

The old way, you either used double buffering (everyhthing was kept locally in RAM), or page flipping (everything in VRAM so it's hardware accelerated 2-D if the card supports it.).

The new way goes through OpenGL/DirectX, which then go through the native graphics driver. So instead of fiddling with registers, you're calling API's which call driver API's which say "draw this please." Everything is in a texture, and Allegro bitmaps are tied to textures with some additional helper information around them.

[This paragraph can be skipped:]
The new way also has the "Fixed/Classic Pipeline" (~1995-2005) vs "Modern Pipeline" (~2005 onward). Classic pipeline used to be faster because it was set-in-stone. Shaders were for special things, and the fixed pipeline did everything else like vertex transformation. The modern pipeline let you (and forced you!) to use shaders for everything. Without a shader, you don't get anything on the screen. These days, the fixed pipeline forces the card into compatibility mode. It's slower, but still 1000's of times faster than your traditional old videocards. IIRC, Allegro normally runs in fixed mode, and that's fine for 2-D games. But if you go on, you'll want to look into the details of this.

They already mentioned that A4 used timers, A5 uses event queues.

Allegro 5 uses event queues for everything. They're not too hard, but they're different, so read up on them. You're just running an event handler that checks if any events are on the event queue, and if so, it deals with them. That's it. But if you're careful, you can still structure a game like Allegro 4 without an event handler, so it should be relatively easy to port an A4 game to A5 without ripping out the core logic.

[edit]

I don't recall the solution to your problem off-the-top of my head, but don't worry about using "minimum amounts of memory." Memory is cheap. Super cheap. Use whatever solution makes sense. It's unlikely you'll be wasting too much memory.

Don't worry about it. I definitely had far worse English when I started here.

No, when you call al_wait_for_event or you call al_get_next_event and it returns true, then the event is taken off the queue. So every tick is a new event, and it ticks at the rate you set with al_create_timer.

Yes, see al_get_next_event or al_wait_for_event_timed or al_wait_for_event_until.

Typically the input loop looks like this :

What does the Fight() function look like? I'm not sure how you want to do it without seeing that first. Isn't there a loop somewhere?

Allegro 5 is event based. You need to check for events inside a loop, because they will keep coming. You can't just check for an event once, and then expect it to change.

Also, you need to make sure the event type matches the data you are trying to get out of it.

Ie.

// This loop will check for all current events
while (al_get_next_event(queue , &ev) {
   if (ev.type == ALLEGRO_EVENT_KEY_DOWN) {
      // Now it's okay to access the keyboard member, because we know it's a keyboard event
      if (ev.keyboard.keycode == ALLEGRO_KEY_R) {
         // do stuff
      }
   }
}

I realize that. I'm just trying to explain the basics of using a loop to process all the events. If you look at my earlier example it uses al_wait_for_event. He didn't seem to fully grasp that model yet so I tried to use a simpler version to explain things. That's all.