Skip to content

Configuration

Jump to bottom
Samuel Grossman edited this page Jan 1, 2025 · 1 revision

Configuration is totally optional. Xidi is designed to require minimal, if any, configuration. Defaults were carefully selected to maximize the probability of compatibility. Nevertheless, it can be configured by placing a text file named Xidi.ini into the same directory as the running form of Xidi. This file is optional; if not present, Xidi simply uses its default settings.

Xidi will display a warning message box and automatically enable logging if it detects a configuration file error on application start-up. Consult the log file that Xidi places on the desktop for the details of any errors.

An example configuration file is shown below, containing default values for all available settings. The remainder of this subsection describes each setting and what can be supplied as a value.

[Mapper]
Type                                = StandardGamepad
Type.1                              = StandardGamepad
Type.2                              = StandardGamepad
Type.3                              = StandardGamepad
Type.4                              = StandardGamepad

[Properties]
MouseSpeedScalingFactorPercent      = 100
UseBuiltInProperties                = yes
CircleToSquarePercentStickLeft      = 0
CircleToSquarePercentStickRight     = 0
ForceFeedbackEffectStrengthPercent  = 100
DeadzonePercentStickLeft            = 0
DeadzonePercentStickRight           = 0
DeadzonePercentTriggerLT            = 0
DeadzonePercentTriggerRT            = 0
SaturationPercentStickLeft          = 100
SaturationPercentStickRight         = 100
SaturationPercentTriggerLT          = 100
SaturationPercentTriggerRT          = 100

[Log]
Enabled                             = no
Level                               = 1

[Import]
dinput.dll                          = C:\Windows\system32\dinput.dll
dinput8.dll                         = C:\Windows\system32\dinput8.dll
winmm.dll                           = C:\Windows\system32\winmm.dll

[CustomMapper]
; This section does not exist by default.

[Workarounds]
; This section does not exist by default.

Mapper

This section controls the mapping scheme Xidi uses when mapping between XInput and DirectInput controller elements.

  • Type specifies the type of mapper that Xidi should for all controllers by default. Supported values are the names of any mapper, built-in or custom.
  • Type.1 specifies the type of mapper that Xidi should use for controller 1, overriding the default.
  • Type.2 specifies the type of mapper that Xidi should use for controller 2, overriding the default.
  • Type.3 specifies the type of mapper that Xidi should use for controller 3, overriding the default.
  • Type.4 specifies the type of mapper that Xidi should use for controller 4, overriding the default.

Properties

This section allows for customization and fine-tuning of various virtual controller behaviors, particularly as they pertain to input and output processing.

  • MouseSpeedScalingFactorPercent modifies the speed of the mouse cursor when a Xidi virtual controller element is configured to emulate mouse movement. Xidi has a built-in default mouse speed, and changing this setting allows that speed to be scaled up or down. The value is expressed as a desired percentage of the default speed. For example, 25 means that the mouse speed should be one-quarter of the default, and 400 means that the mouse speed should be four times the default.

  • UseBuiltInProperties allows certain built-in axis properties to be enabled or disabled. By default Xidi adds a small deadzone and saturation to all virtual controller axes via WinMM and to any analog sticks or triggers that are used to emulate mouse movement. This is done to ensure a better user experience where such properties are not normally exposed for customization. Setting this to no disables these built-in deadzone and saturation properties.

  • CircleToSquarePercentStickLeft and CircleToSquarePercentStickRight apply a mathematical transform to the raw physical readings from the left and right sticks, respectively. On some physical controllers, including Xbox controllers, these sticks can only move in a circular field of motion. This is unlike how some older controllers are constructed, including Logitech RumblePad, which provides a much more square-like field of motion for the analog sticks. Enabling these settings allows a circular field of motion for the analog sticks to emulate a square field of motion instead. The value for each of these settings is a number that must be between 0 and 100, inclusive. 0 means disabled, 100 means that a perfect circle is mapped to a perfect square, and everything in between applies the transform only partially.

  • ForceFeedbackEffectStrengthPercent acts as a global "volume control knob" that can reduce the strength of all the force-feedback vibration effects. The value is a number between 0 and 100 that represents the desired effect strength, as a percentage of what Xidi would normally send to the physical controller. This setting is applied at the very last step, meaning that it does not have any impact on force feedback calculations but rather just scales everything down.

  • DeadzonePercentStickLeft, DeadzonePercentStickRight, DeadzonePercentTriggerLT, and DeadzonePercentTriggerRT respectively allow the analog deadzone of the left stick, right stick, left trigger, and right trigger to be customized. Deadzone is expressed as percentage of the analog range of motion; values must be between 0 and 45, inclusive. If the analog position is less than this percentage away from the neutral position then Xidi reports a neutral reading to the application. It is not generally necessary to customize deadzone because DirectInput applications often use axis properties to do so, and for WinMM, Xidi internally uses its own default properties unless these are disabled. Any customization done via these configuration file settings is in addition to whatever deadzone the application already sets.

  • SaturationPercentStickLeft, SaturationPercentStickRight, SaturationPercentTriggerLT, and SaturationPercentTriggerRT respectively allow the analog saturation of the left stick, right stick, left trigger, and right trigger to be customized. Saturation is expressed as percentage of the analog range of motion; values must be between 55 and 100, inclusive. If the analog position is greater than this percentage away from the neutral position then Xidi reports an extreme reading to the application. As with deadzone, it is not generally necessary to customize saturation, and any customization done via these configuration file settings is in addition to whatever saturation the application already sets.

Log

This section controls Xidi's logging output. Logging should generally be disabled unless issues are discovered.

Any log files Xidi produces are placed on the current user's desktop and are named to specify both the executable and the specific form of Xidi that was loaded.

  • Enabled specifies whether or not Xidi should produce a log during game execution. Supported values are yes and no.

  • Level specifies the verbosity of logging. Supported values range from 1 (show only errors that will affect behavior) to 4 (show detailed debugging logs).

Import

It is not common for there to be a need to modify the settings in this section.

This section provides advanced functionality unlikely to be needed by most users. Unless there is a specific need for this feature, its use should be avoided.

The settings in this section override Xidi's default import library paths. Xidi relies on functions provided by the system-supplied version of each library it emulates (dinput.dll, dinput8.dll, or winmm.dll), so by default it loads the system-supplied version. The example above shows a hard-coded default path, but in reality Xidi determines the system path dynamically.

In some situations, it may be desirable for Xidi to use functions provided by a different library file instead. If this is the case, then values in this section should be specified. Paths can be relative to the directory containing the executable file or absolute.

  • dinput.dll specifies the path of the DLL file that Xidi should load instead of the system-supplied dinput.dll file.

  • dinput8.dll specifies the path of the DLL file that Xidi should load instead of the system-supplied dinput8.dll file.

  • winmm.dll specifies the path of the DLL file that Xidi should load instead of the system-supplied winmm.dll file.

CustomMapper

This section is used to define a custom mapper type that specifies how Xidi should translate XInput controller elements to virtual controller elements and keyboard keys. See Custom Mappers for more information.

Workarounds

It is not common for there to be a need to modify the settings in this section.

This section is used to modify the behavior of Xidi in ways that are not generally required by the DirectInput or WinMM APIs but are necessary to work around bugs in the original implementation of certain applications. Unless an application requires any of the available workarounds, the use of this section should be avoided.

  • ActiveVirtualControllerMask limits the specific Xidi virtual controllers that are made available to the application. By default, Xidi makes available as many controllers as are possible, but in some cases it is desirable to make available only a subset, either because of a specific use case or because of an application implementation issue. This setting is an integer that acts as a bit-mask, with bits in order from least-significant determining which specific virtual controllers are made available. For example, ActiveVirtualControllerMask = 0x03 limits Xidi to exposing virtual controllers 1 (based on the least-significant bit) and 2 (based on the second-least-significant bit).

  • PollReturnCode modifies the return code for a specific DirectInput API call that some applications make but Xidi does not require. By default, Xidi informs applications that invoking this API call is unnecessary, which per DirectInput documentation is considered a successful result, but some applications are hard-coded to look for a specific return code that might be different. For example, PollReturnCode = 0 would modify the return code to 0, which indicates that the operation completed successfully.

  • IgnoreEnumObjectsCallbackReturnCode causes Xidi to ignore the return code it receives from an application while it is enumerating objects (buttons, axes, and so on) that exist on a virtual controller. Normally the application has the option to terminate the enumeration early, but this workaround causes Xidi to ignore the application's request and continue enumerating until all objects have been presented to the application.

  • UseShortVirtualControllerNames causes Xidi to replace its usual virtual controller names with shorter versions. By default, virtual controller names are of the form "Xidi Virtual Controller #" but can be shortened to the form "Xidi-##" with this option enabled. Virtual controller names are often displayed in applications to identify the virtual controllers, and applications sometimes truncate the long-form names so that the player number is hidden.

Clone this wiki locally