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.

The person who reported the issue even posted a video of the problem : https://dl.dropboxusercontent.com/u/37902077/isomer/fullscreen_fail_to_start.avi

I'm not doing anything unusual in how I initialse the display:

    al_set_new_display_flags( ALLEGRO_FULLSCREEN );
 
    m_pDisplay = al_create_display( nWindowWidth, nWindowHeight );

    if( ! m_pDisplay ) 
    {
        _ASSERT( 0 );
        ThrowErrorAndQuit( "Unable to create display ..." );
        return false;
    }

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?

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.

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.

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

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

a5_scale_screen.c

a5_scale_screen.h

#ifndef _a5_scale_screen_h_
#define _a5_scale_screen_h_

#include <allegro5/allegro.h>

extern float scale_x;
extern float scale_y;
extern int offset_x;
extern int offset_y;

// usage: a5_scale_screen(BUFFER_WIDTH, BUFFER_HEIGHT, display_width, display_height);
void a5_scale_screen(int bw, int bh, int dw, int dh);

#endif

I used the following commands before calling this function which effects the quality...

Someone who encountered the issue sent me a dump file that I dug into, here's what I could find:

Firstly, it appears as though my game engine is caught waiting for an event which is never forthcoming from Allegro...

al_wait_for_event( m_pEventQueue, &ev );

of course it could just be the execution pointer jumping ahead, here are the calls before this point

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

{"name":"3fullscreenbug.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/f\/ff7ffddfb3a9d6a5237c282026d3b990.jpg","w":550,"h":308,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/f\/ff7ffddfb3a9d6a5237c282026d3b990"}

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.

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

{"name":"allegro10pdbfiles.JPG","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/7\/c74c88759346c50852638eab8c5c5139.jpg","w":626,"h":193,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/7\/c74c88759346c50852638eab8c5c5139"}

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.

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?

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

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.

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.

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.

Here's the full stack trace:

{"name":"fullstacktrace.JPG","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/f\/6fc03bca8f5194807085f0ac3ace79f6.jpg","w":800,"h":296,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/f\/6fc03bca8f5194807085f0ac3ace79f6"}

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 don't know if Allegro was built with this flag I'm afraid, I'm just using the official version from http://cdn.allegro.cc/file/library/allegro/5.0.10/allegro-5.0.10-msvc-10.0.7z .

Logs and dump file : http://www.ionisingsoftware.co.uk/isomer_worklog/isomer_0803_dump_fullscreenissue.zip

The backtrace looks pretty normal. Typically you spend most of your time in al_wait_for_event and that's what's happening here. Nothing unusual in the logs either. I sent you an email.

True.. it's not the wait but the SetRenderState in d3d9.dll that caught my eye. Given that this trace was taken when the game is sitting doing nothing after having failed to create a fullscreen window (instead doing what is shown here : https://dl.dropboxusercontent.com/u/37902077/isomer/fullscreen_fail_to_start.avi ).

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.

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

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