Silent-Hill-2-Enhancements
Silent-Hill-2-Enhancements copied to clipboard
elishacloud
[Consideration] Xidi as an alternative to XInput Plus
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.
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.
Fair enough, @Polymega . Why fix something that ain't broke? :) Thanks for the concise explanation.
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.
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.
Ok, great. I think the other two issues are easy to solve, if we want to think about switching to Xidi.
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. :)
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).
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.
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.
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.
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.
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
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
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.
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.
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?).
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.
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.
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.
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. 👍
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.
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.
@samuelgr, The only things I did for Windows 7 support was the following:
- 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.
- I added a
xinput1_4.dllproxy file into the package. For this I just renamed the 3rd partyxinput1_3.dllfile we were using with XInput Plus toxinput1_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
Sure, I can make that change. That is very doable. https://github.com/samuelgr/Xidi/issues/39
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.
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.iniwith 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).
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?
@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.
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.