Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Problem with fullscreen reported by some users

This thread is locked; no one can reply to it. rss feed Print
Problem with fullscreen reported by some users
Ionising
Member #14,522
August 2012

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?

Matthew Leverton
Supreme Loser
January 1999
avatar

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
Member #11,410
October 2009

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
Member #1,146
March 2001
avatar

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
Member #14,522
August 2012

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

Neil Roy
Member #2,229
April 2002
avatar

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

a5_scale_screen.c

#SelectExpand
1// Scale Screen: 2// Sets up transforms in order to fit any resolution 3// onto an ALLEGRO_FULLSCREEN_WINDOW. 4// 5// (Special thanks to Matthew Leverton for help with this!) 6 7#include "a5_scale_screen.h" 8 9 10 11// Use to get mouse position on scaled screen 12float scale_x = 1; 13float scale_y = 1; 14int offset_x = 0; 15int offset_y = 0; 16 17 18 19// usage: a5_scale_screen(BUFFER_WIDTH, BUFFER_HEIGHT, display_width, display_height); 20void a5_scale_screen(int bw, int bh, int dw, int dh) 21{ 22 ALLEGRO_TRANSFORM t; 23 24 // Calculate the horizontal and vertial aspect ratios 25 const float HAR = dw / (float)bw; 26 const float VAR = dh / (float)bh; 27 28 // The aspect ratio, x-offset and y-offset (in pixels) 29 float ar, ox, oy; 30 31 if(bw == dw && bh == dh) { 32 // 1:1, just reset everything 33 al_identity_transform(&t); 34 al_use_transform(&t); 35 al_set_clipping_rectangle(0, 0, bw, bh); 36 scale_x = 1; 37 scale_y = 1; 38 offset_x = 0; 39 offset_y = 0; 40 al_clear_to_color(al_map_rgb(0, 0, 0)); 41 al_flip_display(); 42 } 43 else { 44 // Choose the smaller aspect ratio 45 if(HAR < VAR) { 46 // horizontal bars on the top and bottom 47 ar = HAR; 48 ox = 0; 49 oy = (dh - (ar * bh)) / 2.0; 50 } 51 else { 52 // vertical bars on the left and right 53 ar = VAR; 54 ox = (dw - (ar * bw)) / 2.0; 55 oy = 0; 56 } 57 58 // set the global scale/offset so the mouse coords can be inverted 59 // use the following code to get the proper mouse position 60 // mouse_x = (event.mouse.x - offset_x) / scale_x; 61 // mouse_y = (event.mouse.y - offset_y) / scale_y; 62 scale_x = ar; 63 scale_y = ar; 64 offset_x = ox; 65 offset_y = oy; 66 67 // set up the transformation to scale and translate 68 al_build_transform(&t, ox, oy, ar, ar, 0); 69 al_use_transform(&t); 70 71 // clear out the screen before setting the clipping 72 al_set_clipping_rectangle(0, 0, dw, dh); 73 al_clear_to_color(al_map_rgb(0, 0, 0)); 74 al_flip_display(); 75 76 // make sure nothing is drawn into the black bars 77 al_set_clipping_rectangle(ox, oy, ar * bw, ar * bh); 78 } 79}

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

#SelectExpand
1al_set_new_bitmap_flags(ALLEGRO_MAG_LINEAR); 2al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_INVERSE_ALPHA); 3al_set_new_display_option(ALLEGRO_SINGLE_BUFFER, 1, ALLEGRO_REQUIRE); 4 5al_set_new_display_flags(ALLEGRO_FULLSCREEN_WINDOW); 6 7// Allegro picks the desktop resolution automatically with ALLEGRO_FULLSCREEN_WINDOW flag set. 8screen = al_create_display(WIDTH, HEIGHT); 9 10screen_w = al_get_display_width(screen); 11screen_h = al_get_display_height(screen); 12 13a5_scale_screen(WIDTH, HEIGHT, screen_w, screen_h); 14 15al_clear_to_color(al_map_rgb_f(0, 0, 0)); 16al_flip_display(); 17 18// etc...

Ionising
Member #14,522
August 2012

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

#SelectExpand
1bool CSepiaEngine::BeginGameLoop() 2{ 3 m_pTimerFPS = al_create_timer( 1.0 / m_nFPS ); 4 5 m_pTimerGameLogic = al_create_timer( 1.0 / m_nGameTickRate ); 6 7 m_pEventQueue = al_create_event_queue(); 8 9 if( ! m_pEventQueue ) 10 { 11 ThrowErrorAndQuit( "Failed to create event_queue!" ); 12 return false; 13 } 14 15 al_register_event_source( m_pEventQueue, al_get_display_event_source( m_pDisplay ) ); 16 17 al_register_event_source( m_pEventQueue, al_get_timer_event_source( m_pTimerFPS ) ); 18 19 al_register_event_source( m_pEventQueue, al_get_timer_event_source( m_pTimerGameLogic ) ); 20 21 al_register_event_source( m_pEventQueue, al_get_keyboard_event_source() ); 22 23 al_register_event_source( m_pEventQueue, al_get_mouse_event_source() ); 24 25 al_clear_to_color( al_map_rgb( 0, 0, 0 ) ); 26 27 al_flip_display(); 28 29 al_start_timer( m_pTimerGameLogic ); 30 al_start_timer( m_pTimerFPS ); 31 32 bool fRedraw = false; 33 bool fTickGame = false; 34 35 while( ! m_fQuitOnNextCycle ) 36 { 37 ALLEGRO_EVENT ev; 38 39 // Blocking call 40 al_wait_for_event( m_pEventQueue, &ev );

.. 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"}3fullscreenbug.jpg

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Ionising
Member #14,522
August 2012

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"}allegro10pdbfiles.JPG

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Ionising
Member #14,522
August 2012

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
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Ionising
Member #14,522
August 2012

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
Member #261
April 2000
avatar

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
Member #8,592
May 2007
avatar

Ionising
Member #14,522
August 2012

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"}fullstacktrace.JPG

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

Trent Gamblin
Member #261
April 2000
avatar

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.

Ionising
Member #14,522
August 2012

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.

Trent Gamblin
Member #261
April 2000
avatar

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

Ionising
Member #14,522
August 2012

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

Go to: