SFML community forums
General => Feature requests => Topic started by: TTK-Bandit on March 10, 2008, 12:26:49 am
-
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!
-
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 ! :)
-
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.
-
cool thx
-
I've added some missing keys, tell me if it's ok for you now ;)
-
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.
-
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.
-
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 :D
-
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:
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;
}
}
-
it kinda sucks to have unicode chars for binds anyway, so you can skip it.
☠ motherfucker! :P
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.
-
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.
-
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).
-
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.
-
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
-
Thats ok, BUT there is no real difference between the hex and the unicode.
Both are numbers on nearly the same level:)
-
yeah, but having it as hex numbers removes the need for drawing all those different characters ingame.
-
What about providing an additional function to fetch raw key codes. I have german keyboard layout and no access to the Umlaut-keys or tilde, dot, comma, plus or minus. If there were a method to fetch raw key codes one could implement a user interface to configure the keys when the game starts for the first time. So we would not have any problems with different systems.
By the way: is it possible to do this on my own in python without having to patch the library?
greetings,
wurzeldrei
-
What do you mean with "fetch raw key codes" ? Can you give an example ?
-
i think you get key codes from the os (of course os- and locale-specific), if there was a function RawCode containing that os code (from Windows API or X11) i could write
while window.GetEvent(event):
if event.Type==sf.Event.Closed:
running=False
if event.Type==sf.Event.KeyPressed:
if event.Key.RawCode==KEY_END:
running=False
and fill KEY_END on first run of my game by user input, sorry if my english is bad, school is long ago..., i'll train
-
Hmm I'm not sure this would be the best solution.
One obvious reason is that you wuoldn't have consistent values across different systems (if you send keys over the network, or save them to configuration files).
-
I think this is not what the additional function would be good for, since if one has to send keys over network (i think, this is not a good idea in general) he can just use the standard method. But most games will provide an interface to change the key bindings for that game, especially for that user on that platform.
I think there are better solutions, but very much harder to implement:
- Provide all keys on all keyboards via the standard method, here we had to add pages of key codes for some systems,
- Provide a complete key binding management that holds the raw key codes in a black box so programmers are not able to do unwanted things with them (sending key codes over network ;-) )
For the last thing i would suggest a BindingManager class that can be used as follows:
z=enum{C_GAME_EXIT, C_JUMP, C_RIGHT}
A=BindingManager()
A.Learn(C_GAME_EXIT) %waits for user input and saves raw key code internally
while window.GetEvent(event):
if event.Type==sf.Event.Closed:
running=False
if event.Type==sf.Event.KeyPressed:
if A.Get(event)==z.C_GAME_EXIT: %Returns code (z-value) for the event saved in event
running=False