ViGEm and DirectInput emulation
-
Originally posted by evilC
Shaul has ceased vJoy development as he feels that ViGEm renders it obsolete, however, through previous discussion with Nefarius, it seems that there are currently no plans to implement support for DI controllers into ViGEm.
So that leaves us with an EOL product and no planned replacement...
Is this correct? If so, is there maybe any chance we can persuade Shaul to implement DI support into ViGEm? -
Originally posted by shaul
I have been working on vJoy for over a decade, and I think that the latest version (2.1.8) is stable.
There are several factors that lead me to the conclusion that it's time to move on:- The price of signing a driver has become intolerable both in $$$ and in bureaucracy.
- vJoy is mature and I feel I need to continue to other things.
- The architecture I chose back in 2005 is clearly inferior to the one chosen by Nefarius.
It is now the time to implement a generic joystick module (DI Support) that will be "Plugged in" to the virtual USB bus implemented by Nefarius.
Before anyone begins the implementation it is important to receive his permission to incorporate the module as only he has the permission to sign the driver.
Don't think I have a special advantage in writing this module. The technology and the architecture are different from the ones used in vJoy.Good luck to whoever undertakes the task!
-
Originally posted by evilC
Is there anyone around who is capable of / interested in doing it?
I certainly am not. If someone laid down the framework, I could probably do some work on it, but on my own, I would not even know where to begin.
I suppose my main concern is that should a bug be found, or there is some change in windows which breaks things, we have no way of pushing out a fixed version. If that eventuality arises, is there maybe any chance we could sign with Nefarius' cert? -
Originally posted by shaul
@evilC#125
I think the architecture will have to be so that will have to integrate with Nefarius' project hence sign it with his certificate. -
Originally posted by IgelRM
Hello, this is an interesting thread to read.
I wonder if I understood that correctly, this module would add support for DirectInput controllers to transfer their calls to XInput ones, right?
That would be amazing and better way then the current Scp Toolkit and XOutput method.Btw for anyone reading this that doesn't know the price of an EV certificate (like me previously) that is required for activating the driver except when using test mode which is complicated for the average user, it is 309€ to 709€ for 1 or respectively 3 years on GlobalSign. So thanks for your coding and financial efforts. (https://www.globalsign.com/en/code-signing-certificate/ev-code-signing-certificates/)
-
Originally posted by shaul
@IgelRM#129
I meant that the current project Nefarius is leading offers a virtual USB bus plus several optional virtual devices that can be plugged it to it. If I am not mistaken, the list of optional devices include now PSP, Xbox One and Xbox360.
My suggestion was to add a generic joystick (actually any HID) to the list.As for the price of an EV certificate - you need to add to it the price of the Notary approval of your identification and the endless bureaucracy required my Microsoft.
-
Originally posted by evilC
@IgelRM#129 No.
What this is proposing is for ViGEm to gain the ability to create virtual DirectInput controllers, like it can create virtual Xbox or Playstation controllers.
DirectInput to XInput is already possible without XOutput.
You can use [url=https://autohotkey.com/boards/viewtopic.php?f=19&t=12249]UCR[/url] to read your DirectInput stick, create a virtual Xbox controller, and map the inputs of the DI stick to the XI controller. If you need to stop the game from seeing the DirectInput stick, use [url=https://autohotkey.com/boards/viewtopic.php?t=34890]WhiteKnight[/url] (Which wraps HidGuardian / HidCerberus) -
Originally posted by IgelRM
@evilC#132 Thanks explaining this.
The tool you posted looks nice but relies on vJoy and ScpVBus. I was hoping for a efficient solution that only requires the installation of one driver like ViGEm does.
Another problem that isn't solved with either UCR or XOutput is rumble support.So I'm hoping for someone to build DirectInput controller input support into ViGEm.
-
Originally posted by evilC
UCR was just a proof-of-concept, started back when I only used Autohotkey. I have now progressed onto C# and am starting to collaborate with other people on a replacement.
With the new version, we are aiming to make it simple to plug in/out support for various APIs (And their associated drivers).
FFB is a stretch goal, especially converting DirectInput FFB to XInput rumble, but we definitely want to try and support it in some form.
The current plan is to support DirectInput via vJoy (Pure vJoy, no SCPVBus required) and ViGEm for console controllers - so at least that means you can cut out SCPVBus.
But all this is probably a while off, we are yet to have a version which would be of any practical use.
If you have any development skills, you are certainly welcome to pitch in - there is so much else to do, that FFB is kind of taking a back seat at the moment. If you want to tinker and see if you can work out how to integrate FFB into our code, then feel free.
We can be found in this discord channel: https://discord.gg/MmnhQYQ -
Originally posted by nefarius
Nice to see some life here
I'm currently investigating an interesting DInput component: https://github.com/nefarius/vmulti -
Originally posted by IgelRM
@nefarius#141 Hey nefarius,
nice to see you here. I am still a bit confused about ViGEm's functionality. Isn't the subproject 360cetoViGEm the solution to the problem I described above? -
Originally posted by nefarius
>
@IgelRM#142 360cetoViGEm
It is a demo project which has a hard-coded X360 target pad implemented, but can be changes to emulate a DS4 ofc. as long as you implement button and axis translation routines.
-
Originally posted by evilC
Ooh, interesting...
I am currently implementing Interception for keyboard / mouse IO, I take it that vmulti is output only? Can it synthesize input coming from a specific device, or just "synthetic" input? If so, can it synthesize input coming from a device which is not present on your system?
