|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| [AL 5.1 SVN] PRINTSCREEN key does not generate key down message |
|
tobing
Member #5,213
November 2004
 |
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... |
|
Matthew Leverton
Supreme Loser
January 1999
 |
|
Audric
Member #907
January 2001
|
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. |
|
torhu
Member #2,727
September 2002
 |
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? |
|
tobing
Member #5,213
November 2004
|
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. |
|
torhu
Member #2,727
September 2002
|
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. |
|
tobing
Member #5,213
November 2004
|
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... |
|
Edgar Reynaldo
Major Reynaldo
May 2007
 |
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
tobing
Member #5,213
November 2004
|
Here you are: 1 gcn::Allegro5Input input; // this is where events are pushed to, for further consumption
2
3 bool have_seen_printscreen_keypress = false;
4
5 while(true)
6 {
7 ALLEGRO_EVENT event;
8 while(!al_is_event_queue_empty(g_event_queue))
9 {
10 al_get_next_event(g_event_queue, &event);
11
12 if(event.type >= ALLEGRO_EVENT_KEY_DOWN && event.type <= ALLEGRO_EVENT_KEY_UP)
13 {
14 if(event.type == ALLEGRO_EVENT_KEY_DOWN && event.keyboard.keycode == ALLEGRO_KEY_PRINTSCREEN)
15 {
16 have_seen_printscreen_keypress = true;
17 }
18 if(event.type == ALLEGRO_EVENT_KEY_UP && event.keyboard.keycode == ALLEGRO_KEY_PRINTSCREEN)
19 {
20 if(have_seen_printscreen_keypress)
21 have_seen_printscreen_keypress = false;
22 else
23 {
24 ALLEGRO_EVENT down_event;
25 memcpy_s(&down_event, sizeof(down_event), &event, sizeof(event));
26 down_event.keyboard.repeat = false;
27 down_event.type = ALLEGRO_EVENT_KEY_DOWN;
28 input.pushInput(down_event);
29 down_event.type = ALLEGRO_EVENT_KEY_CHAR;
30 input.pushInput(down_event);
31 }
32 }
33
34 input.pushInput(event);
35 continue;
36 }
37 else
38 {
39 // handle other events
40 }
41
42 // remainder of game loop
43
44 }
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... |
|
Matthew Leverton
Supreme Loser
January 1999
|
tobing said: 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. |
|
tobing
Member #5,213
November 2004
|
Matthew Leverton said: 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? |
|
Audric
Member #907
January 2001
|
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. |
|
Elias
Member #358
May 2000
|
Is it possible to listen to both messages and then use the raw input only for the print screen key but nothing else? -- |
|
torhu
Member #2,727
September 2002
|
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 |
|
Thomas Fjellstrom
Member #476
June 2000
 |
I could swear we tried using Raw Events and or DirectInput at one point, and it broke more things than it fixed. -- |
|
torhu
Member #2,727
September 2002
|
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. |
|
Elias
Member #358
May 2000
|
torhu said: 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. 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? -- |
|
torhu
Member #2,727
September 2002
|
Elias said: 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? Raw input is newer, and probably wasn't around for Allegro 4.x. Quote: 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? 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. |
|
Karadoc ~~
Member #2,749
September 2002
 |
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? ----------- |
|
torhu
Member #2,727
September 2002
|
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? |
|
Elias
Member #358
May 2000
|
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. -- |
|
torhu
Member #2,727
September 2002
|
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. |
|
Audric
Member #907
January 2001
|
I think Allegro needs to provide the 2 different kinds of data: 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. |
|
Evert
Member #794
November 2000
 |
Audric said: I think Allegro needs to provide the 2 different kinds of data:
Doesn't it? |
|
Elias
Member #358
May 2000
|
Yes, the API does. It just seems neither the Windows nor OSX implementation implements it properly right now. -- |
|
|
1
2
|
