InvertYAxis should be set to 1 and JoystickEmul should be set to 0 by default

[bguthrie1]

My issue is that my Y axis was not inverted. Pulling on the stick should pitch the craft up. I did not have this issue with the previous ddraw versions. Other people had this issue as well.

I believe I also recall an issue with someone who had to force the joystick emulation to off as it was messing with his physical joystick.

For those who do need Joystick emulation support, they can turn it on manually in the config, but most people will be using a joystick or controller of some sort so this should be set to off by default.

EDIT: It might be ok with JoystickEmul to -1 as default, but the InvertYAxis definitely should be set to 1.

[bguthrie1]

I've gotten some data from other folks on what their inputs are, though it is not a large sample size but it is a small idea of what we are dealing with:

joyID:0 | axes:5 | caps:37 | mid:45e | pid:28e | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:1 | axes:4 | caps:33 | mid:44f | pid:b106 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:

Device 0: PS3 controller as Xbox 360 controller
Device 1: Thrustmaster T-Flight Stick XBox

joyID:0 | axes:4 | caps:33 | mid:44f | pid:b10a | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:1 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:2 | axes:6 | caps:3f | mid:44f | pid:b687 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:

Device 0: Thrustmaster T1600M
Device 2: Thrustmaster TWCS Throttle

joyID:0 | axes:0 | caps:0 | mid:738 | pid:2221 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:1 | axes:0 | caps:0 | mid:738 | pid:a221 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:2 | axes:4 | caps:33 | mid:79 | pid:6 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:3 | axes:5 | caps:3e | mid:738 | pid:2221 | name:Microsoft PC-joystick driver | RegKey:DINPUT.DLL | OEMVxD:
joyID:4 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:5 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:6 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:7 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:8 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:9 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:10 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:11 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:12 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:13 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:14 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:
joyID:15 | axes:0 | caps:0 | mid:0 | pid:0 | name: | RegKey: | OEMVxD:

Device 0: X56Pro Joystick
Device 1: Generic Joystick
Device 2: Generic Gamepad
Device 3: X56Pro Throttle

Note that the gamepad listed above has an mid of "79"

The following is a more extreme example:

(In no order) Thrustmaster Warthog Stick Thrustmaster Cougar MFDs (x2) RealSimulator FSSB R3 Lighting Realsimulator TUSBA R2 (Thrustmaster Cougar USB Conversion device) Saitek X52 Pro mmjoy2 device vjoy virtual device Roccat Kone control device (part of the mouse software)

There is also something that I've read from the creator of a unity plugin called "rewired" that allows input from many different types of devices:

From the Rewired FAQ:

Can you/I add support for this controller?

It depends. Not all controllers are candidates for Rewired's automatic controller recognition system. The controller would have to be evaulated for inclusion.

Rewired's controller recognition system relies on information returned by the controller in order to be able to recognize it and load a hardware definition. Many times, the identifying information provided by the device is inadequate or too generic to be relied upon for recognition, for example those that show up as "Generic USB Joystick", "USB Gamepad", etc. This is true of a huge number of generic PC gamepads. The manufacturers of these gamepads create dozens and dozens of different products under a large variety of brands, some even with different button layouts, yet all of these devices provide exactly the same identifying USB/HID information (both product name and VID/PID). This makes it impossible to auto-recognize these controllers. If you were to add a controller definition for just one of these controllers, all others that don't match the button layout exactly would report incorrect element names and default mappings in the best case, and would be essentially unusable in the worst case. For these controllers, the only solution is to not provide a controller definition so that they will be treated as Unknown Controller which the user can map manually using Control Mapper or your own custom control remapping system.

The solution to allowing users to use these kinds of controllers and others without definitions is to give your players a way to remap their controls. It is a must that you have a system to let your player remap their controllers so they can use any controller they want. It is a core feature of Rewired to allow users to be able to use any controller regardless of whether or not it is recognized, including the ability to save and load their configurations. The controller recognition system is only really there as a convenience so that the most common controllers work without manual configuration out of the box, but it is not a substitute for being able to map controllers.

I think there is no question that eventually there can be some kind of system to attempt to detect and adapt to many devices in the ddraw. The question is, how much time do we want to divert to this task? This isn't going to be simple. This will take some serious hard work to do so. I think it would be better to leave the Xinput (and mouse joystick emulation) detection as an experimental option rather than having it on by default. Simply because it is impossible to detect all the types of joysticks/controllers/gamepads out there. Unfortunately we can't just have any device work out of the box. That's the just the nature of supporting many devices. I think folks that have devices that are really customizable or outliers such as the Steam Controller will naturally want to customize their input anyway and will be looking in the ddraw.cfg to customize. So it's better to just have Xinput detection set as an option.

On another note, another issue I've been dealing with is that the Xbox triggers (particularly the right trigger) is mapped to the z axis. This issue still occurs with the ddraw posted above. A lot of applications have trouble remapping the xbox controller buttons (particularly the triggers) and it takes a few specialized programs (such as reWASD or Steam) to remap them. But it seems that the left trigger was mapped to fire without messing with the z axis with the above ddraw so maybe it is possible.

[bguthrie1]

Basically, I think the best thing to do (for now) is to have JoystickEmul set to "0" by default. People who want to use a mouse or a different control scheme can customize it in the ddraw.cfg.

[rdoeffinger]

There is no "messing with the Z axis", I just find those games to be really painful to play without throttle, so I mapped the right trigger to throttle.

[bguthrie1]

Why wasn't that listed? I thought that was a bug. Well it's still a bug since even mapping the right trigger in game as something else seems to still keep it as throttle (as well as fire whatever was mapped to the right trigger in game).

[rdoeffinger]

Listed where? There kind of isn't a proper documentation for this whole project :( The wrapper can't know if you mapped it or not, plus maybe people have an idea of some mapping that still makes sense even with it being merged with the throttle. But sure, if you think it's less confusing could make left trigger button 11 and right trigger only throttle without button functionality... Right trigger when it was button 2 ended up mapping to "mark target in sights" I think, but now as button 12 I don't think it maps to anything normally.

[bguthrie1]

I apologize if I seem forceful. I get direct feedback from users with their input issues from this ddraw so I feel the full weight of the issue.

Here is my recommendation:

if (g_config.JoystickEmul == 2) {
        XINPUT_STATE state;
        XInputGetState(0, &state);
        pji->dwFlags = JOY_RETURNALL;
        pji->dwXpos = state.Gamepad.sThumbLX + 32768;
        pji->dwYpos = state.Gamepad.sThumbLY + 32768;
        if (g_config.InvertYAxis) pji->dwYpos = 65536 - pji->dwYpos;
        // The 65536 value breaks XWA with in-game invert Y axis option
        pji->dwYpos = std::min(pji->dwYpos, DWORD(65535));
        //pji->dwZpos = state.Gamepad.bRightTrigger;
        pji->dwRpos = state.Gamepad.sThumbRX + 32768;
        pji->dwUpos = state.Gamepad.sThumbRY + 32768;
        //pji->dwVpos = state.Gamepad.bLeftTrigger;
        pji->dwButtons = 0;
        // Order matches XBox One controller joystick emulation default
// A, B, X, Y first
        pji->dwButtons |= (state.Gamepad.wButtons & 0xf000) >> 12;
        // Shoulder buttons next
        pji->dwButtons |= (state.Gamepad.wButtons & 0x300) >> 4;
        // start and back, for some reason in flipped order compared to XINPUT
        pji->dwButtons |= (state.Gamepad.wButtons & 0x10) << 3;
        pji->dwButtons |= (state.Gamepad.wButtons & 0x20) << 1;
        // Thumb buttons
        pji->dwButtons |= (state.Gamepad.wButtons & 0xc0) << 2;
        // Triggers last, they are not mapped in the joystick emulation
        if (state.Gamepad.bLeftTrigger > XINPUT_GAMEPAD_TRIGGER_THRESHOLD) pji->dwButtons |= 0x400;
        if (state.Gamepad.bRightTrigger > XINPUT_GAMEPAD_TRIGGER_THRESHOLD) pji->dwButtons |= 0x800;
        // These are not defined by XINPUT, and can't be remapped by the
        // XWA user interface as they will be buttons above 12, but map them just in case
        pji->dwButtons |= (state.Gamepad.wButtons & 0xc00) << 2;
        // XWA can map only 12 buttons, so map dpad to POV
        pji->dwPOV = povmap[state.Gamepad.wButtons & 15];

This will remove the throttle from the trigger (as well as remove the hardware mapping on the left trigger). People might want the right trigger to be fire (as I use it and some other folks) and the Left trigger to be something else other than throttle. Perhaps there can be functionality to combine multiple buttons, but that should be later down the line unless it can implemented smoothly.

I also recommend having two branches, one that is the stable branch (master branch) and the other the experimental. The stable one should be for the majority of users and may get features from the experimental branch if proven stable. This way a large amount of users will not be affected by these experimental changes.

[rdoeffinger]

It's better to post diffs because I can't really see what you changed. In particular I can't see what you mean by "as well as remove the hardware mapping on the left trigger". Anyway I made it an option. I don't have the time to maintain 2 branches, plus it only helps if there's enough testers and some way to get the experimental releases to them... Either way here is the latest code, with the black screen fix and all. ddraw.zip

[bguthrie1]

Ah here is what I've changed (please let me know if there is a more effective way to show whats changed)

//pji->dwZpos = state.Gamepad.bRightTrigger;
//pji->dwVpos = state.Gamepad.bLeftTrigger;

I've removed the Z and V axis/position mappings from the triggers.

I will take a look at the ddraw you posted.

[bguthrie1]

Triggers are good, glad that the throttle is defaulted to off. I still think that JoystickEmul should be defaulted to "0" however.

There seems to be a flickering issue with the textures though, I'll post in a separate issue.

[rdoeffinger]

I believe the worst issues should be resolved, so I'll close it. Reopen or open a new one if there are problems.