views:

489

answers:

5

I made an FPS game with MSVC++ which is running very well on Windows. But now I am trying to make it portable (at least I want to create a linux and a Windows version), so I decided to change the IDE to Code::Blocks and the framework to wxWidgets. But it seems the virtual key codes and scan codes are different on different systems.

Earlier I experienced that the virtual keycodes may be different even on the same operating system but different computer (I got bug reports about they unable to control the character (depending on the numlock state, lol, not joke), which is fixed when change the code to use scancodes instead of virtkey codes) (edit: with wxWidgets both virtkey and scan codes on the numpad has different values depending on numlock state, bang!)

Now with wxWidgets it seems the wxKeyEvent::GetRawKeyCode and the code obtained earlier from WM_KEYDOWN's lParam are different. And I also get a completely different scan code on linux (ubuntu) from GetRawKeyCode.

Well I can make my own scan code table by pressing all the keys and seeing what code it gives, but the only problem that ubuntu runs on my laptop, and the laptop does not have a full keyboard... But I need all of them to make Control Settings work.

So the question: Is there a standard and cross-platform way to get the same code for the same key (the key at the same position to be more precise)? (at least on windows and linux)

+6  A: 

In case you haven't considered it already, you might be able to use SDL.

TrayMan
Adding a link would make this answer a lot more useful.
Hosam Aly
http://www.libsdl.org/ .. first hit on google-ing ..
lexu
added the link :)
Matt J
+1  A: 

This being an FPS, the lower-level graphics toolkit you are using makes a huge difference (I'm assuming that you're not writing 3d graphics in wxWidgets). If you're using OpenGL, have you looked at what GLUT can do?

The glutKeyboardFunc and glutSpecialFunc combined with glutGetModifiers could be sufficient for cross-platform keyboard code, and GLUT can even be used for other input devices.

To be honest though, I still don't see how this could possibly have anything to do with wxWidgets.

Oliver N.
I have already made my scan code tables (I downloaded several on screen keyboard and get all codes I need.)
Calmarius
A: 

My opinion is that it's completely wrong to use wxWidgets to code fast-paced 3D games. In "hardcore" game development,you should use it to develop supporting tools, such as editors and converters.

SDL is the way to go. It may seem quite basic, but once you start sacrificing small children to the unholy gods of SDL, stuff like SDL_image (perfect for reading numerous image file formats - to the extent I sometimes use SDL solely to read e.g. JPEG) or SDL_mixer (sole solution you need for reading and playing basic audio - OGG, WAV, ...).

So look no further than SDL. Even the 2D graphics support is good once you start using SDL_gfx. SDL may at first seem basic, but once you count in all the extra libraries built around it, and once you code a few wrappers around it, you'll see SDL is the perfect balance between bare necessities and ease of advanced use.

I'll be happy to assist you in any way with SDL since I find it so awesome.

Ivan Vučica
However, it runs with 30 (preset) fps with <10% cpu usage... So I think it is not so wrong...
Calmarius
Nobody said it won't work. I just think it's simply not what wxWidgets' support for OpenGL was meant to do. It was meant for apps that need 3D support, not 3D games that need windowing support, if you're following me.
Ivan Vučica
+1  A: 

I might be misunderestimating what your seeing here, but looking at the raw keycode returned is going to result in hardware, os, configuration and platform differences, so you should be looking at the virtual keycode returned by a key event.

EDIT: Maybe wxWidgets just doesn't handle it right (doubtful). The issue of the numlock key is "forcing" you to work around this (poorly) by using the raw scan code.

If that's the case you don't need to throw away what you've done, but if you add SDL just for the input stuff, you'll find calls which return the SDL_keysym don't just return the hardware scancode (which you can do nothing about "fixing") but also map it to a unicode character and a virtual symbol, which is I think what you're looking for. Hopefully their calls don't have this numlock modifier problem.

dlamblin
A: 

If you don't wan't to use SDL, I recommend SFML - Simple and Fast Multimedia Library. It is multiplatform and really simple to use. For example, from tutorials section:

bool         LeftKeyDown     = Input.IsKeyDown(sf::Key::Left);
bool         RightButtonDown = Input.IsMouseButtonDown(sf::Mouse::Right);
bool         Joy0Button1Down = Input.IsJoystickButtonDown(0, 1);
unsigned int MouseX          = Input.GetMouseX();
unsigned int MouseY          = Input.GetMouseY();
float        Joystick1X      = Input.GetJoystickAxis(1, sf::Joy::AxisX);
float        Joystick1Y      = Input.GetJoystickAxis(1, sf::Joy::AxisY);
float        Joystick1POV    = Input.GetJoystickAxis(1, sf::Joy::AxisPOV);

where Input is

const sf::Input& Input = App.GetInput();

There are some indications that SFML is faster than SDL, however I tend to use it to whip out fast and portable code since I like its usage more than SDL.

Keyframe
Thanks for pointing out SFML, I'm glad to know of SDL alternatives! That said, these benchmarks you pointed to refer to SFML being faster than SDL ... when doing plain 2D rendering. This question relates to 3D rendering :)Again, thanks for pointing out SFML, I'll consider it when working on 2D!
Ivan Vučica