vJoy

vJoy is a virtual joystick driver. vJoy installs a controller that the system treats as the real thing, except no physical hardware sits behind it. Games and applications see a standard joystick, complete with axes, buttons, and POV hats, but the position data is fed in by software rather than by your hand on a stick.

That distinction matters, and it trips people up constantly. This is not an emulator that translates a keyboard or mouse into joystick movements on its own. It is the empty vessel. On its own it does nothing. Something has to feed it, which is where the separate feeder application comes in, and where the real power and the real complexity both live.

Why would you want a joystick that has no joystick attached? Because once you have a virtual device the system accepts as genuine, you can pipe almost anything into it. Head trackers, DIY Arduino boards, mouse input, multiple physical controllers merged into one.

If a game only listens to joystick axes, this is how you make it listen to whatever you actually have.

What the driver actually exposes

A single vJoy installation can present multiple independent virtual devices to the system, so you are not limited to one stick. Each device carries a generous set of inputs. You get the standard axes (X, Y, and Z), the rotation axes (Rx, Ry, Rz), plus a slider and a dial, which covers throttles, rudders, and the odd extra control most setups need. Button counts run high, far more than any physical pad offers, and you can assign up to four POV hat switches per device.

Those POV hats can run in two modes. Discrete gives you fixed directional steps, the classic four or eight-way hat. Continuous reports an angle in hundredths of a degree, which matters for anything that needs smooth directional input rather than snapping to compass points.

You pick per device, and you can strip out axes you do not need so the system is not scanning dead inputs.

The three tools that ship with it

After installing vJoy, you get a small cluster of utilities, and learning what each one does saves a lot of confusion. The Configure utility is where you define each virtual device. How many axes are active, how many buttons, how many POV hats and in which mode. Apply a change and you will hear the familiar device-disconnect and device-connect sounds as the system re-registers the controller.

The Feeder is a test bench. It hands you sliders for the active axes and toggles for the buttons, so you can shove values into the virtual device by hand and confirm a game is reading them. It is not meant for actual play. It exists so you can prove the pipeline works before you wire up something more serious.

The Monitor is the diagnostic window. It shows raw input arriving in real time, axis travel and button states lighting up as data comes in. When a third-party feeder is routing data into the device and something is not landing in your game, the Monitor is where you find out whether the problem is upstream or down.

Feeders are where the work happens

On its own, vJoy just sits there. To make it useful you connect a feeder, and there is a whole ecosystem of them. Some read serial data from an Arduino. Some pull orientation from head-tracking software like OpenTrack and convert it into analog axes a flight sim can use. Others merge separate rudder pedals, a throttle, and a stick into one unified controller, which solves a problem flight sim players hit all the time when a game refuses to bind multiple devices at once.

If you write code, you can build your own. The SDK exposes the device through C and C++, C#, VB.NET, and a handful of older languages, so a mouse-to-joystick or keyboard-to-joystick bridge is a realistic weekend project.

You acquire the device, check that the axes and buttons you expect exist, then push state updates as fast as you like. Tools like PPJoy cover similar ground, but the driver here has become the default target that most modern feeders write against.

Who really uses this

Flight and space sim communities lean on it heavily. DCS World, Microsoft Flight Simulator, and Star Citizen players use it to combine a tangle of separate hardware into something a single game profile can handle, or to feed head-tracking data into a cockpit camera. Hardware tinkerers building custom button boxes or RC-style controllers rely on it as the bridge between their wiring and the games that would otherwise ignore it.

If your needs are simpler, say you just want a gamepad to act as a keyboard, this is the wrong tool and overkill besides. Something like JoyToKey or reWASD does that directly without asking you to assemble a feeder pipeline.

vJoy earns its place only when you need a genuine virtual joystick that arbitrary inputs can drive.

The rough edges

Be ready for friction. Because this is a kernel-level driver, installing it can throw a security prompt about an unverified or unsigned publisher, and you have to choose to proceed. That alone scares off a chunk of users, fairly or not.

And the learning curve is steep if you have never dealt with drivers and feeders. vJoy plus a feeder plus the right configuration is three moving parts that all have to agree, and a mistake in any one of them means a game sees nothing.

Documentation exists but assumes a fair bit of technical comfort. This is not click-and-play software, and it does not pretend to be.

Conclusion

vJoy is built for a specific kind of user. Flight and space sim enthusiasts, hardware tinkerers, and developers who need a virtual joystick that arbitrary inputs can drive. Its input ceiling is generous, its tooling is practical, and its SDK opens the door to custom bridges that no off-the-shelf remapper could match.

It asks something in return. You have to understand that the driver is half of a system, accept a security prompt during install, and put in the time to wire up a feeder that actually does the work. For casual remapping, look elsewhere. But for the people who need it, there is no cleaner way to turn anything that produces data into a controller a game will respect.