Windows (XP and 7 tested):

This is somewhat strange, I was just debugging to find out why the Printscreen key does not trigger a screenshot any more (worked with AL4.4). So far I found that the system doesn't even send out a WM_KEYDOWN or WM_SYSKEYDOWN message, only a WM_KEYUP message for the Printscreen key.

Is this known? Bug in AL5? Bug in Windows? Is it a viable workaround to generate the missing key down event? Where would that be implemented - deep in AL5 or better outside (which would be alguichan in this case)?

Thanks in advance...

http://www.allegro.cc/forums/thread/607535

SDL 1.2 has same behaviour, and its source code has the following comment for DirectX implementation: "Windows only reports keyup for print screen".

As I understand it, it's in the logic of passing an event from the most general handler to the most specific, stopping when it's handled at any level. Here, the explorer process (that handles the desktop stuff) has a defined behavior for printscreen, so it judges that no application window needs the keypress.
It's the same behavior for Alt-Tab, Windows+E, Control-Esc...

Does it really work in 4.4, I'd imagine the message loop code and that in 5.0 is based on the 4.2 code? Maybe it works in fullscreen mode only?

Keyboard code (Windows) seems to be quite different between AL4 and AL5.

So in 4.4 it seems like using DirectInput, and as I just verified, a key press of the Printscreen key is properly detected and working.

In 5.1 the input relies on the Windows event queue, and there it seems that the key press does not generate a Windows event (probably because there's some handler making the screenshot that consumes the event or so), but the key release is properly distributed as Windows event.

So if 5.* remains like this, I'll have to find some other way, e.g. generate an additional key-down for a Printscreen key-up or so, or simply use a different key.

Edit: Just checked, it doesn't work with fullscreen either.

If you really need the printscreen keydown event, you can use my slightly outdated attached patch. It just switches Allegro to using raw input for the keyboard. Raw input gives more or less the same behavior as DirectInput, but still uses the regular window message loop.

Thanks. I'm not sure if I want to sit on a patch that probably won't be integrated into allegro, so what I'm doing now is this: I have in my gameloop one section that takes allegro events and pushed them to alguichan, so I have added some code there to create additional events for key-down and key-char in case of Printscreen. With that it works nicely again, plus I have added the F12 key to make screenshots, too...

Tobing - you should post the code you used to generate key down and key char events for the print screen key. I'm sure other people would find it useful.

Here you are:

On the other hand, if this is a common problem, it might be worthwhile to "repair" it in allegro 5.

No offense intended here, but this is something that worked before and now does not, so as a customer I might say it broke...

Your refund is in the mail. I've included a copy of SDL on CD-ROM.

Thanks a lot.

That's not what I meant however...

I really like allegro 5 much better than allegro 4, which I like a lot. Just two little things which have changed that bother me a little, and this is one of them. Without doubt there was a good reason to change the handling of keyboard input for allegro 5, maybe if someone explains that things become clearer? What are the advantages of the current implementation and what might be the advantages or disadvantages of using raw input as torhu's patch does?

I suppose that if an application/service produces keyboard events (ex: joytokey, my tablet's "macro" buttons, etc.), a game that relies on raw input won't "see" them.

Is it possible to listen to both messages and then use the raw input only for the print screen key but nothing else?

Yeah, I think you can use both. When you enable raw input, you can choose to disable regular key up/down messages or not.

By the way, DirectInput seems to give the best of both worlds, I don't know why that wasn't used for A5. Probably because it's more painful to work with or something.

I think I read somewhere that DirectInput basically is a wrapper for raw input, but I might be mistaken. If it is, there might be a way obtain the remappings that would have been applied for regular key up/down messages. Because the remappings are definitely working in Saucelifter, which is a 4.2 (or 4.4?) game.

I've attached two small test programs (source and binaries) I used for testing this stuff. key_input is WM_KEYDOWN and friends, raw_input is... you guessed it

I could swear we tried using Raw Events and or DirectInput at one point, and it broke more things than it fixed.

There was this discussion that mentions raw input. I guess there could have been older discussions, but I wasn't involved at the time, so I don't know.

What would be the advantage of DirectInput then if it's just the same as raw input but a more painful (I wouldn't know, you said it) API?

I think the reason we need WM_CHAR is to handle things like Chinese or Japanese input methods - anyone knows if those work with DirectInput?

Raw input is newer, and probably wasn't around for Allegro 4.x.

A5 doesn't use WM_CHAR at all. Don't know why.

EDIT: DirectInput creates a separate thread for input processing, maybe that was a reason not to use it for A5.

I recently discovered that allegro can't read the key combinations that I wanted to use in my game. I wonder if this DirectInput business would fix my problem as well as the printscreen problem.

I wanted to use shift + the number pad. For example, num_4 would mean walk left, and shift + num_4 would mean run left. Unfortunately, when I press shift + num_4 allegro doesn't give me those keydown events, but instead gives keydown left-arrow.

I was somewhat resigned to the idea that this is an unfixable problem caused by Windows... but now, is there a glimmer of hope?

When you press the shift key plus a numeric keypad key, you get the arrow key function. It's like if you turn off num lock. Windows makes it possible to differentiate between those arrow keys and the other arrow keys, but Allegro doesn't.

Does this work with Allegro on other platforms?

In X11 it works, but they have a very simple keyboard model. The kernel reports a HW key press/release and in response X11 reports the press/release. For which Allegro in turn creates an ALLEGRO_EVENT_KEY_DOWN/ALLEGRO_EVENT_KEY_UP event.

It's also quite easy to get unicode information in X11 - if a key press or sequence of key presses is supposed to generate a unicode symbol that is reported by X11. And Allegro in turn creates an ALLEGRO_EVENT_KEY_CHAR.

I think using keypad keys with shift is asking a bit too much. Any other key than shift would be fine, but shift together with a keypad key is supposed to give you the arrow function of that key. XT keyboards didn't have the dedicated arrow keys, that's why it works like that.

Windows even sends a key up message for the shift key before sending the arrow key message, then a key down again. So it's actually impossible to do this. Unless you use raw input. But your game would probably break on some other platform if you rely on this anyway. Not to mention it would suck on laptops that don't have a numeric keypad at all.

EDIT: For future reference: This is applies when using raw input, and NumLock has to be on. If you press a numeric keypad key while holding shift, you get two key down events for that key, and then two key up events. Which makes those key combinations pretty much unusable. Turning off NumLock is the only workaround I've found.

I think Allegro needs to provide the 2 different kinds of data:
- low-level: "Alt and E are being pressed"
- higher-level: character "€" is typed

The first is required for games that use the keyboard as a 100-button controller, and it should try to be as rough and close to physical reality as possible. Of course each game should provide configurable controls, since even at runtime you can't know which keys are physically present and how they are laid out.

The second for text input and human-oriented shortcuts, such as an in-game editor that would use Control+Z for "Undo", adapting to the physical location of the key "Z" on QWERTY, AZERTY, QWERTZ keyboard.

Doesn't it?
I thought that was what KEY_UP/KEY_DOWN vs KEY_CHAR was for...

Yes, the API does. It just seems neither the Windows nor OSX implementation implements it properly right now.

I have some time on my hands now, so I can try to fix it on the Windows side. I think there are a couple of obvious things to do:

1. The numpad keys should give the same keycode no matter if Num Lock is on or off. This is how it works in A4, and I assume people would generally want it this way for games. The keys would of course still send different character events depending on the state of Num Lock.

   
   

2. The event.keyboard.modifiers field should reflect the actual state of Num, Caps, and Scroll Lock. Which means that the state has to be set at initialization time, and at switch ins.

   
   

3. When the display has lost focus and then regains it, the keyboard state can easily get out of sync with reality. A4 clears all keys on switch out, and then just updates the 3 Lock keys on switch in. I can make A5 do the same, and additionally send key up events for all keys that are down when the switch out occurs. Or maybe I'll do a complete state update, if it's not too much trouble.

I don't know if those 'fake' key up events are always desirable, though. Any thoughts on that?

Is there anything else that's missing? And is this in line with the other platforms?

I think Pete Hull looked into the OS X implementation and concluded that the way it works now is the best that can be done there. I don't remember the details though.

I did item 1 and 2. 3 I'll have to think about some more. I'll post patches in the newsgroup.