NIL released: My advanced open source input library!

[noorus]

Hi all,
I'd like to present to you my open source (MIT-licensed) input library, called NIL for Nice Input Library
It's finally feature-complete and useful enough (my own projects use it) that I'm making the first official release.

Nil is for now Windows-only, but I'm not opposed to making it multiplatform in the long run, should some co-conspirators come along

To quote the Technology section of the GitHub page:

NIL utilises three different input APIs to achieve best possible input from different types of devices:

• Raw Input API for all mice & keyboard input, with zero lag and no special key weirdness
• XInput API for XBOX 360 controller input
• DirectInput API for all other joysticks & gamepads

NIL can tell apart every input device connected to the computer, including keyboards and mice.
Multi-keyboard and multi-mice input support is, for once, a breeze.

NIL is fully based on Plug-and-Play support: It knows when devices are connected and disconnected
from the computer, and remembers previously-connected devices when reconnected.

Additionally, NIL is capable of receiving direct input from the G-keys of certain Logitech Gaming keyboards & mice.

NIL is single-threaded, buffered and fully listener-based.

• Check out the GitHub page here to read more about the project...
• ...and see the v0.1.1 release announcement here, including downloads!

Nil is the result of a few months' total development effort, and I'm fairly happy about how well it has turned out.

A little backstory: I used to use OIS for all my input needs for several years. Eventually I wanted some things from OIS that it didn't have, and that I only knew how to implement on Windows, so I started keeping my own fork of OIS. Ultimately however my needs diverted from the design of OIS enough that I decided to write my own system entirely, and here we are.

Please feel free to check out the project on GitHub, try it for yourselves (there are prebuilt libraries and a testbed binary in the release downloads) and discuss it here. All feedback (and signs of love) are very welcome

Thanks!

[cybereality]

Cool beans.

[amartin]

Sounds good. Would you mind giving a quick rundown of how this differs from OIS. Also does it work on child windows?

[noorus]

Sounds good. Would you mind giving a quick rundown of how this differs from OIS.

Well, Nil is based on the concept of devices coming and going - your system listener gets device connected/disconnected events and you can then choose to enable or disable those devices and assign listeners to them. This is true for all device classes. I also chose to use normalized floating point input values instead of direct integers as OIS does, but that's a fairly small thing.

The actual implementation of Windows devices is also more advanced. OIS does not support multiple mice or keyboards, which Nil does. OIS uses DirectInput 8 for mouse/keyboard input while Nil uses the RawInput API directly. This is the most direct path of communication with input hardware, also bypassing the OS' mouse acceleration features, which is usually very important for professional gamers.

Care has also been taken to ensure that all keyboard keys, including special ones, work flawlessly for input. The windows keys, capslock and printscreen are as bindable as input keys as WASD are. Alt & AltGr (it's an european thing) are also differentiated between.

Also does it work on child windows?

The foreground mode should work on any window that your process owns. If it doesn't, there's always the background mode (global input) which you can use and then only process input when your window is active or when you feel like it.

[Klaim]

It's very interesting, the only thing that makes me not being able to try it is that it's not cross platform but if it becomes later please notify me

[thegooseking]

That looks really nice, but I am concerned about only offering raw mouse input. Raw is better in certain situations, but it's not a one-size-fits-all thing.

For mouselook, raw is probably (but not necessarily) better. The advantage is that you get more accuracy, but the disadvantage is you need to either change your mouse sensitivity or fling your mouse across a large surface to switch between accuracy and speed, whereas accelerated input lets you have both (to a point - it will never be as accurate as raw input) just by how quickly you move your mouse.
For a point-and-click driven game, the decision of whether raw or accelerated is better depends on whether you prefer accuracy or intuitiveness, which is a decision the player - never mind the developer - should be making.
For menu systems, intuitiveness usually trumps accuracy, so making your menu pointer behave like a Windows pointer (i.e. accelerated) is probably best.

Of course, there are lots of discussions we could have about whether or not those statements in themselves are true (they are, after all, just my perspective), but what is most certainly true is that the preference of one over the other is not categorical, but dependent on certain factors.

There's nothing really stopping us from using your library for raw input and some other library for accelerated input, but the technical difference between raw and accelerated mouse input is so small that using a whole other library for it is overkill, and overcomplicated. A better solution might be to emulate acceleration in our own program, and switch that on or off as we need, but that seems a bit like reinventing the wheel.

So what I'm driving at is that it would be really nice if your library could offer both raw mouse input and accelerated mouse input.

[noorus]

I think it's best for the game developer to implement possible acceleration features themselves.
Obviously if you're making a game that's essentially just another regular program (as in point and click) then using the standard mouse is probably for the best, but at that point you can just take your window's WM_CLICK messages and check the location, since performance isn't critical anyway.

For the record, DirectInput8 also uses raw input internally, so it wouldn't be of any help in that regard either. If you want standard OS mouse, then you don't need an input library, just regular window messages

EDIT: I *could* of course hijack your window's wndproc and handle mouse messages turning them into Nil events before passing them onto the real wndproc, but it's somewhat risky business, and I'm not sure why you'd need Nil in such a case anyway, since Nil isn't cross platform and you could already get the exact same input from the regular window messages that your program needs to handle anyway.

[thegooseking]

Yeah, now that I think about it, I don't know what the disadvantage is, really. I need to check my acceleration option and either call the library or the Windows functions based on that, but that's (a) not a big deal, and (b) not something that would magically go away if it was happening behind the scenes in the library. But, on reflection, I do think you're right that it's better to leave that up to the developers.

[Garibalde]

Hi

This looks cool. Is something i was looking for. I have the need to have dual mouse support in my application. So that i have a left and right hand mouse in my application. Both having their own cursors on screen and providing position and etc.. Does Nil support this type of setup? Do you have an example how to setup it up So that it works with a base application in Ogre. That would be great.

Thanks

[noorus]

Hi

This looks cool. Is something i was looking for. I have the need to have dual mouse support in my application. So that i have a left and right hand mouse in my application. Both having their own cursors on screen and providing position and etc.. Does Nil support this type of setup? Do you have an example how to setup it up So that it works with a base application in Ogre. That would be great.

Thanks

NIL can absolutely do that.
Since NIL is not specific to Ogre in any way, I haven't written an Ogre-specific demo application, but the setup is quite similar and very trivial.
There is an example console program in the "test" directory that listens to every input device in the system and prints all the event output, other than mouse movement which is too verbose.
The input callback signatures are almost exactly the same as in OIS.

EDIT: To clarify, NIL has no visual components whatsoever. If you want to see multiple cursors, you need to render those yourself in the application, and hide the default Windows cursor.

[Garibalde]

Thanks i will have a look at it this weekend.