• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Input... this.

Sign in to follow this  


So upon reading about the uncertainty of the future of DirectInput I did some preliminary research into how we were to handle input from now on. The answer, WM_INPUT. Armed with this knowledge I did nothing. I did other things, more important things as designing input stuff is not exactly exciting or fun as you will find out after reading this.

So this week I begin writing the input interface for Gorgon. I decided to keep this as a seperate entity so that users could plug in their own input library if they so choose. And I made it a plug-in, so it can be dynamically loaded at any time, and so that other input mechanisms can interface with Gorgon (e.g. an interface that utilizes DirectInput, or form events). Naturally, with the demise or at least the abandoning of DirectInput by Microsoft I decided to go back and do my research into WM_INPUT.

You probably know .NET/WinForms does not have anything to handle raw input events. Probably would have been a good idea for Microsoft to have added the event... but I digress. I did some searching on pinvoke.net for the functions associated with raw input (e.g. GetRawInputData, etc...) and lo and behold not a damn thing. Which is surprising really, pinvoke.net usually is pretty up to date and complete. So this required me to start building my own pinvoke crap.

I suck at pinvoke, I always did, even with VB 6 (which, is understandable, it was a horrible bastardized interface). So it took me some doing to get the functions right. Why? Because there are a lot of fucking structs/typedefs to use with the 5 or 6 functions that use raw input, and a million more constants. One thing I noted was that in the device registration for raw input, there were NO HID usage IDs as constants in the header files. Now, the HID usage flags are quite lengthy, I can understand someone not wanting to type that shit out. But I did it anyway. So I really understand. First, I attempted to register the mouse for raw input... it worked, first try, I was floored! After that I hacked up a test win-form to handle the WM_INPUT message and tested the GetRawInputData() function. Not so good. Just kept on failing. I scratched my head for a day or more. Until, after, y'know, I actually read what I wrote I realized I was not intercepting the window message for WM_INPUT, but no, I was intercepting the wParam. Yes, I'm fucking stupid. Fixed that, and boom everything works as it should. After pissing around with the functions a little more I promptly put everything on pinvoke.net (there are a few things not quite right with the HID usage flags on there, but meh) and felt like I did something good for once.

The only thing now was to hook the WM_INPUT intercept into an arbitrary control's WNDPROC. Easy enough, thankfully the Application object in .NET has a function to add a message filter, which basically hooks your message intecepts into the application's main WNDPROC. This worked beautifully and now I have raw input in Gorgon. No DirectInput. Joy. I guess I will have to use DirectInput to handle Joysticks for now, which is kind of disgusting (really, I hate DirectInput), but that's all I can do I guess.

I know this was boring. But no one really reads this anyway.
Sign in to follow this  

1 Comment

Recommended Comments

I don't know if you've heard of it before, but ApiViewer 2004 is a bit like the VB6 API viewer (generating the signatures for methods from the Win32 API), but also supports .NET languages like C#. I've found it to be an invaluable tool when dealing with P/Invoke. It's not perfect (putting in Int32s where an IntPtr might be more useful), but it saves a lot of faffing about.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement