High number of directx controllers and shifting
-
Hello everyone !
I am renovating a cockpit that uses a lot of Leo Bodnar boards.
I am planning on programming everything in DirectX.
My question is about the Shift Magnitude, and if what I am thinking of is even doable.Some details :
14 directx controllers so far.
So #14 has unshifted buttons 416…447Default shift magnitude is 256, so 417…448 is controller #6 shifted.
Does this mean I need to change the shift magnitude ? What is the maximum quantity ?
I haven’t tried it yet, I’m just planning ahead, so if someone with knowledge could share it, it would be really appreciated
Happy flying. Flow.
-
Interesting question. Not sure of the answer, but I’ll be following your thread.
I think I had read that the max number of devices was 8. But that may be dependent on 32 buttons per device (i.e., 256 magnitude between devices …… 32x8). That’s 256 ‘buttons’ unshifted, plus another 256 ‘virtual buttons’ shifted.
My guess is that it’s not the number of devices so much as 256/512 available ‘buttons’ split up evenly (??) between those devices.
I assume you’ve looked through the DX manuals/documents included in the install?
-
The code can recognize up to 16 controllers (like you’d see 16 listed in the Windows control panel Game Controllers applet).
Shifting allows you to fake like one physical controller this is present shows up to the game as buttons on a phantom controller somewhere else in that set of 16. The code that does this shifting does not know or care how many controllers you have attached. It just blindly tells the game that a button was pressed…unshifted, that button is in the namespace range associated with the physical device that holds that physical button/switch; when you mash on the button programmed to engage the shifting then some other button press will be shown to the game as it’s raw number plus the shift value.
Context: Windows lists controllers in an order shown in the control panel applet and that order corresponds to the order that the game treats them as well. Each device can have up to 32 buttons and Windows treats naming for buttons as though all devices do in fact have 32 buttons even if they physically do not.
So, the first controller listed has buttons numbered 0-31, the second one has buttons 32-63, and so on. Again, this is independent of how many actual physical switches are available on a given device. If Windows sees a device it assigns a range of 32 button numbers regardless. [confusingly when you look at a controller’s properties in the Game Controller applet Windows there labels the buttons 1-32 but trust me, internally and as far as the game goes, the numbers are one less than that since the first one programmatically starts from a zero-based numbering scheme. So the number that names a specific button in the .key file is always one less than what the applet would seem to imply]
An example of how the shift code works.
Let’s say you have only one joystick device. It has 10 actual buttons. You want to use shifting to give you more button bindings. Well first you have to assign one button to perform the shifting so we’re talking about doubling up your other 9 buttons. Let’s arbitrarily say you pick button zero for that. So we want to shift buttons 1-9.
Now, since we have only one controller with only 10 buttons we have 16 controllers * 32 buttons minus the 10 we have already used for our unshifted binding to play with.
Now the shifting is completely numeric – doesn’t know about controllers at all. So let’s say we pick a shift magnitude number of 1 just for giggles. What does that do?? If you press-and-hold the shift button (which we said was button zero in this example) and then press button one what the code sees is button number one plus the shift value – 1+1 = 2 so the game thinks you pressed button two.
That’s not very useful because you probably already have a key binding for the unshifted button two and now your shifted button one does the same thing. But the point here is that the shift magnitude is just blindly mathematical.
A more normal example would be to say: well I don’t want overlapping, unshifted and shifted buttons should give me different key binding invocations. So for our 10-button device example you could pick a magnitude of 10 as a minimum to guarantee no overlaps. So if you did that, in the key file you’d want a line to bind button 10 to the pinky shift (so that it really does release the shift multiplier when you let up pressure on that button) and then 9 other lines for the shifted function for the 9 buttons for which you want to add a second binding.
With 10 and the magnitude, press-and-hold button 0 to engage shifting mode, then press, say, button 4 then what the game sees is button number 4 + 10 = 14. Provided the key file has a line to bind button 14 to a callback now you have two functions for that physical button.
Again, that’s possible but not usual. Many controller devices (caveat: that Windows sees as plain joysticks without fancy driver capabilities) have 28-32 actual buttons so the more normal paradigm is to pick a shift magnitude that vaults physical button presses into the set of numbers that would be assigned to a controller if one were present but that are presently “free” because there is no such controller. For example, if I only have one device then 32 is a pretty decent choice for a magnitude because that will ensure that shifted button numbers can’t collide with ones on my device that are known as buttons 0-31.
Personally I tend to use 256 because that means I can plug in 8 physical devices and have shift layers on all of them and guarantee that there are no overlaps or duplication.
Your case with 14 controllers is a bit more tricky to control I suspect. You only have headroom for 64 shifted values that aren’t duplicates of existing physical device buttons. If it’s Bodnar boards, my recollection is that those show Windows DX buttons for switch/button controls so you have limited options for doubling up by having some of the controllers use keyboard emulation instead of DX button bindings in your .key file. The other limit is that there is only one shift magnitude for all controllers. Thus you can shift two adjacent-in-the-list controllers into that free button space but you probably can’t shift two that are separated in the list by a third or more controllers. Let’s say its the first two controllers that you want to shift, in that case your magnitude should be 448.
Now all of that said, I know of a cockpit project that I worked on that used EPIC – it was a single device that could show Windows virtual joysticks and we used 13 virtual devices and that covered all of the things that were active in the game. Since then a few more controls have been added and I haven’t done the sums but I’d guess that 14 covers more or less everything you’d need or want. In which case, your need is probably only to shift the HOTAS device(s) to add things that are simulation controls (I have view controls, padlocking and that sort of thing on my full cockpit shift layer). If that’s the case then figure out where your HOTAS devices are in the controller list and pick a magnitude to shift those into the last 64 button number space, add lines for those last 64 button bindings in the .key file and you should be in good shape.
-
Thank you very very much for your answer Boxer.
It is now very clear and I know how I can organize all this.Happy flying !