I guess it's worth the effort. Last attachment updated.

Anything else?

That while (poll_scroll()); with just a terminator at the end always looks suspicious to me. Sorry; that's just me. I implemented both style suggestions, even thought the RHS evaluates just fine (I guess it's clearer now). Updated attachment.

... Why?

Also, I caught a bug; destroying all the bitmaps like that in shutdown_screen_updating() is a bad move because buffer and active_page could be pointing at the same bitmap. Calling destroy_bitmap() on both would be bad, yes? Fixed up.

If you are assuming the first update method is 0, I'd suggest for clarity, simply explicitly setting the first item in the enum:

enum {
        NOUPDATEMETHOD = 0,
        TRIPLEBUFFER,
        PAGEFLIP,
        SYSTEMBUFFER,
        DOUBLEBUFFER,
        TRIPLEBUFFERWMB,
        PAGEFLIPWMB,
        LASTVALUE
};

And personally I'd add underscores in those, cause they're kinda hard to read. Or in this case, since they're global constants, perhaps:

enum {
        UPDATE_NONE = 0,
        UPDATE_DOUBLE_BUFFER, // Or take out _BUFFER?
        UPDATE_TRIPLE_BUFFER,
        UPDATE_PAGE_FLIP,
        UPDATE_SYSTEM_BUFFER,
        UPDATE_TRIPLE_WMB,    // WMB is a bit odd... maybe MEM or MEMORY instead
        UPDATE_PAGEFLIP_WMB,
        UPDATE_MAX            // this is just personal style for me when doing enums
};

Marcello

I like Marcello's enum name suggestions. I'm gonna keep the WMB (With Memory Buffer) though.

New update; you can now toggle vsync by pressing 2, and cycle through screen update methods by pressing 1 (that's a change to the example code, not the API). Calling the initialization function now let's you switch update methods with a single function call (it calls the shutdown function internally if there's already an update method in operation). Also streamlined main.cpp a bit and added more comments. I think it's bulletproof now ...

EDIT: Oddly, Double Buffering is twice as fast as System Buffering for me. I thought the latter was supposed to be faster ... maybe I should omit it?

Maybe, maybe not. I know that for me, page flipping nets worse results both in terms of tearing and flicker than double buffering does. (Disclaimer: I didn't write the programs referred to here. They might have used some dodgy methods.)

One comment of yours fails the spell checker test.
Yes, "pedantic" is my middle name.

Can't see it.

Huh. Thought it was spelt with an 'i'.

Oh well. If that's my worst bug I'm happy.

Final call ...

One thing I noticed that could be added is documentation ... even though it's simple it's needed anyway for reference whenever you need to use a function, that way you don't have to go diggin through source code or header files to find something. Also in screen.h it is best to add:

This keeps it from being defined twice if it's included in multiple files in a project
I had to use SCREEN_UPDATE_H because I think allegro already uses SCREEN_H therefore it refused to compile the header file

I utilized your screen update code into my little game, which works well since it has the *_WMB ability and I use fades, etc. That way I get ultra smooth motion with Triple buffering fullscreen and fast fades. However for some odd reason in windowed mode triple buffering is actually a bit choppy and not smooth, double buffering is excellent windowed and somewhat ok fullscreen, but at least you get to choose

Ooh just noticed that UPDATE_PAGEFLIP_WMB doesn't work like it should, somehow I'm getting a video bitmap to draw to, this makes it extremely slow at times.

if(is_video_bitmap(get_buffer())){
  allegro_message("OMG VIDEO BITMAP!!!!!DIEKTHXBYE");
  exit(1);
}

You can guess what pops up on the screen
That's using the update method of page flip WMB so somehow I'm getting a video buffer