I'm about to port an MMO game client I created 4 years ago in Allegro 4 to the latest Allegro 5.

Can I expect this to be a lot of syntax trivia (i.e. replacing functions from Allegro 4 with corresponding Allegro 5 functions) or is Allegro 5 completely different from Allegro 4 from a fundamental/architectural point of view?

Are there any consistent gotchas I should be planning for?

I'm definitely looking forward to having iPhone and Android support with my favorite game development kit!

You can read about my experience porting to Allegro5: http://www.allegro.cc/forums/thread/607477

To answer your questions, yes allegro5 is significantly different from allegro4 so its not just replacing function names.

The most significant thing to keep in mind, imo, is that you can't just create bitmaps whenever you feel like in allegro5 and draw on them. You should try to draw on the main backbuffer (the double buffered screen) as much as possible, perhaps making sub-bitmaps of it when its convenient.

If you have a lot of bitmaps in your program you will most likely end up with a few memory bitmaps and your whole program will slow down quite a bit. They should only be displayed if they are converted to video bitmaps which you can do easily with al_convert_bitmap, but make sure only to do it in the thread where the display was created.

I suppose another thing to keep in mind is that allegro5 uses events where allegro4 used global polling. So instead of doing if (key[KEY_A]) you would set up a queue that gets an event placed on it and then check if that event is the A key: al_next_event(&event); if (event.type == KEYBOARD) ...

something like that.

Also drawing primitives and particularly putpixel are much slower in Allegro5 than their Allegro4 counterparts.

They are completely different. The biggest changes will probably be:

• There is an implied destination bitmap (active target)

  
  

• Input and feedback from Allegro is event driven

  
  

• (if applicable) No 8-bit graphics or palettes

To extend to the biggest changes list:

• Automatic hardware acceleration, making direct pixel access require lots of locking/unlocking and requiring that it be used much more stringently.

This thread is just what I needed, and I'll look into kazzmir's, too. Thanks.

The whole no-memory-bitmaps thing does scare me a little, but I enjoy learning new things and trust it's the better solution for whatever reason (hardware acceleration across multiple platforms?).

Think of it like programming for OpenGL (2-D only) with a much simpler and highly-extended API.

You can use memory bitmaps if you like. But they aren't something you want to use in your main drawing code a lot.

You have all been very helpful, thank you very much!