next »

[ThemsAllTook]

I don't use controllers for my current games but the subject interest me. May I ask if you evaluated OIS and if yes, what are the differences with your library? I mean, other than focusing only on the controllers.

Interesting, I hasn't seen OIS when I was searching for alternatives. Looking at it now, it's definitely similar in a lot of ways. The main difference I'm seeing is that OIS appears to be trying to provide a comprehensive solution to inputs from all types of devices, while I'm focused on providing the smallest, simplest possible interface just to game controllers and nothing else. Mine is also a C API, while OIS is all C++. I'll probably look through OIS and see if there are any bits of code that would help me with what I'm trying to do...

[Schrompf]

OIS is indeed a good start, I think. But if you're going to test it, be sure to include the XInput patch. It enhances the Joystick code to test for XBox Controllers and handles them via XInput then, removing all the problems DirectInput has with those Controllers.

I used to use OIS, but rewrote large portions in the meantime. OIS is an overdesigned mess of Factories and Abstractions, but it got the job done. I needed multiple keyboards and mice, which can only be achieved with RawInput, which brings a whole range of own problems along. I also patched an action mapper on top of it, which I'd prefer to build into OIS itsself to save that additional complexity. One day I'll publish it as OpenSource.

[Klaim]

Ah yes, my worries about OIS are basically that there is no improvements going on.
Also the action mapping library that is available could really be better, so I plan to setup my own one for my game, but I think it will not be generic enough to make open source.
Anyway, OIS is a good idea, but I think it was developped in a time a bit different than now and it should be heavily refactored. The problem is that nobody will do that.
Or maybe your version is nicer?

[Schrompf]

Not at the moment :-) And for the exactly reasons you mentioned: not generic enough, and a lack of time to brush it up. Let's see what time brings.

[fractilegames]

I have been using OIS for quite a long time and while it gets the job done it would really need some refactoring and active support. There are patches which resolve some of the problems, but dealing with all the patches and workarounds is getting really messy.

Feature-wise OIS is exactly what I need, a cross-platform library for keyboard/mouse/gamepad input. I have been trying to find a replacement for it, but so far I haven't found anything suitable.

This gamepad library looks really promising! Does anyone know a matching lightweight library I could use for keyboard and mouse input on Windows and Linux (and possibly OSX)?

[ThemsAllTook]

Very interesting...until the OIS discussion and your post, I hadn't considered that there might be demand for an equivalent keyboard and mouse input API. I've always thought of these as different things, and expected whatever windowing API you're using (SDL, GLFW, etc.) to handle it adequately. Maybe you have needs beyond what those APIs provide that I haven't encountered yet? I'm curious to know what features are lacking that you're looking to find elsewhere.

[fractilegames]

I'm using Ogre3D for graphics and it handles all "windowing stuff" that I need, but offers not support for input handling.

So it's not really about lacking features of windowing API, but ease of use. I would like to have a simple API for all input handling that hides all OS/platform specifics from me as Ogre3D does for windowing and rendering.

[Klaim]

Ogre3D is distributed with OIS which is used for the samples programs. That's how I learnt about it. That's also why I use it right now (it's already in Ogre dependencies, so I'm using it for now).


ThemsAllTook by the way, just for having things to compare to your work, you might want to check how SFML handles input. I didn't look at how it handles game pads (or even if it does) but you might find insights there too.

[NoobsArePeople2]

ThemsAllTook by the way, just for having things to compare to your work, you might want to check how SFML handles input. I didn't look at how it handles game pads (or even if it does) but you might find insights there too.

I'm using SFML on a project and it works fine with gamepads via the Joystick class. I've tested the 360 and PS3 pads on Windows 8, and PS3 and Wiimote on OSX. There are two minor issue though:

1. The XInput/DirectInput axis issue discussed earlier in this thread.
2. The SFML API provides no way to get a device ID or name making it difficult to provide default mappings for different gamepads.

[ThemsAllTook]

ThemsAllTook by the way, just for having things to compare to your work, you might want to check how SFML handles input. I didn't look at how it handles game pads (or even if it does) but you might find insights there too.

Aha, didn't know SFML did it too. Thanks, I'll take a look.

[dynamite-ready]

One thing to note is that on Windows, it's made to be used with MinGW, and probably won't work as-is with Visual Studio. If there's interest, I can see about getting it to be compatible. Assistance with this would also be appreciated, since I know little to nothing about VS.

Hope some new people can find this useful! Sorry for the long period of inactivity.

Using my first post here to give you mad props! ^_^

This library is awesome! AFAIK, it's the only one of it's type out there (cross platform, gamepad input only). I used MinGW to link and compile a program based on your library. One issue though... I wouldn't know anything about Visual Studio, but had to link Microsoft's winmm.dll (-lwnmm...) into my program before getting it to compile (win32)...

That was a badger to work out.

Works like a charm though.
Used it to replace a faulty, Windows only, SDL based part. But now it runs great! Will get onto a Linux and OSX port and see how that goes...

Btw, will you put the library up on GIT at some point? I mean it's already open source, right?

[ThemsAllTook]

Using my first post here to give you mad props! ^_^

Thanks, and welcome!

One issue though... I wouldn't know anything about Visual Studio, but had to link Microsoft's winmm.dll (-lwnmm...) into my program before getting it to compile (win32)...

Yep, sounds right. I should probably include some more useful building/linking instructions at some point...

Btw, will you put the library up on GIT at some point? I mean it's already open source, right?

I suppose I could, but I'm not really familiar with git. My svn repository is public: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/

What would be the benefits of having it on github (assuming that's what you meant)?

[dynamite-ready]

Thank you for the warm welcome. ^_^

I suppose I could, but I'm not really familiar with git. My svn repository is public: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/

What would be the benefits of having it on github (assuming that's what you meant)?

I suppose the main benefits to using Github for a project as potentially popular as this would be visibility and potential support. You might have more luck finding stray and willing C developers if the project was up there, but it's hard to say...

For example, Blender is a massive project and has always been on SVN. There are a handful of unofficial Blender repos on Github, but they have like, 2 active followers/developers. Which goes to prove that you can certainly get by without GIT...

On the other hand, and perhaps more relevant, SFML was put onto Github about 2 years ago (but has, I think, been in development for 4 years)... It now has a huge following, and quite a few active developers - https://github.com/LaurentGomila/SFML

Where I can see it being useful to you, is in tracking random bugs found by people like me stumbling across the project, finding an issue (like the -lwinmm thing), and wondering how to raise it. Github does make that step rather simple. Furthermore if someone does have fix on hand (or a feature*), then it's only a small step to incorporate it into the project. That's partly because GIT makes branching a piece of piss...

Given the potential of this project, it's definitely worth looking into...
Would be a great way to learn GIT too.

*View Hat support would be a nice one, but I wouldn't know where to start...  

[ThemsAllTook]

Thanks for the github info, I'll definitely look into it!

*View Hat support would be a nice one, but I wouldn't know where to start...  

Hmm, that might be doable - right now I just translate hats into a pair of axes for simplicity. Admittedly, this library is geared more toward gamepads than flight sticks, but I'd like it to work for both. If it's useful to make hats a third type of element (in addition to axes and buttons), I think the underlying APIs give me enough information to distinguish them from other types. Any suggestions on how you'd want the API to look?

[dynamite-ready]

Thanks for the github info, I'll definitely look into it!

*View Hat support would be a nice one, but I wouldn't know where to start...  

Hmm, that might be doable - right now I just translate hats into a pair of axes for simplicity. Admittedly, this library is geared more toward gamepads than flight sticks, but I'd like it to work for both. If it's useful to make hats a third type of element (in addition to axes and buttons), I think the underlying APIs give me enough information to distinguish them from other types. Any suggestions on how you'd want the API to look?

Ah... The reason why I'm keen on support for view hats, is because of this...



On Windows at least, the OS appears to map the joypad (not the analogue sticks) to a view hat... So console based sticks such as the one above become unusable (tested against your gamepad test harness on Windows).

As for the interface, I'd be happy to merely see the Gamepad_device struct extended with "bool * hatState", where "hatState" is an array of booleans and each array key corresponds to one of the 8 directions on the hat ("centred" = hatState[0] = true, "up"  = hatState[1] = true, and then clockwise thereafter......

Sorry...

Perhaps a Gamepad_device field that looked like "unsigned int * hatState", where the current value indicates the hat position ("centred" == 0, "up" == 1, etc), would be better.

If that's instinctive enough, then I suppose you'd probably want to add "void Gamepad_hatDirFunc(void (* callback)(struct Gamepad_device * device, unsigned int hatDir, double timestamp));".

But that's just me...
What's more, I have no idea how hard this might be to implement across different platforms.

[ThemsAllTook]

On Windows at least, the OS appears to map the joypad (not the analogue sticks) to a view hat... So console based sticks such as the one above become unusable (tested against your gamepad test harness on Windows).

Ooh wait, my test harness doesn't report any input from the view hat at all? If so, that's a different issue that I might be able to solve more easily, unless the driver isn't reporting it correctly. The version that's posted here is using an API that reports a very limited number of elements, and it's possible that they don't fit into the structure returned by joyGetPosEx. I'm in the process of rewriting the Windows portion of the library to use DirectInput instead, which should allow access to arbitrary numbers of elements on any device. The API would stay the same, and your view hat would be reported like a d-pad, with an X axis and a Y axis. I'll be sure to post an updated test harness here once the DirectInput implementation is working.

[Endurion]

I'm currently implementing Raw Input on Windows (my present input library uses DirectInput) and I've got the HID stuff working now (which is probably quite similar to your USB part).

About the hat switch, as far as I unterstood they are a rotational device which enumerates as a single axis device. The XBox 360 Controller reports min as 1 and max as 8 (at least mine does).
However from the looks of it there may be other controllers around that allow a analog hat switch, so max may have a higher resolution.
In my library I'm not separating the hat switch values directly in two axis, but interpolate an angle value from its ranges.

Also, about the left/right trigger of the XBox 360 controller, don't you handle the up/down parts of an axis separate? I do enumerate one axis, but treat the left or right movement as separate virtual keys. This way it's no problem to differ between both analog buttons.

[ThemsAllTook]

About the hat switch, as far as I unterstood they are a rotational device which enumerates as a single axis device. The XBox 360 Controller reports min as 1 and max as 8 (at least mine does).
However from the looks of it there may be other controllers around that allow a analog hat switch, so max may have a higher resolution.
In my library I'm not separating the hat switch values directly in two axis, but interpolate an angle value from its ranges.

I guess this is my inexperience with hat switches showing itself - I'm really not familiar with how they're used, so mapping them to pairs of axes might not be the most intuitive thing to do. I'll have to do some research and see if I can find a more sensible solution, or maybe use dynamite-ready's suggestion above.

Also, about the left/right trigger of the XBox 360 controller, don't you handle the up/down parts of an axis separate? I do enumerate one axis, but treat the left or right movement as separate virtual keys. This way it's no problem to differ between both analog buttons.

Sure, that works fine for pressing one trigger at a time. The problem is that when both are pressed simultaneously, they cancel each other out - if you have one trigger held all the way down, there's no way to distinguish between that trigger being released, and the other trigger being pressed. DirectInput appears to have the same problem, so XInput is the only API on Windows that actually lets you read the two separately.

I'll have to look into Raw Input. Maybe it'd be easier than the DirectInput disaster I'm currently dealing with...worst API I've ever used, hands down.

[Endurion]

Sure, that works fine for pressing one trigger at a time. The problem is that when both are pressed simultaneously, they cancel each other out - if you have one trigger held all the way down, there's no way to distinguish between that trigger being released, and the other trigger being pressed. DirectInput appears to have the same problem, so XInput is the only API on Windows that actually lets you read the two separately.

Dang, you're right. Obviously they cancel each other out. I guess there's no chance as long as the device actually reports them as one axis. So far this really seems like a political decision.


If you find DirectInput awful, you'll hate Raw Input. It's quite similar, and doesn't even provide you with sensical text description of all available controls.


I've heavily picked code from here (http://www.codeproject.com/Articles/185522/Using-the-Raw-Input-API-to-Process-Joystick-Input) and (http://zfx.info/viewtopic.php?f=11&t=2977). The latter is a german tutorial series and currently ends before actually reading the data (for now). It however explains nicely how to get calibration and description data for the devices.

[ThemsAllTook]

If you find DirectInput awful, you'll hate Raw Input. It's quite similar, and doesn't even provide you with sensical text description of all available controls.

Actually, from what I can see it looks quite a bit better for what I need. I don't trust drivers to report sensible text descriptions of anything after seeing how inconsistent they are at everything else, and I couldn't really use those anyway without adding a Windows-specific section to my API, which I'd prefer to avoid. A lot of the awkwardness I ran into with DirectInput had to do with the fact that it's simultaneously a C and C++ API, with some bizarre macros that let you use it natively from either language. Raw Input being a pure C API gives it a leg up already. I don't mind dealing with low-level HID stuff, and it looks like it'll fit my usage patterns better, and as a bonus I won't have to link to DirectX DLLs. Thanks for the links, very useful!