Forth code with equivalent psuedocode

: fs?   display al_get_display_flags ALLEGRO_FULLSCREEN_WINDOW and 0<> ;

: w/f
   display ALLEGRO_FULLSCREEN_WINDOW fs? not 
      al_toggle_display_flag 
         0= abort" could not switch to fullscreen"
   fs? 0= if 
      display ALLEGRO_WINDOWED 1 al_toggle_display_flag drop
   then
;

\ ------------

function isfullscreen () { 
   return ( al_get_display_flags(display) & ALLEGRO_FULLSCREEN_WINDOW) != 0 ); 
}

function switchWF() {
   al_toggle_display_flag( display, ALLEGRO_FULLSCREEN_WINDOW, ! isfullscreen() );
   if ( ! isfullscreen() ) {
      al_toggle_display_flag( display, ALLEGRO_WINDOWED, 1 );
   }
}

Switching from windowed to fullscreen in this manner works, but switching back from fullscreen to windowed does not.

I had difficulty taking a screenshot. Basically what happens is the screen goes black and the game displays at the size of the windowed mode in the bottom left corner. I don't see a window or the desktop.

Anyone else have this problem? Is it a bug? Is there something I'm doing wrong? A step I've left out?

I took out the line with ALLEGRO_WINDOWED but it's the same as before.

The only difference to your code is that I start the game in windowed mode while your code starts in fullscreen. Does your code still work if you start in windowed?

IIRC ALLEGRO_FULLSCREEN_WINDOW is a modifier for ALLEGRO_WINDOWED. I don't think you want to mix ALLEGRO_FULLSCREEN and ALLEGRO_FULLSCREEN_WINDOW.

Well, think you can get a print screen? And you should post your specs - OS, compiler and version of Allegro.

Edit
@Tomasu
Oh yeah! Sorry, that was scraps from an earlier bit of code but it does the right thing even if it looks wrong

Yeah, I mean what compiler did you use to compile allegro? MSVS or MinGW? Which versions?

@Edgar MinGW gcc 4.8.1

@NiteHackr The flags I set at program start are:
ALLEGRO_OPENGL
ALLEGRO_WINDOWED
ALLEGRO_RESIZABLE

I'm not sure what to tell you except to wait for someone who knows more. It could be a change made to Windows 8 that broke something, but I don't know because window creation should be the same on every windows version but somebody correct me if I'm wrong.

Ah, yeah, after reading your post I just tried my own game out with OPENGL enabled (OpenGL 4 on my system) and it crashed, where as it works perfectly fine without it.

"Assertion failed: 0, file d:\Libraries\build\allegro\src\allegro-git\allegro-git
\src\opengl\ogl_bitmap.c, line 357"
(I am using Allegro 5.1.7, GCC 4.7.0 on Windows 7)

After further testing, this only happens in ALLEGRO_FULLSCREEN mode, it doesn't happen in an ALLEGRO_WINDOWED or ALLEGRO_FULLSCREEN_WINDOW.

When I first switched to using Windows 8, I noticed that ALLEGRO_WINDOWED and ALLEGRO_FULLSCREEN_WINDOW were producing stuttering in the framerates of the game I'm working on, where the framerate will be fine for a moment, then stutter for a moment, then be fine for a moment, stutter for a moment, fine for a moment, etc. etc.

However, this only affects the first ALLEGRO_DISPLAY object created. Destroying that display and creating another eliminates the stuttering issue, even if the new display is identical to the first one in every way.

As a workaround to this, I'm moving all video configuration options into a startup window running ALLEGRO_WINDOWED, where a little bit of stuttering isn't going to make a huge difference. Not sure if it's strictly OpenGL related or not as my game uses GLSL fragment shaders so I pretty much have to use OpenGL exclusively for the moment.

However...

1. I have not run into the problem described from the start of this thread. I can make multiple screen setting switches without running into a missing desktop. That said...

2. ...if I switch into one video mode then try immediately to switch into another without really doing anything, this causes some extremely nasty glitching to occur, forcing me to perform a hard-reset of the entire system.

For reference, I never use al_toggle_display_flag() as I was taught from the early days of game coding that you NEVER "adjust" existing displays. The best approach is to close out the display completely (loaded textures and all) and start a new one in order to ensure you're not breaking anything in the process, since altering an existing display context can be an extremely temperamental process that is likely going to perform differently on every OS and video card combination out there.

I didn't have a problem creating displays for OpenGL, my problem was with the following line totally crashing my game:

al_draw_scaled_bitmap(al_get_backbuffer(setting.screen), offset_x, offset_y, WIDTH*scale_x, HEIGHT*scale_y, 0, 0, WIDTH, HEIGHT, 0);

This line works perfectly with DirectX in Windowed, Fullscreen Windowed and Fullscreen.
It works perfectly with OpenGL in Windowed and Fullscreen Windowed.

It only crashes in OpenGL Fullscreen mode. It copies the game screen to a buffer of size WIDTHxHEIGHT which is created with all error checks in place, so I figure my only option at this point is to remove OpenGL support, at least in that mode anyhow, which will make my game Windows only, or at least not have a fullscreen/OpenGL option on other platforms.

He probably sets a different taget bitmap before the instruction, I guess.

I see, that "scaled" is a major issue then, surely a crash is STILL a downer since it was only expected to be "slow".

Now, NH should answer, but I got the impression that the scaled version is fundamental in maintaining the aspect ratio?