Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pjcast]

* Ok, I changed the fixed size bit field to a vector<bool> (I considered using a bitset class, but felt bit manipulation is really not too useful). So, now implementations can implement as many buttons as they possibly want - I still feel an insane amount of buttons becomes rediculous, but I don't want to stand in anybody's way who has that many buttons
* I fixed DirectInput joystick to support 128 buttons.

As for orignal issue, I moved the check to the setting of the user data (where I meant to before). I put the expcetion back in the failure for setting the range values as it is rather imporatant for OIS to have a consistant range for axes. So, if it fails the first part, what I meant to do before, it will just continue to the next (if any) axis. Also, I only increment the axis counter for mapping after a successful user data setting. Let me know how this works for you. (Fixed in 1.1 and 1.0).

[kojack]

Cool, that works fine now. Thanks.

[kojack]

Don't worry, no bugs, just a little informational update.

I've finally gotten the analog hat switch on my joystick to work from DirectInput, in my own code (I've never seen a game which can handle it, even flightsims like XPlane with support for tons of controls). Turns out it's incompatible with the c_dfDIJoystick2 structure. Instead, I have to dynamically construct a custom data format descriptor as I enumerate each control on the joystick.

At least this way I can tell exactly where axes are within the structure, I know the 3rd axis is always the 3rd dword in my structure, whereas in c_dfDIJoystick2 the 3rd axis might be Z, RZ, RX or even a slider, depending on the device's driver.

(Interesting note, the game Fahrenheit can only support gamepads with 4 axes, which use  X/Y for the left stick and Z/RZ for the right stick. My xbox 360 controller uses RX/RY for the right stick, so I had to rebind in the unofficial drivers, but that breaks xinput from working).

This should also generically handle any number of axes, buttons and povs, not just the hard coded limits.

But boy does Direct Input give me a headache.

[pjcast]

Interesting. How portable is your code? Does it handle any normal DirectInput device too? Are you still (or were you) using OIS? Did you just modify the current code, or did you create our own factory creator (if you are using OIS)?

[kojack]

At the moment this is just my own directinput code in a test app. I'm doing a rewrite of my own input library (no cross platform stuff), and I'm testing some alternative ideas. Making the custom format isn't too hard, but I haven't tried efficient access to the data yet. If I can do that, I'll see how well it fits with OIS.

It should work for keyboards and mice too (I'd like to get my hands on that new mouse with 3 hat switches which is coming out soon).

I'd also love to know what the hell the 651 button device is which directinput gives me when I enumerate devices. It's got buttons labeled for police alarm,  lighting level, fan speed, tracking increment, and a ton of other stuff. I'm wondering if my wireless receiver for one of my mice is picking up something strange nearby...

[kojack]

So far the one generic device handles my X52 joystick, Xbox 360 gamepad, Logitech MX Revolution and G15 keyboard (including multimedia buttons) with no custom code for any of them. The only flaw is that I can't get the mouse to return relative data like it should. I'm still working on that bit.

All I need to do to read controls during buffered input is to check the dwOfs. All axes come first, then povs, then buttons. For example, here's the complete code to check a button of any directinput device (mouse, keyboard or joystick):

Code: [Select]

bool isButtonDown(DWORD b)
   {
      if(b<m_buttons.size())
      {
         return m_data[m_axes.size()*4+m_povs.size()*4+b];
      }
      return false;
   }