diff options
| author | 2022-06-11 21:47:19 +1000 | |
|---|---|---|
| committer | 2022-06-11 21:47:19 +1000 | |
| commit | f47f9c3db3c7d20bea0526425cdbc469d5a10868 (patch) | |
| tree | 4dd7ac860eb10169b511521eecb31b8760011434 /docs/source/plugins | |
| parent | 5214d7f31c6e682315a7803484ade265130cfb6b (diff) | |
ui, docs: Added menus to fill a couple of gaps, improved consistency. (#9915)
Added menus for controlling toggle inputs, and showing recognised input
devices and control state. Moved input menu options off main menu to a
submenu, as there are a lot of them now.
Moved menu heading drawing into base class, added headings to more
menus, and made headings more consistent with the menu items used to
reach them. Also made terminology more consistent.
Changed the default names for buttons and hat switches/D-pads to use
1-based numbering. DirectInput still returns 0-based button numbers for
some devices.
Removed local copy of MinGW xaudio2.h as it’s now included in the MSYS2
package. Also fixed building the DirectSound sound output module with
the SDL OSD on Windows - the Windows headers are sensitive to include
order.
Started adding documentation for menus, to hopefully help people find
menus they remember seeing but can't recall how to access.
For translators, this makes terminology more consistent. In particular:
* "Settings" is preferred over "configuration" in a number of places, as
the latter can be construed as referring specifically to settings
stored in .cfg files in the cfg_directory folder. Also, references to
saving machine configuration could be interpreted as relating to the
settings on the "Machine Configuration" menu.
* The controls on host input devices (e.g. keys, buttons, joystick axes)
are referred to as "controls", while emulated inputs are referred to
as "inputs".
* The menus for assigning host controls to emulated inputs are called
"input assignments" menus to distinguish them from other input
settings menus.
* Combinations of controls that can be assigned to emulated inputs are
referred to as "combinations" rather than "sequences".
* The potentially confusing term "ROM set" has been removed altogether.
Use "short name" to refer to a device or system's identifier.
* "System" is used in almost places to refer to a complete, runnable
system rather than "Machine".
* "Driver" is now only used to refer to source files where systems or
devices are defined - it is no longer used to refer to individual
systems.
* A few more menus have message context for the messages. This makes it
a bit easier to guess where the messages are used. It also means you
can use different translations in different places if necessary (e.g.
if the same English text should be translated differently as an item
in one menu and as a heading in another).
Diffstat (limited to 'docs/source/plugins')
| -rw-r--r-- | docs/source/plugins/autofire.rst | 18 | ||||
| -rw-r--r-- | docs/source/plugins/inputmacro.rst | 14 |
2 files changed, 16 insertions, 16 deletions
diff --git a/docs/source/plugins/autofire.rst b/docs/source/plugins/autofire.rst index 56adef9b66f..3b22a9021e7 100644 --- a/docs/source/plugins/autofire.rst +++ b/docs/source/plugins/autofire.rst @@ -50,9 +50,9 @@ Button 1* or the equivalent for another player, but it might have have a different name. On Konami’s Gradius games, *P1 Button 2* is the primary fire button. -Select **Hotkey** to set the input combination you’ll use to activate the -autofire button. This can be any combination that MAME supports for activating -a digital input. +Select **Hotkey** to set the control (or combination of controls) you’ll use to +activate the autofire button. This can be any combination that MAME supports +for activating a digital input. **On frames** and **Off frames** are the number of consecutive emulated video frames that the emulated button will be held and released for, respectively. @@ -81,10 +81,10 @@ immediately. Notes and potential pitfalls ---------------------------- -Autofire buttons act as if they’re wired in parallel with MAME’s regular inputs. -This means that if you set the activation hotkey for an autofire button to a -button or key that’s also assigned to one of the emulated inputs directly, you -may get unexpected results. Using Gradius as an example: +Autofire buttons act as if they’re wired in parallel with MAME’s regular +controls. This means that if you set the activation hotkey for an autofire +button to a button or key that’s also assigned to one of the emulated inputs +directly, you may get unexpected results. Using Gradius as an example: * Suppose you set button 1 on your controller to fire, and set an autofire hotkey to button 1 as well. Holding the button down to shoot will not trigger @@ -97,8 +97,8 @@ may get unexpected results. Using Gradius as an example: powerup because the powerup button is also being held down along with the autofire button. -It is suggested you choose input combinations for autofire hotkeys that are not -assigned to any other emulated inputs in the system. +It is recommended that you choose control combinations for autofire hotkeys that +are not assigned to any other emulated inputs in the system. Autofire is not necessarily desirable in all situations. For example using autofire in Super-X with the blue “lightning” weapon equipped at high power diff --git a/docs/source/plugins/inputmacro.rst b/docs/source/plugins/inputmacro.rst index 99f8a3448fc..dd66fef205e 100644 --- a/docs/source/plugins/inputmacro.rst +++ b/docs/source/plugins/inputmacro.rst @@ -57,10 +57,10 @@ whole: press the UI Clear key to type a new name. Press the UI Select key before moving to another menu item to save the new name; press the UI Cancel key (Escape/Esc on the keyboard by default) to change discard the new name. -* Select **Activation sequence** to set the key or button combination you want - to use to activate the macro. Keep in mind that regular input settings still - apply, so you probably want to use a combination that isn’t being used for any - other emulated input in the system. +* Select **Activation combination** to set the control (or combination of + controls) you want to use to activate the macro. Keep in mind that regular + input assignments still apply, so you will probably want to use a combination + that isn’t being used for any other emulated input in the system. * Set **On release** to specify what should happen if the activation sequence is released before the macro completes. When set to *Stop immediately*, any emulated inputs activated by the macro will be released immediately, and no @@ -133,7 +133,7 @@ thing could be achieved using the :ref:`plugins-autofire`, but this demonstrates a simple looping macro: * **Name**: P1 Autofire -* **Activation sequence**: Kbd Space +* **Activation combination**: Kbd Space * **On release**: Stop immediately * **When held**: Loop to step 2 * **Step 1**: @@ -159,7 +159,7 @@ This allows you to run in Konami Track & Field by holding a single button. This takes most of the skill (and fun) out of the game: * **Name**: P1 Sprint -* **Activation sequence**: Kbd Shift +* **Activation combination**: Kbd Shift * **On release**: Stop immediately * **When held**: Loop to step 2 * **Step 1**: @@ -188,7 +188,7 @@ This macro allows you to perform a right-facing Shōryūken (Dragon Punch) by pressing a single key: * **Name**: 1P Shoryuken LP -* **Activation sequence**: Kbd M +* **Activation combination**: Kbd M * **On release**: Complete macro * **When held**: Prolong step 6 * **Step 1**: |
