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.

So I'm at a bit of a loss.. needless to say the error handling part of the code doesn't trigger so it would appear al_create_display worked.

Any ideas anyone?

Matthew Leverton

Seems like a bug with Allegro (D3D) or the person's graphics drivers.

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.

jmasterx

For the scaling, just use transformations to simulate the desired target resolution from the native resolution.

This way, regardless of the user's resolution, it will always feel like a given resolution.

This is what I do. I find ALLEGRO_FULLSCREEN buggy. Not necessarily Allegro's fault, but D3D has a lot of fits when it is asked to go fullscreen.

Mark Oates

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.

Ionising

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

NiteHackr

Matthew created a nice function for scaling the screen for fullscreen window that works really well...

.. 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 know very little about D3D but, that seems like some weird issue where allegro is waiting on a D3D object event while setting up a mode, which isn't firing.. hmmm.

If at all possible, a proper full trace would be very helpful.

Ionising

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 imagine to use those you need to link to the debug libs and release that to testers? That would also get you allegro.log.

Ionising

Oh interesting, could you explain more? Only a few players get this problem, I can't reproduce it on my test machines and I don't really want to distribute debug code to players

Why are the release pdb files not bundled out of interest?

Thomas Fjellstrom

I'm pretty sure release pdb files would be pretty useless because the release version would have far less useful information in them, and optimized code would make things interesting.

But we might be able to convince the msvc builder guy to make those files for the release libs as well..

Ionising

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...

Trent Gamblin

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.

Edgar Reynaldo

Are you compiling as a GUI application? And have you tried setting the window position after creating your window? Sometimes they appear offscreen and not visible yet.

Ionising

Ok some progress, a really awesome user swapped out the release library with the debug version and sent me the Allegro log files and a dump file I could open fully.

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

I wonder actually whether the game is running normally in the background and simply failing to render...

Not received your email yet for some reason but will send you download details when I do.

Trent Gamblin

My first email bounced and I sent another. Did you still not get it? I can send from another email address...

Ionising

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..