Hi All! I've released an alpha of my indie game Isomer yesterday and am having some bug reports of users being unable to use the fullscreen mode.

In both cases the users have multimonitor setups (but this can't be the root cause as I've tested on a number of dual monitor setups myself including my dev machine without problem).

Here's the problem as described on my forum:

When I start the game, Isomer appears in the task bar,
but nothing else happens. If I click somewhere the screen
flashes black fast, same way as any fullscreen game would
if you alt+tab out or in of a game. Mouse cursor also jumps
at center of the primary screen.
If I attempt activate Isomer by clicking it from task bar a
small black box appears at top left corner of the primary screen.
I tried also to use only one screen, by disabling either
primary or secondary screen, but it had no effect.

How hard would it be for you to support ALLEGRO_FULLSCREEN_WINDOW? It is going to give you the best compatibility, but you'll need to do the scaling yourself since the resolution will be dependent on their current desktop.

I've run into buggy behavior with allegro and the various fullscreen options. The one that still evades me is when no multi-monitor is setup, the primary display is driver 0 (makes sense). When a monitor is plugged in, the primary display is driver 1 and the secondary display is driver 0.

I was looking at ALLEGRO_FULLSCREEN_WINDOW, I'll probably look to give this a go if it's likely to fix the issue.

The other point is that I was a little behind on Allegro library versions when I released. I was using 5.0.5 (which I noticed was quite old actually) whereas the latest is 5.0.10. I didn't see anything obvious in the changelog which would indicate this had fixed the problem however

.. however it does mean that initialization did complete i.e. al_create_display didn't return an error condition.

Annoyingly in the build of the allegro library I'm using (from https://www.allegro.cc/files/) the pdb files don't match up to the binary I distributed so I can't see what's going on from there, but it appears from the call stack that Allegro gets stuck waiting on an _NtWaitForSingleObject from a call in d3d9.dll (see image)

I tried to earlier but the pdb files from allegro-5.0.10-msvc-10.0\lib seem strange (see screenshot). There isn't one for the dll in the stack trace and they all have -debug appended for some reason. I did try renaming allegro-5.0.10-md-debug.pdb to allegro-5.0.10-md.pdb but visual studio wasn't happy with that..

I take the point as the compiler does tend to bend the code a bit, however it is more common to keep the PDBs for release mode binaries. How else do you track down issues 'in the field'? Previously where I've worked we've used the release generated PDB files to good effect to track down all sorts of issues.

Since the files are generated at build time irrespective I would move to have them zipped up and distributed too.

This is a bit of a sticking point for me because I don't really want to distribute debug builds because of performance issues to players, nor do I really want to code around the issue (but thanks to NiteHackr who provided some sample code for me to look at) unless I have to in case it turns out to be a quick fix in Allegro that could benefit all users of fullscreen mode

Any idea about how long it might take for an Allegro developer to fix this? Unfortunately I don't have enough experience with D3D currently to take the job on myself...

I'll try on my multi monitor setup today. If I can reproduce it I might be able to fix it. If not, we're going to need a better trace. For that you'll either have to track down Michal Cichon who builds the binaries, or build binaries yourself.

EDIT: Can't produce the problem here. Are all the affected users running Vista? Which graphics hardware?

EDIT2: If you send me a copy of the game or something that produces the problem, I can try again. It could be discrepancy between Allegro libraries or something.

EDIT3: Was Allegro built with WANT_D3D9EX? Might have to ask Michal and try the opposite setting.

I'm using a multimonitor setup on at two test machines including my dev machine, plus at least two testers used multiple monitors without seeing the issue. That said at least four people on my forum are experiencing the issue, I'm waiting to hear back as to what hardware they all have but I'd guess it would be fairly different. We will see!

Trent: Send me a mail to konrad@ionisingsoftware.co.uk and I'll send you a build key to test

Sorry for the delayed reply.. timezones! I've replied to your email with the details. I'm not sure if it helps but I received this further information from a player:

I found a workaround how to get the fullscreen to work (in my case). Seems that Isomer doesn't like my screen's native resolution 1920x1200. If I drop the resolution to 1920x1080, or anything lower the fullscreen mode works fine. 1920x1200 gives still the black box. 1680x1050 gives also black box.
Here's my setup:
Two 24inch screens (HP LP2475w and Dell U2412M), both using 1920x1200 resolution.
both screens connected to EVGA GeForce GTX 580
Asus P8Z77-V motherboard
8GB RAM
Windows 7 x64

Although I tried a range of resolutions in my monitor including 1680x1050 (my monitor doesn't go higher than 1920x1080 sadly) without problem, so this seems to raise more questions than answers..