During development of my Clockwork Game Jam 19Q2 entry (Using SDL2), I have come across an input issue, but am not sure if it is an SDL issue or a GameShell hardware issue.
I am trying to detect the state of LShift / RShift keys for some input in my game, and while this works on the builds for my PC (the application is properly receiving SDL_SCANCODE_LSHIFT and SDL_SCANCODE_RSHIFT), when I run a build for GameShell, the shift key is not being detected as either LSHIFT or RSHIFT and the state remains as unpressed.
Has anyone seen this issue before? Is it possibly an issue with the GameShell keyboard firmware not actually sending the LShift or RShift scancode? I am doing some digging, but thought I would throw this up here if anyone else has already encountered this and has any information.
Just took a look at the Arduino keypad driver code, and sure enough, it doesnât actually send a scancode for shift, it just has mappings for what shift + another key should be.
So basically, shift cannot actually be used⌠Sad.
Thank you for that post, unfortunately I did want to use the actual shift key, which as I found above, and you said, is not possible with the current GameShell keypad driver, and is not likely to change. Iâll just have to change my controls
Well the lightkey module just extends the keypad, and the driver maps 2 pin inputs to âshiftâ (Shift and LK3), and since the keypad driver never sends the scancode for lshift or rshift, it canât be a real shift.
we need a better keypad driver, but as the time advance and homebrew release count go up it will become a real mess for compatibility in the future if we change it (or we need write also a soft live event patcher)
itâs a bit like my thread about gameshell future ecosystem, changing the way things work must be done quickly for a massive adoption, handle some variation cannot be viable in the long run, community must speak and made choices now.
I ran into this issue also, but I didnât think much about using the Shift key by itself in my game. My issue arose when I realized the light keyâs overlapped the shifted face buttons. That limited my original plan for button layout, and makes it feel like I lost 4 options for input.
I agree it would be a lot nicer if every button simply acting as single keys on a keyboard instead, and we could just handle âshiftâ in our game code however we want to.