More Keys for Press/Release events

[TTK-Bandit]

hey
I've just played a little with sfml, and I must say I like it very much, works better for my needs than SDL.
But the number of keys available for keypress events are too limited.
The first thing I missed was the tilde key, for those who know quake, its the console key (the key left from the 1).
found out it is VK_OEM_5 on windows..

the super keys are missing (windows keys), the menu key, the key right to the left shiftkey, the dot key, the period key, etc.. there are a few more, but I guess you got what I want..

anyway, since some keys might be available on some OS, and others won't, would it be possible to at least send the original keycode out, so one could check it manually, instead of getting a key event with code 0 ?

Another thing that is bugging me, is that there is only one key event for shift/ctrl/alt, but in games I would be interested in having one for left and one for right.

Thanx, great work!

[Aszarsha]

Another thing that is bugging me, is that there is only one key event for shift/ctrl/alt, but in games I would be interested in having one for left and one for right.

I completely agree with this !

[Laurent]

I completely agree too

If I remember correctly, I didn't implement left and right shift / ctrl / alt because there's no way to get them on Windows (the only function for which WM_LCONTROL etc. work is GetAsyncKeyState ; not when receiving a WM_KEYDOWN message).

However I'll add the missing keys, I wonder why I didn't do it before.

[TTK-Bandit]

cool thx

[Laurent]

I've added some missing keys, tell me if it's ok for you now

[TTK-Bandit]

definetly better, altho, now I found its missing translation for different keyboard layouts, sdl calls it unicode translation I think.
a lot of the keyinputs just dont match the names you gave them on my keyboard or still give 0 as code, I guess due to the different layout.

also the numpad should have unique key inputs too, not just for the numbers, but also for plus, minus, enter, etc

one weird thing I noticed, was that F12 triggered a breakpoint that was not in my source.

[Laurent]

definetly better, altho, now I found its missing translation for different keyboard layouts, sdl calls it unicode translation I think.
a lot of the keyinputs just dont match the names you gave them on my keyboard or still give 0 as code, I guess due to the different layout.

I know. But I really have no solution to handle all the possible keyboard layouts.

one weird thing I noticed, was that F12 triggered a breakpoint that was not in my source.

It's a feature of the Visual C++ debugger.

[TTK-Bandit]

you could check out the sdl code, I think they have it working pretty well..
on windows, you can use GetKeyboardLayout(), dunno about x11/mac
on the weekend, I'll see if I can get some working code together..

did not know about the F12 debug bind.. never pressed F12 while debugging

[TTK-Bandit]

results of my tests are that it kinda sucks to have unicode chars for binds anyway, so you can skip it.
but there still are a few issues I'd like to adress:
1. lower/greater than: VK_OEM_102
2. Tilde is VK_OEM_5 for me, are you sure its VK_OEM_3 on your system ?
3. capslock via VK_CAPITAL, dunno maybe numlock too ?
4. numpad keys for divide, multiply, .. should be unique too.(see 5.)
5. numpad keys should work even if numlock is disabled..
on windows you could add this to the top of VirtualKeyCodeToSF:

Code: [Select]


int hiFlags = HIWORD(Flags);
if ( !(hiFlags & 0x100) ) {
switch( MapVirtualKey(hiFlags & 0xFF, 1) )
{
case VK_INSERT :     return Key::Numpad0;
case VK_END :        return Key::Numpad1;
case VK_DOWN :       return Key::Numpad2;
case VK_NEXT :       return Key::Numpad3;
case VK_LEFT :       return Key::Numpad4;
case VK_CLEAR :      return Key::Numpad5;
case VK_RIGHT :      return Key::Numpad6;
case VK_HOME :       return Key::Numpad7;
case VK_UP :         return Key::Numpad8;
case VK_PRIOR :      return Key::Numpad9;
case VK_DIVIDE:      return Key::NumpadDivide;
case VK_MULTIPLY:    return Key::NumpadMultiply;
case VK_SUBTRACT:    return Key::NumpadSubtract;
case VK_ADD:         return Key::NumpadAdd;
case VK_DELETE:      return Key::NumpadDelete;
case VK_RETURN:      return Key::NumpadReturn;
}
}

[Lord Delvin]

it kinda sucks to have unicode chars for binds anyway, so you can skip it.

☠ motherfucker!
Unicode input is one reason why i still use sfml 1.1 with my patches:)
Unicode keypresses are as usefull as all others are, but it wont matter if they are unnamed.

[TTK-Bandit]

for text input unicode is good, but for binds ?
would be pretty complex to have all the enums sorted out correctly.

edit: oh just noticed, that there is no unicode translation for text either, I thought there was since sf::Event::TextEntered uses Event.Text.Unicode
Thats definitely something that has to be changed.

[Lord Delvin]

for text input unicode is good, but for binds ?
would be pretty complex to have all the enums sorted out correctly.

If you look at Keyboards outside of Europe and America you will have to notice, that they have keys which are unicode. Some boards may consist only of unicode characters.
I dont think its a good idea to disallow them to play your game.
If you dont like unicode, you can still check if the character has a value higher then 255(maybe a bit more if control chars are mapped to higher values), but believe me when I tell you that 64k characters are not a problem, as my improved version has a project which uses all 64k characters(or at least accepts them).
But it wont be an urgent feature(i dont know how easy it is to implement on windows, linux took me about 4 hours, as i didn't know how x11 and sfml handels unicode).

[TTK-Bandit]

If its only a different keyboard layout, not a completely different keyboard type, then you can still bind stuff via the menu, just entering it via config or console will be harder, since you need to find the english key for your button.
if you want me to accept chinese as input type, then I have to say that would be hell of a lot work to make it possible, since that is not only the input stuff, but also string and font issues you have to redesign.

[TTK-Bandit]

lord delvin, what about this:
could use unicode and have the ascii characters normally bound (32-126)
and those that are not covered by ascii can then be bound by its hex value, i.e. 0x38

[Lord Delvin]

Thats ok, BUT there is no real difference between the hex and the unicode.
Both are numbers on nearly the same level:)