Yeah, your video shows that the display is not being acknowledged. I'm not sure why since you are indeed acknowledging it.

One thing that is very important. Do you register your display to your event queue?

Notice how I do it:

 int main(int argc, char *argv[]) { 
// Start the event queue to handle keyboard input and our timer
 ALLEGRO_EVENT_QUEUE *queue = al_create_event_queue(); 
al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*)al_get_keyboard_event_source()); 
al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*)al_get_mouse_event_source()); 
al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*)timer); 
al_register_event_source(queue, (ALLEGRO_EVENT_SOURCE*)display);
 ALLEGRO_EVENT event;
 while(!done) {

If you do not register your display, certain things might not work correctly, and resizing might be one of them.

You probably will not receive the resize event.

If you can, print the bool returned by acknowledge resize call to see if it returns true.

Oh wow, I never even knew about those functions hahah

At the time that I wrote the template, I was using 4.9.something and I'm not sure if those API's had been added yet

This is basically the gist of the whole thing :

outer_area is your screen, layout_area is the percentage rectangle, and LayoutArea returns the new rectangle based on the combination of the two.
fx,fy,fw,and fh are all floats representing the percentage from 0 to 1.0 (or beyond, but then offscreen) of that dimension's x or y or w or h.

Really, you should check to make sure you're transforming your buttons to the new position properly. All I saw was += fx + ... which is just a translation, and not a scaling.

The main disadvantage of the resolution independence methods you linked is that your game can only run on 1 aspect ratio. If you want your game to run on 4:3,16:9,16:10 aspect ratios etc, then you will have to have black borders or everything will look stretched.

Yes, the other option involves using layouts / relative size algorithms for your gui, and for the game, you can use transformations such that the character is always the same size, but more land is in view in widescreen and so forth. My game supports just about any common aspect ration because of how I designed it.

The basic idea of layouts is that you specify constraints for your widgets/components. You put Widgets into containers with these constraints and the algorithm will size and position your Widgets such that they look optimal for the selected width and height.

Java's Swing API allows this sort of flexibility. My GUI API and a few other GUI APIs on a.cc support this sort of Layout concept.

Otherwise, the alternative quick n dirty way is for you to specify when you get a resize event:
button1.size = width * 0.2f, 60;
button1.location = width / 2, height / 2;

So basically, when the screen is resized, set the button to the center of the screen, and set its width 20% of the screen width, and its height to a fixed 60 pixels.

This way at any resolution the button will look correct.

It's a lot more work to do it this way but I personally prefer it over a static solution.

If you run both allegro examples ex_resize and ex_resize2 you might end up thinking that, since both programs resize what's in the screen automatically; this led me to the initial confusion because clashed with what jamsterx said (and I actually remebered like that as well).

Upon looking at the code of the examples thou it was clear that's not the case.

Dunno, maybe the two examples could be tinkered with.

moving on...

Not exactly, because I don't know what are you aiming for specifically, but in principle if you're not bothered by the shrinking/stretching you indeed COULD use the automatic gfx adaptation.

It's not elegant nor eyecandy thou, you should at least set display constraints that set for a minimum and maximum width/height (see al_set_window_constraints), and could even handle the resize event (still without acknowledging) calling al_resize_display to FORCE a certain aspect ratio.

At least that's how it come to mind seeing your video, which admittedly it's not the optimal way to do it (I dunno if the gfx driver performance would be bothered for example, even thou I guess not).

Felt obligated to mention this - the way the display looks during a resize is just a temporary way to keep something on the screen that looks remotely appropriate. The mouse and its positions will NOT be affected until you call al_acknowledge_resize or al_resize_display. Then they should work as expected. Allegro does not transform the mouse. It just stretches the display to the intermediate size.