Well I just returned to Allegro after a long period away so this is really jumping in with both feet: I'm getting an intermittent issue with an Allegro app' hanging in an odd way... the program keeps running but ignores the keyboard (can't tab out or anything, and any key being pressed at the time gets stuck as active) and although this will only occur every now and again it's a complete killer when it kicks in.

Oddly, clicking the mouse sometimes seems to restore matters, as if the focus had been lost or something. Anyway, this is with the 4.1.16. devpack via the latest DevC++ - there's a massive, massive chance that I'm doing something dumb but the "bug" being hard to replicate (the same exe will run fine one time then suffer the next) AND being seemingly present in the demo game too makes me think it worth a mention. Maybe my keyboard is just cack.

Other people have mentioned this as well. They seemed to fix the problems by using sleep(1) to restore the input thread.

Could you try that?

You can get older versions from the sourceforge page ([url http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=40805])

It'd be nice if people mentioned the problem and we can try to fix it rather than work around it though (which was sortof the point of this thread).

You might get behavior like this if you acquire a bitmap but don't release it (if it's not an Allegro example program) or it might be the way your system deals with mutex locks (ie. your system lets go of and re-locks the screen bitmap lock before the input thread can be locked to get input). Tthis is an X (and DirectX?) limitation that you can't get input while you have the screen locked. Yielding in the main loop should be just as effective as rest(1) if it's not that you're failing to release the screen.

Here's my fix for allego's windows mouse driver:

The changes:

friendly htm format
txt format

And here's the new wmouse.c file.

If you want to test it, you don't even need to recompile allegro. Just stick the new dll into the same directory as whatever you are testing and it should work. If you downloaded Clovekx's Priority: Survive, then that's a good one to test it on.

I've kept this patch as simple as possible, addressing only the main problem (messed up acceleration scaling) with the old code. So in terms of sensitivity, the mouse movement feels much as it used to.

I have, however, written a slightly more complicated patch which, in my opinion, gives even better results. For the moment I'll just give the simple patch as it's real purpose is to fix a problem, not to tweak the mouse movement to my personal taste.

Cool, thanks!
One thing though: could you generate a unified diff (pass -u) next time? It's generally easier to read.

Would it be a possibility to provide some C++ examples, that would only compile if its a C++ compiler, ofcourse. That way there could be some simple examples for handling units and other stuff in oop fashion. I'd love that sort of thing, but I know there are a few people who arent paticular for C++ very much.

So.. what do you guys think?

ImLeftFooted: Hasn't got anything to do with Allegro... language tutorials are, and should be, a bit beyond the scope of Allegro's examples IMO.

I would like to see the FAQ displayed in a more prominent place in the manual though - even with the updated layout it's still hidden in the middle of a lot of (for the newbie) unnecessary information under the heading of "miscellaneous". Heck, even I have problems finding the link when I'm just skimming the text, and I know where it is .
I'd like to see it moved to say, right beneath "A general introduction to Allegro"...

There is a C++ test/example already. Most of the examples are simple enough anyway that you making an explicit distinction between C and C++ is overkill. Things like managing units more properly belong to a tutorial or demo game.

Makes sense to me.

Yes! I actually have a custom routine that does just that (also takes a printf-style format string). Not sure why I never submitted it. Probably because the code is too ugly or gcc specific.