Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Windows mouse stops working in full screen

This thread is locked; no one can reply to it. rss feed Print
Windows mouse stops working in full screen
Christopher Webb
Member #8,059
December 2006

Hi, all: I've been beating my head against this bug for several days now in my spare time, and I have exhausted my limited ability to figure this out.

I've got Allegro 4.2.0, Dev-C++ 4.9.9.2, MINGW32 3.4.2, WinXP SP2. I'm working on a object-based version of the Allegro GUI with a number of extensions. I've got a message loop that checks for mouse changes and key presses and pushes them into a message queue. The messages are passed to "state" objects that then pass the messages to "component" objects - conceptually the same as the DIALOG* array.

What I see is that, when I let the program run for a while in full screen mode, the mouse stops responding (the pointer freezes on the screen). If I press CTRL-ALT-END immediately, the app closes up just fine, but if I press a few keys on the keyboard, the app doesn't respond. I get no error messages.

What I'm having a problem with is that it won't happen in windowed mode (I've never seen it happen), and I can't debug it since I can't figure out a way to stop the debugger and get a stack/thread trace - all of my programming experience is in embedded systems, where we don't have this Windows thing. The "hang" doesn't happen consistently - I can run the app for several minutes without a problem and exit normally, or it'll hang within a minute. I've tried it on my home system (AMD 2100+ CPU) and on my workstation at work (dual processor Xeon 3.20GHz) with similar results, although my workstation seems more prone to the hang.

I haven't seen this happen with any of the Allegro example apps, so I assume it's something I'm doing, but I have no clue where to even start looking for the problem, since it seems to be dependent on full screen vs. windowed mode. Any advice is appreciated.

-Christopher

Kris Asick
Member #1,424
July 2001

I have a couple suggestions:

1: Poll the mouse using poll_mouse() in your game loop. This avoids using a timer interrupt which could be being disrupted. (Possible, but unlikely. Either way, it's worth a shot.)

2: Try adding rest(1); into your game loop to give a millisecond of processor time to the OS every frame. I've noticed that this helps I/O issues on my Windows 98 system, perhaps it will help on your Windows XP system? Yes, it does cause processor time to be sucked from your program potentially reducing the framerate, but it plays nice with the OS by allowing it to do some of its tasks which could be being backlogged and clogging things up. rest(0); is supposed to do this without wasting CPU time, but for some reason it doesn't.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Evert
Member #794
November 2000
avatar

It's hard to say with the information you have given... are you running multiple threads at the same time? It almost sounds like a threading issue.
Also, check for any acquire_bitmap()/release_bitmap() calls and see if removing those helps.

Quote:

Poll the mouse using poll_mouse()

Don't. Never use poll_mouse(), it serves no useful purpose.

Kris Asick
Member #1,424
July 2001

Quote:

Don't. Never use poll_mouse(), it serves no useful purpose.

Why not? I use it all the time with no issues, specifically so that I know exactly when the mouse is being updated. That way the mouse state never changes in the middle of calculations which use it.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

BAF
Member #2,981
December 2002
avatar

Quote:

I use it all the time with no issues, specifically so that I know exactly when the mouse is being updated. That way the mouse state never changes in the middle of calculations which use it.

It doesn't even do anything useful AFAIK. And, just because you poll the mouse doesn't mean the state won't change.

Kris Asick
Member #1,424
July 2001

BAF:

Quote:

And, just because you poll the mouse doesn't mean the state won't change.

Does that mean the mouse polling system in Allegro doesn't work or what? ???

As far as I understand it, when you first call poll_mouse() in Allegro, it switches the mouse from interrupt driven to polling driven, meaning that the state variables stored in Allegro only update whenever you call the poll_mouse() command. If the state could change in polling mode without calling the polling command then that would defeat the purpose of polling, wouldn't it?

To quote the Allegro 4.2.0 documentation for poll_mouse():

Quote:

Wherever possible, Allegro will read the mouse input asynchronously (ie. from inside an interrupt handler), but on some platforms that may not be possible, in which case you must call this routine at regular intervals to update the mouse state variables. To help you test your mouse polling code even if you are programming on a platform that doesn't require it, after the first time that you call this function Allegro will switch into polling mode, so from that point onwards you will have to call this routine in order to get any mouse input at all, regardless of whether the current driver actually needs to be polled or not.

Are you saying that this is incorrect?

.Christopher Webb:

Something else you might want to try is if you are using page flipping, triple buffering, or the acquire and release commands is to switch to double buffering, with or without vsyncing, stop using the acquire and release commands by only ever making one draw to screen per frame, then see if that helps. Control lockups with page flipping is another problem I've encountered on Windows 98 with the newer versions of Allegro and I was fairly certain, since no one else seemed to have heard of that issue when I brought it up, that it was limited to Windows 98.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

BAF
Member #2,981
December 2002
avatar

All platforms, IIRC, run the interrupt handler, so the variables are updated as the mouse is moved, not when you tell it to.

But I didn't know about the polling mode thing, so I'm not sure about it.

Christopher Webb
Member #8,059
December 2006

Sorry for the lack of complete details - it's a pretty convoluted chunk of code, so it's a little tough distilling it down to simple pseudocode.

I am using double buffering, with the draw BMP created with create_bitmap (not video memory). The actual draw process is:

DoTheDrawingOntoDrawBmp();
acquire_bitmap(drawBmp);
acquire_screen();
scare_mouse();
blit(onto the screen);
unscare_mouse();
release_screen();
release_bitmap();

I had already tried polling the mouse (by doing a poll_mouse prior to the main loop), and that did not affect the outcome. I'll give it a try without the acquire* calls and see if that helps. I'm also poking around with Allegro GL and finding some problems rendering text there, but that's a different issue :(

Thanks for the suggestions.

Evert
Member #794
November 2000
avatar

Quote:

Why not? I use it all the time with no issues

It doesn't have issues, but it doesn't actually "do" anything and isn't ever needed. It also doesn't work naturally with "event-based" update schemes (which is what most OSes seem to use these days).

Quote:

And, just because you poll the mouse doesn't mean the state won't change.

Read the manual before making a claim about something you don't know about. ;) Or at least say "as far as I know."
When calling poll_mouse() for the first time, Allegro switches into polling mode and you will need to poll the mouse after that.

Quote:

I'll give it a try without the acquire* calls and see if that helps.

You should probably scare/unscare the mouse outside the acquire block in any case. Also note that locking a memory bitmap is pointless and you should only lock the screen if you're doing multiple blits in a row to it.

Kris Asick
Member #1,424
July 2001

Change:

DoTheDrawingOntoDrawBmp();
acquire_bitmap(drawBmp);
acquire_screen();
scare_mouse();
blit(onto the screen);
unscare_mouse();
release_screen();
release_bitmap();

To:

DoTheDrawingOntoDrawBmp();
scare_mouse();
blit(onto the screen);
unscare_mouse();

I don't use the scare and unscare commands for my mouse cursors so I don't know whether or not they're causing any problems, but as far as acquiring bitmaps, you don't need to acquire the screen unless you do more than one draw onto it at a time, and there's no reason to ever call acquire on regular bitmaps. (Only video bitmaps that are going to see more than one command of action in a loop.)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

BAF
Member #2,981
December 2002
avatar

If you just draw mouse_sprite yourself to the buffer and remove your call to show_mouse, you won't even need to scare/unscare the mouse.

Go to: