[Consideration] Xidi as an alternative to XInput Plus

[r2rX]

Hello there,

This isn't an issue but I wanted to bring to your attention a very cool XInput to DInput project called Xidi. It's robust and easy to use. I've tested it with Silent Hill 2, 3 and 4 with great success (tested in Windows and Linux). All analog sticks, buttons, triggers and force feedback works. Silent Hill 2 (as well as 3 and 4..well 4 requires a complimentary .ini file but that's besides the point) only requires one file from Xidi, dinput8.dll, and that's it.

I know XInput Plus is absolutely fine but I thought to share this anyway. Might be worth testing. :) If not, all good.

[Polymega]

Hi there!

I received a few messages about Xidi in the past and, while the software looks great, there were a few concerns I had about it.

On the GitHub page it mentions it's only targeted for Windows 10 and 11. Ideally we'd want something that can work as far back as Windows 7 (like what XInput Plus does), as our minimum OS spec for the project is Win7. Well, technically, we 'support' as far back as WinXP but we don't advertise that. 😅

My other concern is the Visual C++ Runtime for Visual Studio 2022 dependency. A lot of people who use the project aren't computer-savvy so we try to mitigate how many Microsoft runtime redistributables users have to download. From how I understand it, XInput Plus just taps into and uses the official Microsoft XInput driver that is shipped with all modern Windows operating systems and doesn't require any other dependencies. From their site:

The Xbox 360 controller is recognized as an XInput controller using the driver for Windows (official driver) . The XInput controller has a DirectInput compatible function and can be used in both the above DirectInput format and XInput format. In Windows Vista or later, the driver is included in the OS, and the driver can be automatically installed and used just by connecting the XBOX360 controller.

From what I've read, there's a lot to like with Xidi, but I don't know if it'd be the best fit for our project at this moment.

[r2rX]

Fair enough, @Polymega . Why fix something that ain't broke? :) Thanks for the concise explanation.

[elishacloud]

On the GitHub page it mentions it's only targeted for Windows 10 and 11.

I can look into this, but it is probably just compilied targeting those versions of Windows. I can try and compile it targeting Windows XP, which is what we do with SH2EE.

My other concern is the Visual C++ Runtime for Visual Studio 2022 dependency.

This is just a compiler option. I can compile this with those runtimes included so there will be no outside dependancies.

B.T.W, on a tangent related to Xidi, it was working fine with a vanilla installation of SH2. With SH2:EE, however, the game wouldn't launch if I removed the Xinput Plus files (XInput1_3.dll, Dinput.dll and Dinput8.dll) and replaced it with the dinput8.dll from Xidi. Is the executable from the EE package hard-coded to look for XInput Plus's files in particular?

This should be looked at, even if we don't use Xidi. Maybe something we do is not quite right. Ideally, we should try and be compatible with as many of these types of tools as possible.

[r2rX]

I tested Xidi again and realized I forgot to install the VC++ 2022 redist. Once done, removing the Xinput Plus files and dropping in Xidi's dinput8.dll worked fine.

[elishacloud]

Ok, great. I think the other two issues are easy to solve, if we want to think about switching to Xidi.

[r2rX]

If you ever want to experiment and build Xidi in a way that works without depending on VC++ 2022, I'm more than happy to test. :)

[Polymega]

If those concerns can be resolved, then I'm open to use whatever is best for the project (for end user experience, ease of maintenance on our end, etc).

[r2rX]

The pro is that you're dealing with just one dll, as opposed to two (assuming this is a technical issue/debt of any importance). The only con I can think of is that adjusting parameters (i.e remapping layouts for the virtual controller) will have to be done manually through a Xidi.ini file, as opposed to XInput Plus' GUI. Although, such options could be exposed through a tab in the SH2EESetup so you could centralize everything, rather than referring to Xinput Plus' GUI.

[Polymega]

The only con I can think of is that adjusting parameters (i.e remapping layouts for the virtual controller) will have to be done manually through a Xidi.ini file, as opposed to XInput Plus' GUI.

That shouldn't be a concern for us. We include a preconfigured INI file for XInput Plus so users never have to adjust this. We've never received any reports of people wanting a feature to adjust this as, since we've pre-adjusted it for them, it's essentially plug-and-play for their controller.

[r2rX]

If that's the case, then Xidi works out-of-the-box without needing an .ini file. Of course, I've only tested this with an Xbox One and Series X controller but this should apply to any XInput controller.

[ThirteenAG]

Recently used Xidi in my scarface fix, it's good. Even modified it a bit, to have different sets of controls for InCar/OnFoot/InMenu cases.

[elishacloud]

Unfortunately, I cannot compile this for Windows XP. However, I don't see any reason why this would not work on Windows 7. I don't have one to test though. Anyways, this Xidi may be much better for users who use different controllers.

Here is the Xidi build without the Visual C++ Runtime requirements: dinput8.zip

[Polymega]

Question to any Xidi users here:

SH2 PC has this annoying quirk here: https://enhanced.townofsilenthill.com/SH2/troubleshoot.htm#my-gamepad-is-not-being-detected-by-the-game

Silent Hill 2 PC detects and uses the first gamepad you connect to your computer. Disconnect any other gamepads that are connected to your PC prior to launching the game. This may include wireless dongles, receivers, or non-gamepad peripherals that are detected as gamepads by your PC. You may need to then disconnect and reconnect the gamepad you wish to use. This is the most common reason why the game does not detect the gamepad.

Does Xidi get around this? I ask from some of the things I read in the Q&A: https://github.com/samuelgr/Xidi#questions-and-answers

[r2rX]

Unfortunately, I cannot compile this for Windows XP. However, I don't see any reason why this would not work on Windows 7. I don't have one to test though. Anyways, this Xidi may be much better for users who use different controllers.

Here is the Xidi build without the Visual C++ Runtime requirements: dinput8.zip

Here are some test results (with Xbox One Controller & Xbox Series X Controller):

Linux (WINE/Proton) - Works 100% Windows XP - Cannot test (no drivers for controllers) Windows Vista - Cannot test (no drivers for controllers) Windows 7 - Works 100% Windows 8 /8.1 - Untested (but pretty sure it works) Window 10 - Works 100% Windows 11 - Works 100%

If someone with an Xbox 360 pad, Logitech Xinput pad or other XInput pad (that has drivers for XP and Vista, optionally) can test XP and Vista, that'd be great. VMWare works fine for testing in VMs of the OS's.

Question to any Xidi users here:

SH2 PC has this annoying quirk here: https://enhanced.townofsilenthill.com/SH2/troubleshoot.htm#my-gamepad-is-not-being-detected-by-the-game

Silent Hill 2 PC detects and uses the first gamepad you connect to your computer. Disconnect any other gamepads that are connected to your PC prior to launching the game. This may include wireless dongles, receivers, or non-gamepad peripherals that are detected as gamepads by your PC. You may need to then disconnect and reconnect the gamepad you wish to use. This is the most common reason why the game does not detect the gamepad.

Does Xidi get around this? I ask from some of the things I read in the Q&A: https://github.com/samuelgr/Xidi#questions-and-answers

Looking at the behavior of XInput, it supports up to 4 controllers. The first controller connected will act as controller 1, second as 2 etc. As far as Xidi and SH2 are concerned, it will refer to the first controller assigned. Testing the game out, with both controllers connected, it will only register the pad that is connected first in the OS (Linux and Windows). The only way around it is if there's a method to change the XInput assignment order.....unsure what the behavior would be when mixing XInput and DInput controllers.

[samuelgr]

Does Xidi get around this? I ask from some of the things I read in the Q&A: https://github.com/samuelgr/Xidi#questions-and-answers

The enumeration bit is somewhat intricate so let me try to shed some light on it. The short answer is yes, Xidi does work around this quirk. (It isn't just SH2 that has this quirk either, lots of games just use the first gamepad - or some buggy games just use the first DirectInput device and assume it is a gamepad, whether that's true or not.)

The somewhat longer answer is, in general, Xidi will present its own virtual controllers first. The very first controller a game like SH2 will see is Xidi Virtual Controller 1 (XInput player 1) so it would use that. Exception: if, when the user starts the game, there are no XInput controllers plugged in and at least 1 non-XInput controller plugged in, then there is a high likelihood they are trying to use the non-XInput controller. In this case Xidi will first present all the non-XInput controllers it sees (in whatever order the system enumerates them) before it presents its own virtual controllers.

[Polymega]

Hi @samuelgr,

Nice to have the man himself here to better explain! Thank you.

The very first controller a game like SH2 will see is Xidi Virtual Controller 1 (XInput player 1) so it would use that.

This is fantastic then. And if I'm reading the second-to-last question in your FAQ correctly, the use of Xidi would also allow the player to plug in a controller after the game launches thanks to Xidi reserving the 'first gamepad slot' the game is looking for as a virtual device to swap controllers in and out? (This is the other annoying quirk of controllers with SH2 PC.)

Exception: if, when the user starts the game, there are no XInput controllers plugged in and at least 1 non-XInput controller plugged in, then there is a high likelihood they are trying to use the non-XInput controller. In this case Xidi will first present all the non-XInput controllers it sees (in whatever order the system enumerates them) before it presents its own virtual controllers.

I don't think that's too much of a concern for use with this project. While we can't account for every use case scenario, the majority of people use an XInput controller (typically by Xbox). I've seen a handful of DualShock 3/4 (DirectInput) users and, very rarely, Switch Pro controller users (which I'm still unsure if that controller is detected as DirectInput or just a generic HID device by Windows?).

[samuelgr]

And if I'm reading the second-to-last question in your FAQ correctly, the use of Xidi would also allow the player to plug in a controller after the game launches thanks to Xidi reserving the 'first gamepad slot' the game is looking for as a virtual device to swap controllers in and out?

Correct, that's how Xidi does hot-plugging. A user could even unplug an XInput controller, plug in a different one, and assuming that new controller gets assigned player 1 it would just start working in place of the old one.

I don't think that's too much of a concern for use with this project.

Acknowledged, I just figured that info might be useful for completeness. The thinking behind that feature is that, hypothetically, if Xidi were distributed alongside a game (or patch set) and users might or might not be using XInput controllers then Xidi would do its work where appropriate and intelligently get out of the way otherwise.

[Polymega]

It's been a pleasure having you join us to further discuss this. I believe we should make the switch from XInput Plus to Xidi as part of the next update then. 😄

Thank you specifically for your creation and continued work with Xidi, Samuel! And thank you Elisha and r2rX, as well! We'll get this prepped for inclusion down the line for the next project update.

[mercury501]

Hi all, I have a quick question, will this render this patch non functional then? Because my mouse input work is relying on this, if so maybe I can find a way to make it work with xidi, since it always has a virtual game pad connected if I read that right?

-edit: from the readme it looks like it's using dinput down the line anyway, so should still work.

[elishacloud]

I have a quick question, will this render this patch non functional then?

No, that patch is still needed with Xidi.

edit: from the readme it looks like it's using dinput down the line anyway, so should still work.

We are using the dinput interface into Xidi, so as long as your updates are working with dinput then it should be ok. 👍

[samuelgr]

I'm happy to help and glad to see Xidi being used in more places. @r2rX has been great about championing the project and spreading the word, both on and off of GitHub.

I'll be interested to see how things go when it comes to getting Xidi compiled for and running on Windows 7. I don't have the bandwidth to test and support this myself, but if there are any minor coding changes that would somehow help with compatibility I am happy to consider making them.

[r2rX]

I'm happy to help and glad to see Xidi being used in more places. @r2rX has been great about championing the project and spreading the word, both on and off of GitHub.

Xidi is fantastic as a well engineered and functional Xinput to DInput project and essential for game preservation, so I'm just doing my duty to try and help. Thanks @samuelgr for creating Xidi and @elishacloud and @Polymega for considering it. :)

I'll be interested to see how things go when it comes to getting Xidi compiled for and running on Windows 7. I don't have the bandwidth to test and support this myself, but if there are any minor coding changes that would somehow help with compatibility I am happy to consider making them.

Well, elisha's modified dinput8 worked perfectly in Windows 7 without needing to install VC 2022. Not sure how it applies to the other components and even hookshot but (I'm assuming) the potential is there.

[elishacloud]

@samuelgr, The only things I did for Windows 7 support was the following:

1. I changed the project settings to "Multi-threaded (/MT)". This will tell the compiler to include the runtime components inside the dinput8.dll file. This way users don't need to install the Microsoft Runtime. See screenshot at the bottom of this post.
2. I added a xinput1_4.dll proxy file into the package. For this I just renamed the 3rd party xinput1_3.dll file we were using with XInput Plus to xinput1_4.dll. The exports are the same so it works just fine. This allows Windows 7 and newer to use the Xidi.

It looks like Xidi is statically loading the xinput1_4.dll file. If this file is missing (which it typically would be on Windows 7) then Xidi won't work.

If you wanted to make a change to allow supporting older operating systems you could dynamically load the xinputX_X.dll file, rather than statically loading it. Just have it check for xinput1_4.dll. If that does not exist then check for xinput1_3.dll. If that does not exist then check for xinput1_2.dll. And so on. The exports used by Xidi look like they are the same for these different versions of xinput.

Here is the proxy dll I used: XInput1_4.zip

[samuelgr]

Sure, I can make that change. That is very doable. https://github.com/samuelgr/Xidi/issues/39

[elishacloud]

Thanks @samuelgr!

[Polymega]

I'm having a bit of trouble getting Xidi to work with the game. May I ask for some help? I'm using the build Elisha compiled (found here). I read over Xidi's documentation and, I don't know if it is needed for this game, but I also created a Xidi.ini with the following:

[Mapper]
Type            = StandardGamepad

[CustomMapper]

StickLeftX      = Axis(X)
StickLeftY      = Axis(Y)
StickRightX     = Axis(Z)
StickRightY     = Axis(RotZ)

DpadUp          = Pov(Up)
DpadDown        = Pov(Down)
DpadLeft        = Pov(Left)
DpadRight       = Pov(Right)

ButtonLB        = Button(5)
ButtonRB        = Button(6) 
TriggerLT       = Button(7)
TriggerRT       = Button(8)
ButtonBack      = Button(9)
ButtonStart     = Button(10)
ButtonLS        = Button(11)
ButtonRS        = Button(12)

ButtonA         = Button(2)
ButtonB         = Button(3)
ButtonX         = Button(1)
ButtonY         = Button(4)

However, I don't think it's hooking/working. The typical problems are happening for me: No triggers, no right stick, etc.

[r2rX]

I'm having a bit of trouble getting Xidi to work with the game. May I ask for some help? I'm using the build Elisha compiled (found here). I read over Xidi's documentation and, I don't know if it is needed for this game, but I also created a Xidi.ini with the following:

[Mapper]
Type          = StandardGamepad

[CustomMapper]

StickLeftX        = Axis(X)
StickLeftY        = Axis(Y)
StickRightX       = Axis(Z)
StickRightY       = Axis(RotZ)

DpadUp            = Pov(Up)
DpadDown      = Pov(Down)
DpadLeft      = Pov(Left)
DpadRight     = Pov(Right)

ButtonLB      = Button(5)
ButtonRB      = Button(6) 
TriggerLT     = Button(7)
TriggerRT     = Button(8)
ButtonBack        = Button(9)
ButtonStart       = Button(10)
ButtonLS      = Button(11)
ButtonRS      = Button(12)

ButtonA           = Button(2)
ButtonB           = Button(3)
ButtonX           = Button(1)
ButtonY           = Button(4)

However, I don't think it's hooking/working. The typical problems are happening for me: No triggers, no right stick, etc.

When I tested it, there was no need to create Xidi.ini and adjust a custom mapping. When replacing Xinput Plus, you also have to remove dinput.dll and xinput1_4.dll....so the only file that should be present is dinput8.dll (from Xidi).

[Polymega]

When I tested it, there was no need to create Xidi.ini and adjust a custom mapping. When replacing Xinput Plus, you also have to remove dinput.dll and xinput1_4.dll....so the only file that should be present is dinput8.dll (from Xidi).

I see, thanks. Elisha included an Xinput1_4.dll file in his test build, so I figured I'd need that. I removed this file and can use triggers again, but I am still experiencing a few other issues:

With XInput Plus, I modified its ini so that if a player used a DirectInput or XInput controller the functions to control the game should be using the same button layout.

To achieve this, I first plugged in an old DirectInput controller to the game and assigned game functions accordingly. This told me which button # should be assigned to which function for XInput controllers:

Then, I went into XInput Plus' ini and changed things up. So instead of "A" being assigned to "Button 1", it would instead be assigned to "Button 2" (to follow the image list above by matching the button placement of an Xbox controller to a DirectInput controller).

I hope that made sense. Check out the [X2DInput] section near the bottom of this file: XInputPlus.zip

I was also having trouble making the right joystick work to control the search cam, but it looks like I resolved that by changing the "Controller type for search cam movement" to DirectInput, instead of XInput, even with the use of Xidi. Just want to make sure that sounds correct to you?

[r2rX]

@Polymega , would you happen to have the MS VC++ 2022 redistribution installed? Just confirmed with my setup, which has the redist already installed, and dinput8.dll was all that was necessary to operate. @elishacloud, can I assume the Xinput .dll is required in order to compensate for not having to install the redist? I will create a new prefix to try with both .dll's, sans installing the redist, and report back.

[r2rX]

So I finished testing in both Windows and Linux (with the VC redist absent). In both instances, all buttons, analog sticks and force feedback worked fine for me whether XInput1_4.dll was present or not.

[Polymega]

would you happen to have the MS VC++ 2022 redistribution installed?

I don't. And for sake of testing purposes, I'd like to keep it uninstalled. I believe Elisha's build removed the requirement to install the redistributable.

So I finished testing in both Windows and Linux (with the VC redist absent). In both instances, all buttons, analog sticks and force feedback worked fine for me whether XInput1_4.dll was present or not.

Did you test using his build as well? My tests are on Win10 for now.

[r2rX]

would you happen to have the MS VC++ 2022 redistribution installed?

I don't. And for sake of testing purposes, I'd like to keep it uninstalled. I believe Elisha's build removed the requirement to install the redistributable.

Alright. Just wanted to confirm.

So I finished testing in both Windows and Linux (with the VC redist absent). In both instances, all buttons, analog sticks and force feedback worked fine for me whether XInput1_4.dll was present or not.

Did you test using his build as well? My tests are on Win10 for now.

The tests were done with elisha's build in Linux via WINE prefix and Windows 11.

[Polymega]

Just to confirm, though: I am now able to use triggers with an XInput controller again. My current situation is that using a Xidi.ini file doesn't seem to re-assign the buttons as I'd like. For example, I want the A button on an XInput controller to act as Button 2 on a DirectInput controller. I figured this line in the ini would make it work, but doesn't seem to?

ButtonA         = Button(2)

I might be doing something wrong with the ini?

[Polymega]

Figured that out. Needed to name it "custom", as in:

[Mapper]
Type                = Custom

[samuelgr]

I tested @elishacloud's build in a different game and it seems to work as expected on Windows, with and without the included xinput1_4.dll proxy. Once I implement a change that addresses https://github.com/samuelgr/Xidi/issues/39 the proxy shouldn't be needed anymore.

One thing worth noting is that the xinput1_4.dll proxy is actually an XInput Plus DLL file, so most likely you will want to get rid of the XInputPlus.ini file if it exists. If you have an XInputPlus.ini file in the same directory then XInput Plus will do its own remapping before Xidi sees the controller, then Xidi will do its own additional remapping on top of that.

I resolved that by changing the "Controller type for search cam movement" to DirectInput, instead of XInput

I assume this refers to which API the game uses to communicate with controllers? Xidi only does any sort of re-mapping via DirectInput, it doesn't do anything on the XInput API path. I believe XInput Plus can do re-mapping on both paths.

[Polymega]

I assume this refers to which API the game uses to communicate with controllers? Xidi only does any sort of re-mapping via DirectInput, it doesn't do anything on the XInput API path. I believe XInput Plus can do re-mapping on both paths.

Great to know. We'd need to change the default setting for "Controller type for search cam movement" in the Configuration Tool to "DirectInput" then, if using Xidi.

---

I'm going to keep testing and I'll report back once I'm done. @samuelgr I may have a preconfigured ini to send you to add to XidiGameConfigurations once I'm done.

To reiterate the purpose of this custom ini: I first assigned all functions in the game's Options menu using an actual DirectInput controller. I will then remap Xidi buttons through Xidi.ini to correspond to this (such as changing the "A" button to "Button 2" instead of "1"). That way, the button config will be good to go out of the box whether a player is using an DirectInput or XInput controller while Xidi is in the game's directory.

Really, I think the only change that needs to happen is changing the "A" button to "Button 2" (which means the "X" is changed to "Button 1").

---

One thing I'm noticing though is that if Xidi is in the game's directory and you play with a DirectInput controller, the controller no longer works?

[samuelgr]

One thing I'm noticing though is that if Xidi is in the game's directory and you play with a DirectInput controller, the controller no longer works?

Do you have any XInput controllers plugged in (or, if they are wireless, turned on and connected) when you launch the game? If you do then Xidi will always enumerate its own virtual controllers first.

You can enable logging in the INI file to see the enumeration order.

[Log]
Enabled = yes
Level = 4

[Polymega]

Do you have any XInput controllers plugged in (or, if they are wireless, turned on and connected) when you launch the game? If you do then Xidi will always enumerate its own virtual controllers first.

No, I shouldn't. I made sure no other controllers were plugged in from what you previously told me:

Exception: if, when the user starts the game, there are no XInput controllers plugged in and at least 1 non-XInput controller plugged in, then there is a high likelihood they are trying to use the non-XInput controller. In this case Xidi will first present all the non-XInput controllers it sees (in whatever order the system enumerates them) before it presents its own virtual controllers.

I am using a Logitech RumblePad 2 for tests with a DirectInput controller. The log looks to have found it?

[10/29/2022 13:13:53] [D] Starting to enumerate DirectInput devices.
[10/29/2022 13:13:53] [D] Enumerate: DirectInput device "Logitech RumblePad 2 USB" is being presented to the application.
[10/29/2022 13:13:53] [D] Enumerate: System has no XInput devices, so Xidi virtual controllers are being presented to the application after other controllers.
[10/29/2022 13:13:53] [I] Mappers assigned to controllers...
[10/29/2022 13:13:53] [I]     [1]: Custom
[10/29/2022 13:13:53] [I]     [2]: Custom
[10/29/2022 13:13:53] [I]     [3]: Custom
[10/29/2022 13:13:53] [I]     [4]: Custom

But it doesn't work when the Xidi dll file is present in the game's directory. Here is the log: Xidi_DInput8_sh2pc.exe_16284.log

[Polymega]

Here is the ini I made for Xidi for remapping:

[Mapper]
Type            = Custom

[CustomMapper]

StickLeftX      = Axis(X)
StickLeftY      = Axis(Y)
StickRightX     = Axis(Z)
StickRightY     = Axis(RotZ)

DpadUp          = Pov(Up)
DpadDown        = Pov(Down)
DpadLeft        = Pov(Left)
DpadRight       = Pov(Right)

ButtonLB        = Button(5)
ButtonRB        = Button(6) 
TriggerLT       = Button(7)
TriggerRT       = Button(8)
ButtonBack      = Button(9)
ButtonStart     = Button(10)
ButtonLS        = Button(11)
ButtonRS        = Button(12)

ButtonA         = Button(2)
ButtonB         = Button(3)
ButtonX         = Button(1)
ButtonY         = Button(4)

I suppose I could greatly cut this down to something like the following and it will still work?

[Mapper]
Type            = Custom

[CustomMapper]

ButtonA         = Button(2)
ButtonX         = Button(1)

[samuelgr]

But it doesn't work when the Xidi dll file is present in the game's directory. Here is the log: Xidi_DInput8_sh2pc.exe_16284.log

I might need to investigate a bit further. It looks like the game is enumerating twice, the first time it is presented the Logitech controller and the second time it isn't, and then the second time it is picking the virtual controller.

I suppose I could greatly cut this down to something like the following and it will still work?

If you are just taking StandardGamepad and modifying it then yes, but you will want to specify Template = StandardGamepad as well.

[Polymega]

If you are just taking StandardGamepad and modifying it then yes, but you will want to specify Template = StandardGamepad as well.

Here's where things get funky for me. I was following your read me here and, if I understand correctly, this should be all I need to do to change the assignments of just those two buttons for XInput Controllers:

[CustomMapper:ModifiedStandardGamepad]

; Imports all of the element mappers from StandardGamepad.
; This line is allowed to appear anywhere in the section, including between or after the element mappers below.
Template            = StandardGamepad

; These changes are applied on top of the template.
ButtonA             = Button(2)
ButtonX             = Button(1)

Unfortunately, this doesn't work for me. However, this does work, but requires listing out all button mappings:

[Mapper]
Type            = Custom

[CustomMapper]

StickLeftX      = Axis(X)
StickLeftY      = Axis(Y)
StickRightX     = Axis(Z)
StickRightY     = Axis(RotZ)

DpadUp          = Pov(Up)
DpadDown        = Pov(Down)
DpadLeft        = Pov(Left)
DpadRight       = Pov(Right)

ButtonLB        = Button(5)
ButtonRB        = Button(6) 
TriggerLT       = Button(7)
TriggerRT       = Button(8)
ButtonBack      = Button(9)
ButtonStart     = Button(10)
ButtonLS        = Button(11)
ButtonRS        = Button(12)

ButtonA         = Button(2)
ButtonB         = Button(3)
ButtonX         = Button(1)
ButtonY         = Button(4)

It's certainly not a problem to list all button mappings in an ini like this, but figured I'd tell you the shorter method (above) doesn't appear to be working for me.

[samuelgr]

Did you also change your Mapper type from "Custom" to "ModifiedStandardGamepad?"

EDIT: You might also want to include the configuration for B since it appears to differ from StandardGamepad as well.

[Polymega]

Did you also change your Mapper type from "Custom" to "ModifiedStandardGamepad?"

Ah, that was indeed the problem. Thanks.

EDIT: You might also want to include the configuration for B since it appears to differ from StandardGamepad as well.

Great catch. Thanks again! If you'd like use it, here are the two files for a Xidi configuration with SH2 PC: keyconf.zip

Why two? It includes both Xidi.ini and keyconfig.dat (the file the game uses to store keybinds). As previously mentioned, this configuration is mapped for DirectInput controllers and the Xidi ini modifies a few XInput button assignments to work alongside the configuration for the DirectInput button layout.

This way, the controller layout should work/be the same for both DInput and XInput controller users.

Let me know if I can help any with testing that enumeration concern with DirectInput controllers.

Thanks Samuel

[samuelgr]

@Polymega regarding the enumeration concern could you please re-capture a log with this development build? (It should work without the Visual Studio 2022 runtime installed - I made the same change @elishacloud did.)

This won't fix the problem, but it will output more information in the log that would help me figure out the reason for the behavior.

Xidi-v4.0.4-dev.3.1+46c156b1.dirty.zip

[Polymega]

Happy to do so. Attached is the log: Xidi_DInput8_sh2pc.exe_11208.log

[samuelgr]

@elishacloud https://github.com/samuelgr/Xidi/commit/1ad4f57d856519f248917a83d87469a5f0938f6a contains the change to pick an XInput library dynamically.

@Polymega From the log you uploaded (thank you, by the way) it looks like the game is trying to enumerate twice:

• The first time it looks for all attached controllers (dwDevType = 0x00000004, dwFlags = 0x00000001) and so it gets the Logitech Rumblepad first followed by the Xidi virtual controllers, as expected.
• The second time it asks for only attached controllers that support force feedback (dwDevType = 0x00000004, dwFlags = 0x00000101) and for some reason the system does not include the Logitech Rumblepad as supporting force feedback, so Xidi only presents the virtual controllers. The game seems to prioritize what it sees as supporting force feedback, so it picks the first device it gets in this round of enumeration, namely the first Xidi virtual controller.

Without Xidi, does your Logitech Rumblepad work in SH2 (or other games) with force feedback? I also have a Rumblepad 2 with all the Logitech software installed, and with a small DirectInput test program - even when going through Xidi - my machine does enumerate it as a device that supports force feedback, and Xidi will enumerate it before its own virtual controllers.

[Polymega]

Hi @samuelgr,

Without Xidi, does your Logitech Rumblepad work in SH2 (or other games) with force feedback?

No, it does not. And to be fair, I can't get ForceFeedback (FF) to work with any game using the Logitech Rumblepad 2.

even when going through Xidi - my machine does enumerate it as a device that supports force feedback, and Xidi will enumerate it before its own virtual controllers.

I was always under the assumption that Windows broke/removed FF from modern operating systems? And that for programs to make FF work on DirectInput controllers they have to do it through some trickery?

I also have a Rumblepad 2 with all the Logitech software installed, and with a small DirectInput test program

My RumblePad 2 was bought second-hand on eBay many years back. It didn't include any installation software, so I'm not sure if that's the issue here or not?

Do you have any ideas or recommendations on how to best approach the use of a DirectInput device with the game while using Xidi?

[elishacloud]

samuelgr/Xidi@1ad4f57 contains the change to pick an XInput library dynamically.

Great! Thanks!

From the log you uploaded (thank you, by the way) it looks like the game is trying to enumerate twice:

I don't think this is from the game. The game may only do the enumeration once. However, our module also does an enumeration as well. That might be the second (or really the first) enumeration. Is there an issue that the enumeration happens twice? We just do the enumeration for logging purposes.

[samuelgr]

There is no issue that the enumeration happens twice... any number of times is totally fine as far as Xidi and DirectInput are concerned.

The first time around, the request is for all attached controllers, so Xidi presents the Logitech controller first and then the virtual controllers. However, the game doesn't actually bind to a controller this time.

The second time around, the request is for only those attached controllers that specifically support force feedback. Since as far as the system is concerned the Logitech controller doesn't, it is excluded from the enumeration. It is here that the game binds to the first controller it sees, which is the Xidi virtual controller (because these do support force feedback and hence are included in the enumeration).

Two questions come to mind:

1. Without using Xidi, does the Logitech controller work? (This can be tested by deleting Xidi's dinput8.dll file and running the game.)
2. If you were to turn off force feedback/vibration in the game's settings and/or the patch's settings, does that affect the enumeration behavior? (This can be tested by changing the appropriate settings and then using Xidi to get another log.)

[Polymega]

The game may only do the enumeration once. However, our module also does an enumeration as well. That might be the second (or really the first) enumeration.

I tested vanilla SH2 PC with Xidi and, interestingly, the DirectInput controller (RumblePad 2) still was not working with Xidi. I've attached the log: Xidi_DInput8_sh2pc.exe_12336.log

1. Without using Xidi, does the Logitech controller work? (This can be tested by deleting Xidi's dinput8.dll file and running the game.)

Yes, without Xidi the RumblePad 2 works with the game/our project.

2. If you were to turn off force feedback/vibration in the game's settings and/or the patch's settings, does that affect the enumeration behavior? (This can be tested by changing the appropriate settings and then using Xidi to get another log.)

I've disabled/enabled vibration both through the game's options menu and on the RumblePad 2 controller itself (it has a "Vibration" button on it). No matter the combination, the RumblePad 2 was not picked up by the game when Xidi was in use. Because of this, I think the log attached above should cover these scenarios but, if not, let me know and I can make you another log using whatever testing methods you'd like me to perform.

Before we continue on with this, I'd first like to thank you again for your time and assistance with us, Samuel. It's not my place to say this, but if you'd like to test out the game for yourself you can grab a copy of the game here:

https://www.myabandonware.com/game/silent-hill-2-restless-dreams-bgd#download

Download the "fully extracted version." I provided the site this download, and it is a rip from my real, physical copy of the game. Note that everything in it is 100% vanilla, including its DRM-riddled executable. So if you download the game, be sure to replace the main binary with this no-CD/DRM free version: https://files.townofsilenthill.com/SH2EE/packages/SH2EE_Enhanced_EXE_NA_v1.0.zip