x360ce: using a wheel, joystick or PS-style pad as an Xbox 360 controller on Windows

The gap x360ce fills: DirectInput hardware, XInput games

Windows games built around XInput expect an Xbox 360 controller and nothing else. A Logitech wheel, a flight stick or a generic gamepad speaks DirectInput, so the game either ignores it or misreads its axes. x360ce sits between the two: the README describes it as software that lets your controller (gamepad, joystick, wheel) function as an Xbox 360 controller, and gives playing Grand Theft Auto or Mafia II with a Logitech Wheel as the example. The audience is narrow and specific. It is someone on Windows 10 or newer with a working but unrecognised input device and a game that refuses to see it. It is not a general input remapper, and it does nothing for a controller the game already reads correctly. The README is blunt about scope in the other direction too: the issue tracker is for crashes and bugs, and installation or configuration questions are redirected to the NGemu forum. That tells you the maintainers treat this as a tool with a support community rather than a help desk.

Two mechanisms: a virtual gamepad bus in v4, a DLL in v3

Version 4.x uses Virtual Gamepad Emulation, per the README, and the release notes name the component as the Virtual Gamepad Emulation Bus, version 1.21.442.0 on Windows 10 and later or 1.16.112.0 on older Windows. That is a different shape from the v3 line, which ships x360ce_x86.zip for 32-bit games and x360ce_x64.zip for 64-bit games and works by placing a DLL where the game loads it. The v3 README notes the DInput.dll plugin is built from Native/dinput8 and embedded in x360ce.exe, and is no longer kept as a committed binary, so there is no separate plugin file to fetch. The practical consequence is that v3 requires you to match the game's bitness, and the README warns that most game executables are 32-bit and therefore need the x86 build plus the x86 redistributable. v4 sidesteps the bitness question by emulating a bus instead of injecting a library. The repository layout reflects the split: App.v3 and App.v4 sit side by side, with Engine, Native, Data, Resources and Tests alongside them. The program also documents itself. docs/ui-tree.md is described as every control with its purpose, written by the program and regenerable with x360ce.exe /ExportUi=docs, and docs/Help.v4.md is the help the program shows. That is unusual and useful: the UI tree is generated output, not hand-written documentation that drifts.

Installing x360ce and getting one game working

The README points to the Releases page and insists on digitally signed files only, with an explicit warning not to disable antivirus or exclude the app if someone tells you to. Download x360ce.zip from the latest v4 release, which at the time of writing is the 4.22.0.0 release carrying application 4.22.21.0.

# from the latest v4 release assets
# download x360ce.zip, verify the digital signature, then extract

Before running it, check the system requirements the README lists: Windows 10 or newer, .NET Framework 4.x (already present on Windows 10 and 11), the DirectX End-User Runtime from June 2010, which the README says is required regardless of OS, and the Visual C++ Redistributable 2015-2022. On a 64-bit system the README says to install both the x86 and x64 redistributables.

# run the extracted application
x360ce.exe

With the program open, map your device to the Xbox 360 pad on the controller page, then start the game. If the game reads only the first controller, the XInput Devices page can move a controller to a different place; the README notes that switching a real controller off and on again needs Administrator, so the program starts one elevated copy for that step and closes it, and anything it switches off is recorded first so an interrupted run is undone at the next start. For a wheel or pedal, the mapping row itself can hold a formula. Press the small fx button beside the row and type one starting with =.

=a5*2        # double the trigger, full at a half press
=a1*0.5      # halve the stick, for aiming through a scope
=a1*abs(a1)  # fine control near the centre, full speed at the edge
=max(a1,0)   # use only one half of a pedal axis

Sources are written the way mappings are stored: a1 is axis 1, b2 is button 2, s1 is slider 1. An axis reads from -1 to 1 when it drives a stick and 0 to 1 when it drives a trigger. The fx button turns green while the formula is understood and driving the row, and red while it is written down and not; pointing at a red one shows what is wrong. The formula takes effect as it is typed.

The 16-character formula limit and other real constraints

The formula feature is the most interesting thing in v4 and also the most obviously unfinished. A formula is limited to 16 characters, which the README explains is the width a mapping is stored in, and it says the limit is raised in a later release. Sixteen characters covers the four examples above and nothing more. You cannot write a dead zone or a full response curve in that space, and the README says so directly. Worse for tuning, a formula replaces the dead zone, anti dead zone and sensitivity for its row rather than being applied on top of them, so you are choosing between the sliders and the formula, not combining them. The operators, functions and sources are listed on the Help page rather than in the README, so the expression language is only fully documented inside the running program. The other constraint is Denuvo. The README states in bold that Denuvo protected games are not supported, and links to the Wikipedia list of such titles. If your library is mostly recent AAA releases with Denuvo, x360ce is the wrong tool and no amount of configuration changes that. Settings storage has a social constraint as well: settings live in C:\ProgramData\X360CE\Settings, and the README says anyone may create a file there but only the account that created it may change it afterwards, so on a shared computer a second user can find the settings read-only. Options then Settings shows the folder in use and lets you choose another, and the per-user folder %LOCALAPPDATA%\Jocys.com\X360 Controller Emulator cannot be locked by another account. Moving settings copies every file and checks it against the original, removing nothing unless all of them match.

Force feedback pass through, and why it exists

Rumble is the part of this problem that people underestimate. An Xbox controller offers its motors through XInput and nowhere else, so a game's rumble cannot be sent back to it the way it is sent to other controllers. Force Feedback Pass Through, on the Force Feedback tab, hands the rumble to a real controller instead. The destination defaults to Auto (Real), meaning the real controller behind the mapping, and can be pinned to XInput 1 through 4. The Test sliders on that tab drive the same path a game does, pass through included, so the destination can be checked without launching anything. That last detail is the useful one: it turns a feature that is normally verified by feel inside a game into something you can confirm in the UI. The README does not document what happens when the chosen XInput slot is empty or the destination device is disconnected mid-session, so that is worth testing yourself before relying on it.

Alternatives, and where x360ce stops being the answer

The closest alternative in the same problem space is Steam Input, which remaps controllers at the platform layer. The difference in approach matters: Steam Input works for games launched through Steam and configures the mapping in Steam's own UI, while x360ce runs as a Windows application and presents a virtual Xbox 360 pad to whatever the game sees, including games bought outside Steam. If your entire library is on Steam, Steam Input asks less of you and needs no extra process. If your problem is a retail disc, a GOG install or an old executable, x360ce is the one that applies. The second boundary is platform. The related searches include x360ce for Android, and nothing in the README supports that: the system requirements begin at Windows 10, the v3 line is explicitly x86 and x64 Windows DLLs, and v4 depends on a Windows virtual gamepad bus. Treat any Android build you encounter as unrelated to this repository. The third boundary is the game itself. The README links a wiki Compatibility List and a Reporting Compatibility page, which is the honest signal that coverage is per-title and community-maintained rather than universal.

Maintenance, licence and what upgrading costs you

The repository is not archived and the last push was on 2026-09-23, one day before this was written, so this is a project with current activity. The release cadence is quick: 4.20.0.0 on 2026-09-01, 4.21.0.0 on 2026-09-13, and 4.22.0.0 on 2026-09-17. That cadence cuts both ways. You get fixes and the promised formula-limit increase, but you also get a moving target, and the README's own note that the limit is raised in a later release is a reason not to build careful mappings around the current 16-character cap if you can wait. The upgrade path itself is not documented in the README: there is no stated procedure for moving from v3 to v4, and no documented rollback if a new build misbehaves, so keep the previous signed archive rather than overwriting it. The licence is a genuine unknown here. The repository metadata carries no licence identifier and the README does not state one, so if you are considering redistributing x360ce or bundling it with a game, confirm the terms from the repository itself before doing so. The README does state that every signed build is published on the Releases page, and it asks users to report suspected false positives to the issue tracker so the maintainers can work with antivirus vendors. That is a maintenance commitment of a kind, but it is not a licence grant.

Editorial conclusion

Adopt x360ce if you are on Windows 10 or newer with a DirectInput wheel, joystick or third-party pad and a game that only reads XInput, and start with the signed x360ce.zip from the latest v4 release. Do not adopt it for a Denuvo-protected game, which the README states is unsupported, and do not expect it to help on Android or any non-Windows platform, since the whole mechanism is Windows input APIs. Before you commit, verify three things yourself: that the game appears on the wiki Compatibility List, that you can live with the 16-character formula limit if you plan to write curves, and that the settings folder under C:\ProgramData\X360CE\Settings is writable by the account that will use it, because only the account that created a settings file may change it afterwards.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. x360ce/x360ce on GitHub