vJoy icon indicating copy to clipboard operation
vJoy copied to clipboard

Complete instructions for building/writing a feeder?

Open WasabiFan opened this issue 8 years ago • 10 comments

Currently, I am trying to get a simple test app up-and-running that uses the Xinput-based vJoy library. I was able to successfully install the driver from the most recent Xbox branch release, but actually getting a feeder running is proving very challenging.

At first, I simply tried opening the solution in vJoy\apps\vJoyFeeder in VS 2015. When I attempt to build the project, I get the following errors (copied from the output window):

1>------ Build started: Project: vJoyFeeder, Configuration: Debug x64 ------
1>  "<path to repo>\vJoy\apps\vJoyFeeder\x64\Debug\CreateVersion.exe' is not recognized as an internal or external command,
1>  operable program or batch file.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): error MSB3073: The command "<path to repo>\vJoy\apps\vJoyFeeder\x64\Debug\CreateVersion.exe <path to repo>\vJoy\apps\vJoyFeeder\gen-versioninfo.h
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): error MSB3073: :VCEnd" exited with code 9009.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

So, I figured there's probably something that I need to build manually. I started by trying to run BuildAll.bat from the root of the repo. It failed with the following errors:

Build FAILED.

       "<path to repo>\vJoy\vjoy.sln" (default target) (1) -
       >
       "<path to repo>\vJoy\driver\sys\vJoy.vcxproj.metaproj
       " (default target) (10) ->
       "<path to repo>\vJoy\driver\sys\vJoy.vcxproj" (defaul
       t target) (14) ->
       (ClCompile target) ->
         <path to repo>\vJoy\driver\sys\vjoy.h(40): fatal er
       ror C1083: Cannot open include file: 'Ntddk.h': No such file or direct
       ory [<path to repo>\vJoy\driver\sys\vJoy.vcxproj]
         <path to repo>\vJoy\driver\sys\vjoy.h(40): fatal er
       ror C1083: Cannot open include file: 'Ntddk.h': No such file or direct
       ory [<path to repo>\vJoy\driver\sys\vJoy.vcxproj]
         <path to repo>\vJoy\driver\sys\vjoy.h(40): fatal er
       ror C1083: Cannot open include file: 'Ntddk.h': No such file or direct
       ory [<path to repo>\vJoy\driver\sys\vJoy.vcxproj]
         <path to repo>\vJoy\driver\sys\vjoy.h(40): fatal er
       ror C1083: Cannot open include file: 'Ntddk.h': No such file or direct
       ory [<path to repo>\vJoy\driver\sys\vJoy.vcxproj]


       "<path to repo>\vJoy\vjoy.sln" (default target) (1) -
       >
       "<path to repo>\vJoy\apps\common\vJoyInterface\Test-v
       XboxInterface\Test-vXboxInterface.vcxproj.metaproj" (default target) (
       11) ->
       "<path to repo>\vJoy\apps\common\vJoyInterface\Test-v
       XboxInterface\Test-vXboxInterface.vcxproj" (default target) (18) ->
         TRACKER : error TRK0005: Failed to locate: "CL.exe". The system cann
       ot find the file specified. [<path to repo>\vJoy\apps
       \common\vJoyInterface\Test-vXboxInterface\Test-vXboxInterface.vcxproj]

    0 Warning(s)
    5 Error(s)

Time Elapsed 00:00:11.29

This makes me think that it can't find the Windows driver kits on my machine. I know that I have them installed, but can't find where I would set that property with this build system -- and either way, I don't think I actually need to compile the drivers, so this shouldn't matter. Additionally, looking in some of the projects, I see local paths from what I assume is a developer's personal machine (such as C:\WinDDK\vjoy2\apps\vJoyDemo\controls). I suspect that this is part of the problem.

So, how can I actually build the feeder? After that, I would like to create my own blank project and add all the required DLLs and linker paths so that I can write my own feeder. What must I do there to make it build with the proper libraries?

Side-note: I see in some of the paths that it seems to be attempting to use v120 of the compiler. To have it compatible with VS 2015 native projects, it would need to use v140 as I understand it. Is there something that must be configured to make this happen?

WasabiFan avatar Apr 13 '16 05:04 WasabiFan

A few comments before I plunge into the issues:

  • The Xbox DLL is in its development phase. Bugs and radical changes are expected.
  • Unless you wish to make changes in the code, you don't need to compile anything - just use the latest release.
  • If you do wish to compile the DLL, you should restrict yourself to projects "Test-vXboxInterface" and "vJoyInterface" and only to "Release-Xbox" and "Debug(Xbox)."

  1. CreateVersion.exe: This utility is created in project CreateVersion.exe with every compilation and should be copied to the target. It is then ran while compiling the target and adds to it a build number.
  2. Cannot open include file: 'Ntddk.h': You need this to compile vJoy solution. It is based on the latest Windows 10 WDK
  3. I assume is a developer's personal machine: Oh, I was sure I removed it all. However, this has not been my dev directory for a long time now.
  4. So, how can I actually build the feeder?: Now you're talking. You just create a blank C++ project and link it to vJoyInterface.DLL. Either you dynamically load the DLL or you add the following line to it: #pragma comment(lib, "vJoyInterface") You should also include the header file (vXboxInterface.h) Your comments will be used to write a proper manual.
  5. v120 of the compiler: This is a good point. Let me try to explain: While the driver itself should be compiled with VS2015 native compiler (v140) the applications can be compiled with v120 (VS2013 native compiler). Code compiled with v120 requires copying of two DDL files while code compiled with v140 requires lengthy installation of VS2015 Visual C++ Redistributable pack.

shauleiz avatar Apr 13 '16 09:04 shauleiz

Thanks for such a quick response!

The Xbox DLL is in its development phase. Bugs and radical changes are expected

Yep, I'm aware of that. I am fine to work through those issues.

Unless you wish to make changes in the code, you don't need to compile anything - just use the latest release.

Ah, I think that's probably where I went wrong :wink: I tried to do that at first, but I ran into compilation errors with the header files. I don't have access to that project right now but I can try to figure that out soon.

v120 of the compiler

As far as I know, compiling the libraries with v120 means that one must compile their client app with the same version because mixing-and-matching runtime versions isn't officially supported. I have had errors caused by this problem before; I was using a DLL compiled with vs2013 in a vs2015 project, and when the DLL allocated an object on the old runtime then passed it into my code, the newer runtime would throw an error trying to deallocate it.


I'll try doing as you have instructed and see if I can get it to work. I'm happy to hear that I was over-complicating the situation and that's not how I actually have to do it! I think that my main issue was probably just getting distracted by that feeder project.

I'll close this issue once I get it running.

WasabiFan avatar Apr 13 '16 13:04 WasabiFan

compiling the libraries with v120 means that one must compile their client app with the same version because mixing-and-matching runtime versions isn't officially supported.

I am not aware of such problems. AFAIK, new applications can use legacy DLL files.

I'll try doing as you have instructed and see if I can get it to work

Please let me know of any problem. This is the time to make changes while I have very few users. Later I will have consider existing user base.

shauleiz avatar Apr 13 '16 18:04 shauleiz

It works! This is great! And I was very surprised -- after getting it to compile, it took less than 30 seconds to figure out the API and get it working. Some notes that I think you should make sure to mention in docs:

  • You need to manually include both the standard vJoy interface and the Xbox version, as well as public.h and the standard Windows.h, i.e.

    #include <Windows.h>
    #include "public.h"
    #include "vjoyinterface.h"
    #include "vXboxInterface.h"`
    
  • Once you have PlugIn()ed a controller, you must UnPlug() it before it can be used again. (I expect that this is by process, and that one process "owns" the device).

I also have some questions:

  • What's the LT in SetBtnLT? Left Trigger? If so, that doesn't seem like an appropriate name given that this function sets the stick, not the trigger.
  • The naming convention of SetAxisXfor the left stick and SetAxisRx for the right one seems a bit asymmetrical. I think it would make more sense if they were SetAxisLeftX and SetAxisRightX or something along those lines.

If there's anything that I mentioned above that I misunderstood or if there's a better way to do something, I'd be interested to find out what it is. Closing this issue now that this has been resolved.

WasabiFan avatar Apr 14 '16 03:04 WasabiFan

I'm happy it works and I am taking your comments seriously.

You need to manually include both the standard vJoy interface and the Xbox version, as well as public.h and the standard Windows.h

In the future, I would like to put everything in one header file, not including standard Windows.h of course.

Once you have PlugIn()ed a controller, you must UnPlug() it before it can be used again. (I expect that this is by process, and that one process "owns" the device).

I will try to make sure all device are automatically unplugged when DLL exits. Anyhow, I added a "Force" version to unplug that unplugs devices even if not owned.

What's the LT in SetBtnLT? Left Trigger? If so, that doesn't seem like an appropriate name given that this function sets the stick, not the trigger.

Trigger is what Microsoft calls it. It is a low-resolution (0-255) squeeze button on the "Shoulder" of the device.

The naming convention of SetAxisX for the left stick and SetAxisRx for the right one seems a bit asymmetrical. I think it would make more sense if they were SetAxisLeftX and SetAxisRightX or something along those lines.

I had the impression that the left stick is the "Main" one. Well, you can always change the names in a macro.

shauleiz avatar Apr 15 '16 07:04 shauleiz

Trigger is what Microsoft calls it. It is a low-resolution (0-255) squeeze button on the "Shoulder" of the device.

I am referring to the following lines in the header:

VJOYINTERFACE_API BOOL  __cdecl  SetBtnLT(UINT UserIndex, BOOL Press); // Left Thumb/Stick
VJOYINTERFACE_API BOOL  __cdecl  SetBtnRT(UINT UserIndex, BOOL Press); // Right Thumb/Stick

What is confusing me is that the comments say that they are the thumb sticks, while LT and RT are the names that Microsoft uses to refer to the triggers. Because they return bools, I believe that the comments are correct. Typically, Microsoft and game makers use the term "RS" and "LS" for the sticks so they aren't confused with the triggers.

WasabiFan avatar Apr 15 '16 13:04 WasabiFan

Forgive me: LT/LR are Left/Right Thumb - the press on the stick. LB/RB are left/Right Bumper - also known as shoulder. The triggers are not related.

I have based my terminology on the following two articles: DirectInput and XUSB Devices and XINPUT_GAMEPAD Structure.

I think that if the comments are correct, we can leave it at it.

shauleiz avatar Apr 15 '16 13:04 shauleiz

Hmmm... on the second page that you linked to, it says:

LSB (left stick button) Button 9 RSB (right stick button) Button 10

I think this is the "standard" terminology that they use, although generally it's just "LS", without a B.

I just wanted to make sure that you were aware that LT means "left trigger" to most gamers and users of Xbox controllers (I believe that those letters are even inscribed on the buttons themselves on the 360). As long as you are aware of that, I am fine with whatever you want to use -- just make sure that it is consistent and well-documented. The API functions work well either way, regardless of the names :wink:

WasabiFan avatar Apr 15 '16 14:04 WasabiFan

Enhancements:

  1. I would like to put everything in one header file
  2. I will try to make sure all device are automatically unplugged when DLL exits

shauleiz avatar Apr 15 '16 15:04 shauleiz

Hey guys not sure if this discussion is still alive while I am using vs2019 and still have the same problem(lack of the createversion.exe & gen-versioninfo.h) when build Vjoyfeeder/sln. Currently I am stucking at using v120 platform tools where I have no idea where to locate the configuration....

DuctedDUck avatar Dec 15 '23 07:12 DuctedDUck