Per the documents, Prefer using ALLEGRO_FULLSCREEN_WINDOW as it typically provides a better user experience as the monitor doesn’t change resolution and switching away from your game via Alt-Tab works smoothly. ALLEGRO_FULLSCREEN is typically less well supported compared to ALLEGRO_FULLSCREEN_WINDOW.

Otherwise, destroy current display, toggle flag, then make a new display.

He's doesn't want full screen window, but full screen.

Better to just have your stuff stretch to fill the larger full screen window.

Sorry for the delay in getting back to everyone.

Here is the init code for the game.

I've added the before and after screen shots. You can see the display size does get bigger but the components of the screen remain the same size.
On an A4 game (as I remember) I changed my game from WINDOWED to FULLSCREEN and the writing / images changed with the screen size. Again, I believe it reset the screen resolution so the 640x480 was full screen or a window on a 1920 x 1200 screen.

Thanks

I should note that if you use the native resolution and hz, FULLSCREEN is no problem. The only problem with native fullscreen is the destroy create window routine.

Like we said before: you have to destroy the current display, change the new display flags, create the new display

Don't do this if you have a bunch of events. Make sure all events are cleared first. Or if you do, then immediately flush event queue. Might have events using previous display and we don't want that.

Here, I made it slightly easier

Or how about you set what you want

Yes and no. It's a hurdle you have to jump. I find it superior to A4 even if a little more cumbersome. It helped that I was already pretty fluent with A4 and had been using for years. I was on the fence and decided to switch to A5. To do that, I remade a game I made in A4 to A5 as a learning tool.

Points:
A4 is not updated.
A5 has been out for over a decade now. Has OpenGl/Direct3D builtin which give you hardware accelerated drawing from the start.

As to your issue:

Stretch it.

Make a buffer 640,480. Draw all things to buffer unstretched.
Stretch buffer to display. Then it doesn't matter if fullscreen or windowed and you can use allegro_fullscreen_windowed.

Edgar,

I just chose 640x480 when I was experimenting with writing in A5. After I got the program working well enough along with my grandson's request, I wanted to go larger. I just didn't want to re-write the graphic locations, sizes, and mouse reaction locations. So I was hoping, like A4, I could set the graphics mode instead. Given that's not easily possible and the game is pretty simple, I'll just re-write. I was really just thinking of the future should I get in a similar situation.

Daniel gave me some good direction, that I may hold on to for the future but may be a little complicated for such a simple game. Thanks anyways Daniel.

I did try al_set_new_display_flags(ALLEGRO_FULLSCREEN) but it stops the display from initializing. If I do RESIZABLE or FULLSCREEN_WINDOW it functions fine, just doesn't do what I was hoping it would do.

To toggle fullscreen and windowed modes in Allegro 5, use al_set_display_flag with ALLEGRO_FULLSCREEN_WINDOW. Remember to adjust your display's resolution and adapt your drawing logic accordingly for each mode to maintain proper rendering of game elements. Implement a UI element for user-initiated mode changes. you can learn more at: https://fifaapk.com/

Use the function al_draw_scaled_bitmap to apply the proper transforms.

// buffer is your bitmap (640,480 or whatever you need)
// target is current target which should be display's backbuffer.

al_draw_scaled_bitmap(buffer, 0, 0, al_get_bitmap_width(buffer), al_get_bitmap_height(buffer), 0, 0, al_get_bitmap_width(target), al_get_bitmap_height(target), 0);

Hey amelia, I missed your input. I'll check it out. Thanks

Edgar, why read the manual when you can talk directly with the people who wrote the manual . Seriously, I could do a better job of reading up. However, I do often "google" my problem first, but MAN pages giving a description of what a command does isn't nearly as helpful as a brief tutorial approach to a command.

Example,
al_flip_display

void al_flip_display(void). Copies or updates the front and back (doesn't tell how) buffers so that what has been drawn previously on the currently selected display becomes visible on screen. Pointers to the special back and front buffer bitmaps remain valid and retain their semantics as back and front buffers respectively, although their contents may have changed.
Several display options change how this function behaves: etc etc.

See also: al_set_new_display_flags, al_set_new_display_option. I can start down this rabbit hole of links to links to further links.

My question that it doesn't answer is will this command allow me to chose which display I want to flip?
Like maybe al_flip_display(BUFFER)' or al_flip_display(DISP);

My confusion with Daniel's example is I don't al_draw_ to a given ALLEGRO_DISPLAY*. Since I was only using one, I assumed all my al_draw commands were drawing to the only game in town. Now that I'm generating a second one as a buffer, how to I draw to buffer, al_draw_scaled_bitmap from buffer to disp and flip the disp (not the buffer)?

You have a valid point in my case, I do often go to the path of least resistance, but in my defense, Some of the MAN pages aren't written for novices. IMHO

Now your talking Daniel. So simple even I can follow. Of course that doesn't mean I won't have further questions on the topic

** UPDATE ** See told you. I'm at a loss on "target" I understand target is a bitmap and buffer is a bitmap and display is a display. However, if we are not drawing to target, why is it needed or why do I need to switch back and forth? Can't I just draw to buffer, send it to display and then flip?

Thanks Daniel. I get it now, or at least in my trial and error. You can't al_draw_scaled_bitmap a bitmap that is still the target. I couldn't get it to work until I did as you said and created a second bitmap to revert back to prior to my al_draw_scaled_bitmap command.

It visually works fine. The down side is my mouse positions are way off. Example, I have a "Play" button at 489 x 343 to 575 x 379. My program looks for the mouse to be somewhere within that boundary while the mouse button is down. With the stretching, my "Play" button is closer to 1300 x 700 to 1380 x 736 . So while I've solved my graphics enlarging issue, I still have the mouse Key Down location issue. Still it's been educational. Thanks for all the help.