Night in the Woods x360 compatability patch, and a few questions for the devs...

Discussion in 'x360ce' started by An0Hit0, Mar 8, 2017.

  1. An0Hit0

    An0Hit0 New Member

    Messages:
    2
    Likes Received:
    0
    Hi, I just wanted to let everyone know I made a patch to get Night in the Woods working with x360ce. I was a Kickstarter backer for the game, so I could not let the lack of x360ce support stand. Also I had been wanting to see what could be done about getting Unity games to work with x360ce for a while, since Unity is starting to be used by a lot more games and the lack of support for x360ce can be a real issue.

    As it turns out Night in the Woods actually does use XInput through it's "mono.dll" file. The issue was just getting the game to ignore RawInput controllers, and making sure x360ce was loaded only from "mono.dll" and not the main .exe file. I haven't looked into this extensively, but I wonder if XInput is supported the same way in other Unity games, which would mean my patch would work for those games too. Might be worth looking into if anyone wants to check.

    Anyway, to the devs, I was looking at x360ce's source code, and there seems to be a lot of stuff in there. I was a bit confused by this because there are fewer than 10 function calls in the entire XInput specification, so I didn't really think x360ce would need to do that much. There is also stuff like hooking, which I am not sure what the purpose of is. I mean, if you support the XInput interface the the same manner as the original .dll's, why would you need to hook anything?

    Also, is there some reason you haven't tried to support RawInput or DirectInput yet? Originally I was going to do my patch as a forwarder from RawInput to Xinput so I could just let x360ce handle the configuration stuff, but as it turns out it wasn't necessary. Still there are a lot of games that only use RawInput or DirectInput with poor controller support that would benefit from something like x360ce, so I was wondering why it hasn't been done yet? If the issue is because (at least in the case of RawInput) the interface functions are in system dll's I wrote a script called ShimmySham that can easily generate shims for system .dll files. This lets you intercept system calls in a relatively non-invasive way, and with a high level of compatibility with things like copy protection. Maybe it's something you guys could use?

    Anyway, since I have made it one of my missions in life to fix Unity's horrible controller support, if anyone else knows of any Unity games that load an XInput .dll but are not compatible with x360ce, let me know and I will try to have a look at them.
  2. NGEmu.com Advertisement

  3. Squall-Leonh@rt

    Squall-Leonh@rt Maybe I'm a Lion

    Messages:
    4,973
    Likes Received:
    109
    Because a good majority of xinput titles check for a specific extension to the device string in order to disable DirectInput enumeration on the xinput 'pad'. Others check the device name, or product and vendor id of the device.

    To tell the application that the pad attached is xinput and does not need to enumerate it as dinput as well, the application must be 'hooked'.

    you cannot emulate "Raw" input, it reads the pads HID data directly and is interpretted by the application. Hence why Unity incorporates controller profiles in its developer sdk.

    and why should we do anything regarding DirectInput when its already the stock standard that the majority of controls support?
  4. An0Hit0

    An0Hit0 New Member

    Messages:
    2
    Likes Received:
    0
    So are you hooking the DirectInput calls then? I'm not sure how you are going about that, but I would think a DirectInput shim to block device enumeration would be an easier and less hacky solution. But I haven't really looked into this issue extensively or anything.

    I'm not sure why you think that... RawInput has an API just like XInput does. It's just that most of the calls are located in user32.dll, making it more difficult to hook. In order to block RawInput and get Unity to use x360ce as a fallback, I had to hook functions in both user32.dll and kernel32.dll. It's perfectly doable, though not as simple as loading an XInput .dll.

    As it turns out, there are a number of games that use DirectInput that don't allow or have arbitrary limits on the way a controller can be configured, so it's not as much of a non-issue as you might think. Even more of a problem can be the way deadzones are handled (or not handled as the case may be), and I have seen people create fixes just for this issue alone.

    I mean fixing all the issues Windows has with controller support would be a pretty massive undertaking, and I wouldn't blame you for not wanting to take on writing DirectInput and RawInput wrappers in addition to what you've already done. But it really would be nice if someone would because the whole situation is really a mess right now.

Share This Page