next »

[MadWatch]

I use OOIS as library abstracting all inputs, not sure how it works for gamepads but never heard complains about it.

OIS is great but I had quiet a lot of troubles with it. There are two things anyone intending to use it should know.

First, you must turn on the XINPUT option into OISConfig.h if you want proper Xbox 360 pad support on Windows (it works like a charm when this option is on, but it has problems with the triggers when it isn't).

Second, multi platform keyboard support kinda sucks. Keyboard behavior is different on Windows and Linux (don't know about Mac yet since I don't have a Mac yet). On Windows OIS will give you keymap independent key code, that is if you press A on an azerty keyboard OIS will send you KC_Q. But on Linux it will give you keymap dependent codes so pressing A on any kind of keyboard will always send you KC_A.

But for some games you need both keymap dependent and independent codes. The later is great for directions keys (so that your qwerty WASD automatically becomes ZQSD on azerty). The former is great for commands key (ie press Ctrl-Z to undo whatever you just did in the level editor).

I also noticed some special keys are just ignored. I have a bépo keyboard (a French ergonomic layout), meaning I have an É key where you Z key is (assuming you have a qwerty). But OIS doesn't recognize it at all (it doesn't sent any event when it's pressed) which is troublesome.

I've been working on a patch to fix all these problems. But I must test it on Mac too before I can submit it on the OIS forum.

[Schrompf]

I, too, was using OIS, but I pretty much rewrote all of the windows input handling. Moved all keyboard and mouse handling to RawInput to be able to handle multiple mice/keyboards for multiplayer input. Included the XInput option and then extended all input handling to also fire a digital event when an analogue axis passes a certain threshold, and vice versa. And finally I added hotswapping because RawInput reports a lot of ghost devices that really botch your input handling in case they accidentally come up at index 0.

I once intended to clean it up and release it under some sensible OpenSource licence, but I never came around to actually do it. Maybe when Splatter is finally done.

[Klaim]

MadWatch> Interesting to know that the behaviour is fixed on Linux. I thought it was a general problem to not have the real keys (because it seem it's the same problem with almost all games - I use both Azerty and Qwerty)

I'll have to check if it hasn't been fixed already.


It's too bad we still have to do ourself platform-dependent code to get not-so-raw correct inputs :/

[MadWatch]

I'll have to check if it hasn't been fixed already.

To my knowledge it hasn't been fixed in OIS yet.
I've seen a patch proposal on the forum to fix the Linux behavior but it hasn't been integrated to the git repo. And from what I've seen of it it only fix half of the problem (because only half of keycodes values are standard amongst Windows and Linux).

[Klaim]

Wait, there is also a way to convert any key pressed to it's textual (UTF8 if I remember correctly) value (as a string). Is it too slow for action inputs too? Or does it have the same problem of not providing the localized value on Windows? I remember it was working well few years ago for typing text...

[MadWatch]

Wait, there is also a way to convert any key pressed to it's textual (UTF8 if I remember correctly) value (as a string).

From my experience this has always worked perfectly. It always gives keymap dependent values on both Windows and Linux. However there are few pitfalls there too.

First you're never sure what string you will get if you press a non latin or accentuated character key.

Second, if you press a modifier key you won't get the string you expect (ie pressing the Z key gives you "z" string, but pressing Ctrl-Z gives you another string that isn't necessarily the same depending on your OS and keymap).

[Klaim]

Ok so it's not very useful for combinations of keys...