GameShell + SDL2 Shift Keys

#1

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.

Thanks!

#2

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.

#3

yes you cannot use shift as a single and alone key

check this post for sdl1.2 keycode with all shift combo

#4

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 :frowning:

#5

i never wired the lightkey but the graphic may suggest LK3 as a real Shift key ?

(yet still unusable if it is %)

#6

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.

Ironically, I mapped all of this myself before (https://github.com/Cecilectomy/Alex4_GameSH/blob/master/GameShellKeys.txt) and even noted there were no codes attached to either shift or lk3. I even debugged on the GameShell and shift doesn’t send scancodes.

Late night brain malfunction I guess. I need to step away from the computer lol.

#7

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.

#8

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.

#9

but not nice for port who got ingame button assignation we will gain shift alone but lose all shift combo

also it will force all program to wrap key code part to simulate shift key, not as easy for beginners

better thing would be choice a keybind by program