As a VR enthusiast, chances are good you've had occasion to play with a few weird or non-standard controllers in your day - cyberpucks, flex sensor gloves, head trackers, whatever. In these interesting virtual travels, you may have even needed to convince a video game or some other software to accept inputs from two or more of these wacky devices simultaneously. If you were lucky, the software in question either allowed for liberal remapping entirely according to your whim or you were a principle coder on said software and could eventually make it do whatever you needed from it. If you were like the rest of us, you used PPJoy. Standing for Parallel Port Joystick, this painfully kludgey but still impressively useful bit of Windows 2000-era software was originally designed to allow enterprising hardware hackers a way to plug a crudely rewired console gamepad into a parallel port and have the resulting monstrosity function like a “real” joystick under Windows. People definitely used it for that, but presumably because some of them intended to wire in two controllers or use a “real” gamepad in conjunction, it helpfully included a feature that saw it reach a wider user base: a virtual joystick driver. Then as now, most games include gamepad/joystick support and a configuration screen to set everything up, but just about any game that isn't a flight sim will adamantly refuse to allow mixing of inputs from multiple sources. “What's that? You want to make button 3 of joystick 1 jump, and button 8 of joystick 2 duck?! What are you, crazy? NO!” the games would shout, that or stare blankly off into the distance as you mashed the forbidden button; whatever you were actually trying to accomplish, you'd inevitably shut the game down, open your Game Device properties, be thankful you weren't crazy when all your input devices worked just fine within their own control panes, and eventually either give up in disgust or discover PPJoy. Using a collection of small GUI apps included with the part that handled negotiating with parallel ports, you could (often after several harried attempts, disconnecting every other joystick from the computer, and locking them in a separate room) define a virtual joystick that would appear alongside your other “real” joysticks in Windows, and populate that definition with inputs from any other physical input device Windows could recognize. Your game could then be convinced to accept this virtual PPJoy joystick as its only gamepad-type input, and meanwhile you could use an arbitrary number of controllers within games that refused to recognize more than one. Assuming you got the damned thing working right in the first place, it was a fine piece of software (and fulfilled its original intent quite impressively, besides).
But that was then, in the bad ol' 32-bit days. Even when PPJoy worked according to your expectations, the interface was entirely unintuitive until you sussed everything out (though for a program built by a hobbyist for other hobbyists to have any kind of GUI made it somewhat remarkable), multiple tools within the package added to the confusion and accomplished things most users never needed, and a stable 1.0 release was never realized; the project has since been abandoned by its author, the vacuum thereby created being so pronounced several people have attempted to resurrect its GPL'd source, with limited success. A 64-bit version of PPJoy does exist, but requires an archaic command to place your Vista/7/8 computer into an ominously-titled “Test Mode” (this is due to Microsoft and Symantec requiring $500/year in “protection money”). In my recent efforts to demonstrate a foot pedal + gamepad control scheme concept, I again ran into the old problem of being unable to use multiple input devices under any one of the many games installed on my “new” PC. As I had several times before, I turned to PPJoy, but was in for a rude surprise – either due to the 64-bit OS or the fact that my “new” (read: released in mid-2007
) Dell XPS 720 has no serial or parallel ports (and refuses to accept a PCI card designed to add the same, due again to a lack of 64-bit drivers), PPJoy failed to do its old magic. The solutions remaining are dubious at best; even if I manage to eventually get PPJoy working, no part of this state of affairs bodes well for our nascent VR revolution, predicated as it is upon so many novel input devices working in harmony.
Something needs to be done, and while I can clearly see the problem and the solution, I'm barely proficient with Python; Windows driver programming is generally considered an arcane art best left to others even among C++/C# gurus. Encouraging current game developers to include native support for a wide and eclectic range of controllers in their future games is a quest worthy of pursuit in its own right, but even if someone succeeded in that quest beyond all expectation, this community is perhaps uniquely qualified to identify the large and ever-growing need to mix input sources in previously released software that will never see further updates. Assuming some basic knowledge of the apocrypha involved in both 64-bit Windows driver programming and joystick/gamepad drivers, this coding challenge would seem almost trivial: Define a gamepad-type device with the maximum amount of inputs allowed by Windows, allow it to accept freely-mapped inputs from any and all other input devices already recognized by the host system, and ensure that this intermediary step doesn't significantly add to the overall latency, done. The $500 fee to remove Microsoft's arbitrary roadblock would come almost instantly from a working demo on Kickstarter; I'm of the opinion stretch goals to extend Symantec's certificate to three years and even cash to set up a dedicated URL home for the project would be met with enthusiasm, and less expensive options may exist if the project was kept open-source. Even exploring PPJoy's source code and chopping out the relevant virtual joystick portion ("PPJoyJoy") could go a long way toward meeting the growing need for this product. GlovePIE is great, etc., but the world needs this void filled by dead-simple software the average piker can have running in minutes, not by roll-your-own hobbyist software even experts struggle to ever get working flawlessly. If Oculus has a “driver guy” (for all I know, it's Palmer himself), releasing a small (properly signed) driver + configuration app filling this need would be a tremendous boon to gamers, and provide immeasurable opportunities to game developers and hardware developers already toiling in the shadow of the Rift. Regardless of who does it or how it happens, the first entity to release a signed 64-bit virtual joystick will be remembered as a hero among the VR and experimental gaming communities; if it's also free, the person or people responsible may never have to buy their own drinks again. Deon van der Westhuysen, if you're out there, your software has improved the lives of countless gamers and others, and we're all eternally grateful for it, but it's time to put this pony out to pasture.
Is anyone up to the task?
TLDR: KNOW HOW TO PROGRAM DRIVERS? MAKE A VIRTUAL JOYSTICK COMBINER!
It does take a bit of fiddling around, but that process worked for me (after I tried MANY different combinations of files over several days).
