version: 5.2.3
OS: Windows 10

Toggling ALLEGRO_FULLSCREEN_WINDOW works fine on one of my machines but not the other.

On the other one, the initial window works fine, but after entering fullscreen and then exiting, instead of a window I just get a picture-in-picture effect in the bottom left corner of the screen.

I can't update to the latest version (that is to say, I've tried and failed) so I'm trying to see if this was/is a known issue and what suggestions anyone has on a workaround or if I am doing something wrong.

Here's the Forth code:

variable winx  variable winy
: ?poswin ( - )   \ save/restore window position when toggling in and out of fullscreen
    display al_get_display_flags ALLEGRO_FULLSCREEN_WINDOW and if
        fs @ 0= if  r> call  display winx @ winy @ al_set_window_position  then
    else
        fs @ if     display winx winy al_get_window_position  then
    then ;
    
0 value #lastscale
variable newfs
: 2s>f ( ix iy - f: x y ) swap s>f s>f ;
: ?fs ( - )  \ toggle fullscreen based on FS flag
    ?poswin
    fs @ newfs @ = ?exit
    display fs @ if native 2@ else res 2@ #lastscale * swap #lastscale * swap then al_resize_display drop
    display ALLEGRO_FULLSCREEN_WINDOW fs @ $1 and al_toggle_display_flag drop
    fs @ newfs !
    fs @ if
        #globalscale to #lastscale
        native xy@ 2s>f f/ 
        res xy@ 2s>f f/ f> if
            native y@ res y@ /
        else
            native x@ res x@ /
        then
            4 min to #globalscale
    else
        #lastscale to #globalscale
    then
    FULLSCREEN_EVENT al-emit-user-event
;

Maybe a driver issue? This kind of thing also happens with AAA games, this is not easy...

I can't imagine that being the case... ALLEGRO_FULLSCREEN_WINDOW essentially just resizes the window and removes the frame. For some reason it doesn't appear to be doing either! Only changing the projection, I guess.

Update:

Extra weirdness! When working in my engine's IDE I have this issue (on one computer), but in exported games it works fine!

Which is very strange because they use the exact same code. The only difference is the Ramen IDE has a "parent" window, the SwiftForth IDE.

Update:

OK, I lied. There is a difference; exported games don't set ALLEGRO_OPENGL. Which is technically a bug; they should. But that means that Allegro 5 isn't playing well with OpenGL on this machine. Or the driver is buggy ... or both! What should I do?

Well, what is an "exported" game?

Classic Forth practice is to save an image of the running compiler-interpreter, along with the compiled program in memory. This image is called a "turnkey" and that's what my exported games are. They use the "runtime" startup code that's slightly different from the "development" startup code.

I guess the question is what happens to the code you write before it is executed. Forth is an old and largely unsupported language. There could be many reasons why your program fails. Do you have an active Forth community that you can ask?

It may be helpful to post the allegro.log.

You can enable it by... having an allegro5.cfg in the same directory as your program with the contents:

[trace]
level=debug

An allegro.log will appear after you run your program.

I really haven't the faintest what you're doing in that Forth code, but it should be as simple as translating this C to Forth :

bool fs = al_get_display_flags(display) & ALLEGRO_FULLSCREEN_WINDOW;
al_set_display_flag(display , ALLEGRO_FULLSCREEN_WINDOW , !fs);

Destroying and recreating the display solved the issue.

A particular monitor caused a different issue when the first computer was connected to it. Different but no better. So it seems to be picky not only depending on what driver but what monitor is connected. (I tested with and without OpenGL and it didn't matter with this combination.)

I'd recommend to anyone to just never ALLEGRO_FULLSCREEN_WINDOW with al_toggle_display_flag. Maybe that feature should be removed.

EDIT: After some more debugging I think I was doing something wrong, I'll update when I figure it all out.

That's one option, sure, but it's sub-optimal. It would mean moving all the textures to memory and back, which is fine if you haven't loaded any.

al_toggle_display_flag was deprecated in favor of al_set_display_flag. They do the same thing. Whether or not the implementation changed I'm not sure yet. My gitfu isn't good enough to figure out how to compare 5.2.3 with master.

Also, al_set_display_flag(d , ALLEGRO_FULLSCREEN_WINDOW , onoff) works fine for me on Windows 10 with 5.2.5.

If you need help upgrading that's a different topic.

EDIT
Is this the code to toggle the flag?

display ALLEGRO_FULLSCREEN_WINDOW fs @ $1 and al_toggle_display_flag drop

Could anyone download this and run the examples under bin/ and post how toggling fullscreen with alt-enter works for them? (Assuming they run. Windows 7+ only)

https://www.dropbox.com/s/zpzs2nhlufpyrwg/RamenEngine-2.0-Preview-1.zip?dl=0

@Edgar, the documentation says that bitmaps are preserved in cases where the driver might drop them from VRAM, so doesn't that mean it shouldn't be an issue?

I added a check to see if the al_set_display_flag returns 0 and if so use the destruction/creation method. On the computer where toggling out of fullscreen doesn't work right, it doesn't return 0 so the bug persists.

I spend way too much time dealing with these kinds of low-level issues that I feel Allegro should have already solved for me. I'm thinking of dropping windowed mode entirely, or prohibiting switching (i.e. applications are windowed OR fullscreen.)

It's a performance issue, not a usability issue, just wanted you to be aware in case your apps are resource heavy.

I've been spending some time with the Windows window code and I'm confident we could get it fixed (if it hasn't been already).

I'm not seeing any changes in src\win\wwindow.c since 5.2.3. I checked out 5.2.3 and it's the same.

It works fine for me as long as I don't have my HDMI monitor attached, then it gets weird. Try updating your graphics drivers and see if that helps.

I downloaded your zip from DropBox and Windows Defender says it found a Trojan in your code.

{"name":"611945","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/3\/7339cc9217cdbc8a8ef5dafced95d6e7.png","w":698,"h":786,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/3\/7339cc9217cdbc8a8ef5dafced95d6e7"}

I was afraid of that... my install literally just started doing the same thing. Can you whitelist it? I forget the procedure but when it gets tripped if you click advanced options or something you get the choice to ignore it.

It's a bug with SwiftForth, don't know if they even fixed it. Things are way overdue to jump ship from that product. Because the evaluation doesn't let you write .exe's and the full copy costs $400 and I don't even use 90% of its features, which are oriented towards Windows GUI's.

Graphics drivers are up to date. It's just plain old Intel HD.

Alt Enter works fine on your platformer app.

Good to hear, but I got the same bug on my mom's computer (another Intel HD), so it doesn't appear to be a fluke. What kind of graphics adapter do you have?

Intel HD by default. NVIDIA by choice.

Your platformer works fine, including on my HDMI monitor, just with the Intel.

Are you switching to fullscreen and back, or just into fullscreen and quitting? It happens when you go from window->fullscreen->window.

Both

OK. Are you able to access any other machines? Otherwise I guess we just have to wait and see if anyone else can reproduce it.

The toggling ability isn't a crucial feature, so for now I've taken it out of the engine.

I don't have any other computers to test it on except for XP.

I tried using my HDTV and it works too.

Thing is, going from fs window to window is a mode switch for the monitor.

So maybe you just have bad monitors, I don't know.

Thing is, the windows code does the same thing on every windows edition there is. It's not necessarily a Windows problem, rather a hardware or software problem.