SHIFT key input dropped

[connorjclark]

Previous to this change https://github.com/NewCreature/Allegro-Legacy/commit/4b904126a76ca5c394273586c1229dbcf1cea50a , the shift key was processed correctly. With the current code it is never read by a4 system as a key press. I simply changed -1 to 0 and it worked again (and CMD continue to work). Not sure if that breaks other stuff

[connorjclark]

alright so that breaks arrow keys (seems to process ~twice for each input). Here's what I ended up with:

if (event.keyboard.keycode >= ALLEGRO_KEY_MODIFIERS || event.keyboard.keycode == ALLEGRO_KEY_COMMAND)
{
    if (event.keyboard.keycode != ALLEGRO_KEY_CAPSLOCK)
        _handle_key_press(0, a5_keyboard_keycode_map[event.keyboard.keycode]);
}

I'm not expert in key events, but seems to work well

[NewCreature]

Does the shift key put a key in the key buffer with Allegro 4? Is the issue with keypressed() not being triggered with the shift key?

In Allegro 5, some key presses will generate both a KEY_DOWN and KEY_CHAR event. The KEY_DOWN events are the events we need to use to modify the state of the key[] array. KEY_CHAR events should be used to put keys into the key buffer.

I believe my thinking with the original implementation was that all keys below the modifiers would trigger changes to the key[] array through the subsequent KEY_CHAR event. This turned out to not be true with the CMD key and maybe others that just haven't been noticed yet.

The current code is a more clear and correct way of handling key presses with regard to the key[] array. I would rather add exceptions in the KEY_DOWN event handling for specific keys that trigger keypressed() in Allegro 4 that don't generate KEY_CHAR events in Allegro 5 (assuming your issue was with keypressed()).

I'd like the implementation to mimic the behavior of Allegro 4 as close as possible.