I am not certain if there is something I am missing, or if this is a bug with Allegro 5? I am using 5.1.11, all works fine (I am really loving it!). My game is in the final stretch, I am just bug testing it now to see where problems might exist. I easily swatted quite a few of them, but one.

I was testing out switching back and forth between different modes, from windowed, to full screen windowed and back, also windowed to regular full screen and back. When I click the close button in windowed mode, works no problem, triggers the event. BUT, if I switch to regular (non-windowed) fullscreen mode, then I switch back to windowed mode from it, the close button no longer responds. All other input works just fine. If I switch to<->from fullscreen Windowed mode, no problem, close button triggers. It's just fullscreen to windowed that stops it.

Otherwise my game runs perfectly fine. This, to me is a minor issue, but I just know SOMEONE that plays my game will report it as a problem. Now, if you exit the game and rerun it, with windowed mode now the default when you restart the game, no problem, close button works again. So something gets disabled for that when fullscreen mode is enabled in Allegro.

If it's a bug, I'm reporting it now. If not, what can I do to reset this?

The close button works under normal circumstances. But if your program is in fullscreen mode, then you switch to windowed mode while the game is running, then it won't work.

I'll see if I can whip up a simple program to demonstrate this. I am using Allegro 5.1.11 with Windows 7-64bit (the program is 32bit) compiled with MinGW 4.8.1 (Code::Blocks IDE).

I basically discovered this while bug testing my game, it's not something I probably would have ever noticed otherwise.

Edit: Okay, I just created a test program which does the bare minimum, it creates a fullscreen display, then destroys it and creates a windowed mode display and that closes okay, so I am a little confused as to why it would stop playing in my game. The event is simply not coming up, I wonder if I might need to re-initialize the event handler when I change the display. <shrug>

Edit2: Okay, solved the problem. The event queue is registered with the following...

al_register_event_source(event_queue, al_get_display_event_source(display));

So when the display is destroyed and re-initialized, I need to register the event queue again as well. I should probably be careful to destroy the event queue at the same time I destroy the display as well. nope, destroying the event queue crashes the program, so just re-registering the display is needed. Otherwise, when a new display is created without initializing the event queue again, the close button will stop working.

Ah, right! I forgot to unregister it, thanks, I'll add that in. Otherwise my game is complete. I just got done more bug testing, this was the last major bug there was (this and some other missing code to handle the close button on various screens).

Edit: That worked. I unregistered it. I realized I shouldn't be destroying the event_queue, but only unregistering the display before I destroy the display. I then register the display again with the event_queue after I recreate it. All is working smoothly with this anyhow, thanks. I've only done basic work with the event queue, being used to the old Allegro 4 state machine. So this has been a learning curve, getting used to remembering to do these sorts of things has been helpful.

If you destroy the display first, it'll detatch itself from the queue, so everything should be fine. The crash probably has a different source.

But yes, if you re-create the display, you'll want to re-register it with the event queue.

Yeah, I usually do shut down in reverse order. I don't even know why I tried to destroy the event queue when all I wanted to do was unregister the display. Brain must have frozen up at the time or something.

But why it crashed, I am not certain, if everything said is true, than that is strange. But it works now and I am finally about done with that game, ... I want to move on to something else but I vowed not to start a new project until I finished this.

Yet another Deluxe Pacman game. ... it was an idea about a remake I was interested in like... 6 years ago... and have fiddled around with on and off since then. I wanted to remake the original because it was started in the 1990s on... Allegro 2 I think, and updated since.

It's nothing fantastic, but it runs. My Deluxe Pacman 1 game still gets thousands of downloads a month from one website out there (lots of people in South America eat these sort of games up, so, there's a market for you people).

Anyhow, here's the download as it is now, compiled with Allegro 5.1.11, with level editor etc. Programmed with CB + MinGW 4.8.1 in pure C (2011 standard).

http://home.cogeco.ca/%7Edeluxe.pacman/zips/DPacman2_2015JUL04.zip

Edit: The display problems were mainly with going into the OPTIONS menu and changing the video mode, usually from FULLSCREEN to Windowed which lead to the close button not working. No big deal really, but now it works. Changes resolutions right away and saves that for the next time it is run. It has Windowed, Fullscreen-Windowed and Fullscreen modes.

Yeah, my libs depend on OpenAL. There's no static version of OpenAL that I could build. Here's the OpenAL32 dll :
https://www.allegro.cc/files/attachment/609574

Not with cmake. And I don't use MSVC.

Hmmm, I don't get that problem on my system and I don't have the dll in my path, or at least I didn't think I did. Obviously I do! Can I recompile the game without the need for it? It's strange this is the first time anyone has even told me about that. Could be just 5.1.11 it is missing as before I used 5.0.8.

Thanks, the level editor is the first thing I create when I start making a game and I wanted to make certain that if a level was loaded, there would be nothing missing and no potential errors so the validation checks for everything. If you have a spot to wrap around on one side, but not the other, it will point it out to you. If you have pills in spots on the map that the pacman cannot get to, it will mark the areas that are blocked off (I used the ghost path finding function to actually test this, which works nicely) etc... you name it, it will probably test for it. Unvalidated maps will not load into the game. So it's a nice idea I felt. I actually got the idea for drawing a map like that (rather than a piece at a time) from SimCity 2000! The way you draw your roads, if you ever played it you will see how it autoconnects roads up, so I thought, hey, why can't I use that for lines, and of course, most levels I like symmetrical, so no sense in repeating drawing when you can have the editor do it for you.

There's still some things I want to change in it, like the ability to just put down ONE piece and not auto-connect it, for certain map ideas. Plus I am working lately on making the level editor remember the name of the level file you loaded so when you save it, THAT is the default name.

I guess the reason why the level editor works is because I have no sound effects for it. I was going to but just never got around to it.

Edit: Okay, I recompiled the game, fixed that problem in the level editor so now it remembers the filename for the level you load. The installer now installs the OpenAL dll into the game's main folder. So it SHOULD work now (famous last words)...

http://home.cogeco.ca/%7Edeluxe.pacman/zips/DPacman2_2015JUL08.zip

The error with OpenAL is gone in this version, but now it can't find "libgcc_s_dw2-1.dll". I'm at my work computer, so I don't have GCC installed here (and even on my private computer, I think, I don't have, since I'm using the Visual Studio compiler for Allegro). I guess the GCC libs probably weren't linked statically correctly. I think I had this kind of issue before when working with Allegro and actually using GCC, but I'm not sure how I solved it back then (or if I solved it at all).

EDIT:
One thing that could really enhance the editor would be an undo command. When using it, it should basically undo everything that happened between the last mouse key press and the last mouse key release. I've had it happen various times now that I had to switch back and forth between different objects because my sensible mouse made me draw something I didn't want to.

YAY, IT'S WORKING NOW!

Although it glitched quite a bit on my first attempt. When starting the game - it automatically launched in fullscreen mode - the game forced intself into the background/minimized itself. When going back into the game, it for some reason ran really, really slow (as in, 1 frame every few seconds). I switched out of the game and back in again (with Alt + Tab) and for some reason the game now was completely black aside from the mouse cursor (the sound was already playing, though). Switched back and forth a few times, but the game stayed black. I decided to close the game and restart it and finally it worked for me and ran smoothly (this time it didn't minimize itself on startup). I don't know, what was going on there, but I guess I can just switch into window mode to prevent this problem.

Yeah, I figured this out, because naturally, at some point I asked myself how to remove pieces again and just tried the right mouse button. Didn't know about the mouse wheel, though. Going to give this a try.

EDIT:
Apparently the slowdown in the game starts whenever it minimizes itself during startup. It just happened again. I don't know, why it keeps minimizing on startup, but I'd guess that it's not the game's fault, but my computer's. More accurately, I think it might be the fault of BlueStacks App Player. If I remember correctly, I've experienced it forcing itself into the foreground quite a few times when trying to start other games in fullscreen mode. With said other games it never caused the slowdown, though. Those games usually worked fine after switching back into them.

EDIT:
Also, you confused fullscreen and fullscreen window in the options. The game on my PC actually starts in fullscreen mode, but is set to fullscreen window in the options. This may be one of the reasons why it glitched up.

As I tried to explain, the game was pushed into the background right when starting up (that is, the monitor switched into fullscreen mode for a brief moment and then right back to the desktop). Maybe the time at which this happens is actually important. As in: Maybe the glitch doesn't occur if you switch to another task after the game has already started properly. Can't tell for sure, though, this is just speculation. It might just happen on my computer after all. In any case, it's not a big deal to begin with and I am probably the only person to ever experience this glitch, anyways.

Oh, I think I didn't explain what I meant well enough. What I meant was that these glitches were probably caused by the game running in regular fullscreen mode instead of in a fullscreen window. Fullscreen mode is actually known for its ability to cause trouble in some games on some PCs (thanks to losing contexts, switching graphics cards settings and stuff like that). That is why, generally speaking, fullscreen windows are the preferred way of handling fullscreen applications nowadays. Maybe you should just make fullscreen window the default option, I can imagine that to already solve the problem. Then again, fullscreen windows might have their own problems, I don't have enough experience with that.