It's probably because Allegro has to go through the trouble of destroying and creating a new OS window when going fullscreen (I think so anyways, the source code shows that).

Maybe ALLEGRO_FULLSCREEN_WINDOW would give better results. There might also maybe be a switched in or expose event or something that you receive when doing that.

Yeah, I run the program, initialize everything. I am very careful about the order I do things in. No bitmaps are set until long after the display is set up. I set VSYNC & FULLSCREEN from a config file (I got that from one of the examples on vsync I think it was). Once the display is set early in the program it isn't changed again. I tested it with vsync set at 0 (system driver), 1 (forced on) and 2 (forced off) and the problem is still there. But only in Fullscreen mode. I don't do anything fancy with other settings (like blenders and such) as I want to be sure the program is running smoothly with normal default settings first.

It's puzzling because I wouldn't think I would be able to hear my sound sample at all until the flip was done, but it plays halfway through before the screen appears.

I have 10gigs of system memory and an nVidia GT240 video card, so I am not lacking in memory. CPU is quad core 3Ghz too.

Like I said, window mode and fullscreen window works. I like fullscreen window, but then I would have to hack away at some code to make everything display properly when I should be able to simply call a normal fullscreen mode and let the users monitor handle how to do that.

If I have to I will, but it seems like odd behavior and would be nice to find out why it is doing that.

Below is my initialization function, I cut out most of it and just commented what is there, but all code I do have was tested and works fine, I always check return values no matter how remote the chance of failing as I like to be safe...

My intro where the problem occurs.

The end of the code above is where you get the delay before the screen appears, the sound plays for about 2 or
3 seconds before the screen appears, but only in ALLEGRO_FULLSCREEN mode.

And my main function...

int main(int argc, char *argv[])
{
   // set variables etc for use later here, non of  these effect the intro...

   initialize();

   intro();

No need to show more, this is where it branches off to do the intro mentioned above.

Edit: not that it matters, but all graphic, font and sound files are loaded from a ZIP file and shut_down() you see simply destroys anything that needs destroying before the game exits.

I just tried it with al_set_new_display_flags(ALLEGRO_FULLSCREEN|ALLEGRO_OPENGL); and there was less of a lag. It was almost right away, but not quite, still a small one, but much shorter lag.

I also tried it with lower resolution graphics (bitmaps are half the size) and lower quality sound (I changed the sound from a WAV to an OGG). They're MUCH smaller files to load etc... but there's no difference in lag.

I have an allegro log file, wish I knew what I was looking at.

Edit: I attached the log file from the default Direct3D run.

5.0.7

Edit:

Also, I am not sure how to do this. I may fiddle around with ALLEGRO_FULLSCREEN_WINDOW and see if I can work something out with it, or just stick to opengl for now, at least until the next stable release comes out. I don't compile my own allegro anymore, all the dependencies seem to always give me problems. No big deal I guess, I'll be working on this project for a while anyhow.

I attached a log where I set the breakpoint in debug mode to immediately after al_flip_display();. I actually had to logoff my machine, couldn't break out of the program or even for it to shut down, sheesh Microsoft need to fix Task Manager!

I check the docs and started looking at anything I could find on transformations. Looked at ex_transform, started to play around with it.

It took me a while of fiddling around with the number to figure it out, but I managed to come up with this (before reading your post).

   display.w = al_get_display_width(display.screen);
   display.h = al_get_display_height(display.screen);

   display.scale = (float)display.h / (float)HEIGHT;
   display.move = (float)(display.w - (WIDTH*display.scale))/2;
   al_identity_transform(&transform);
   al_scale_transform(&transform, display.scale, display.scale);
   al_translate_transform(&transform, display.move, 0);
   al_use_transform(&transform);

I placed that after I create the display and it works great!

For certain screens I added:

   al_draw_filled_rectangle(-display.move, 0, -1, HEIGHT, al_map_rgb_f(0,0,0));
   al_draw_filled_rectangle(WIDTH, 0, WIDTH+display.move, HEIGHT,
                            al_map_rgb_f(0,0,0));

That puts a black box on each side.

I'm not sure if there is a better way, but this works, I am quite pleased, I didn't think I would be able to grasp how to do a transform.

I can plug this into any other program as it is quite portable, just set WIDTH and HEIGHT to the resolution you want. I think I should probably put some sort of checks in there but it's too late for me to think, my brain is already about to explode.

EDIT: Hmmm, I may use the code you posted instead, look prettier.

OMG that might explain why it suddenly turned dirty fast on my ancient hardware ><

That's the best way to learn. Unfortunately, it seems like programmers have gone from figuring things out from documentation to searching Google to just asking somebody for the code.

I've been sucking on the Google tit myself, it's easier to search Google than to CTRL-F some pdf and if I'm lucky, get one specific example that invariably differs from my problem. But usually my problem is so specific that a programming forum doesn't know the answer off the top of their head, so they have to Google or whatever themselves if they want to help.

I did, but there's no need to give credit. There's pretty much only one reasonable way to do it.