Emulation/docs
1
0
Fork 0
mirror of https://github.com/libretro/docs.git synced 2024-06-23 14:52:10 -04:00
Code Issues Packages Projects Releases Wiki Activity

fixup

Browse source
This commit is contained in:
Mark W. Kidd 2021-07-12 22:26:46 -05:00
parent 0735ce5b74
commit 46d5758f30
10 changed files with 31 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/development/cores/developing-cores.md
View file

@ -2,7 +2,7 @@
### Libretro API
The Libretro API is a lightweight C-based Application Programming Interface (API) that exposes generic audio, video, and input callbacks. Developers of "cores" such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, joypads, etc.
The Libretro API is a lightweight C-based Application Programming Interface (API) that exposes generic audio, video, and input callbacks. Developers of "cores" such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, gamepads, etc.
When you choose to use the libretro API, your program gets turned into a single library file (called a ‘libretro core’). A frontend that supports the libretro API can then load that library file and run the app. The frontend’s responsibility is to provide all the implementation-specific details. The libretro core’s responsibility is solely to provide the main program.
@ -77,7 +77,7 @@ While libretro has callbacks for video, audio and input, there’s a callback ty
#### `retro_set_controller_port_device()`
By default, joypads will be assumed to be inserted into the implementation. If the engine is sensitive to which type of input device is plugged in, the frontend may call this function to set the device to be used for a certain player. The implementation should try to auto-detect this if possible.
By default, gamepads will be assumed to be inserted into the implementation. If the engine is sensitive to which type of input device is plugged in, the frontend may call this function to set the device to be used for a certain player. The implementation should try to auto-detect this if possible.
#### `retro_get_system_info()`
@ -106,7 +106,7 @@ This function lets the frontend know essential audio/video properties of the gam
After a game has been loaded successfully, retro_run() will be called repeatedly as long as the user desires. When called, the implementation will perform its inner functionality for one video frame. During this time, the implementation is free to call callbacks for video frames, audio samples, as well as polling input, and querying current input state. The requirements for the callbacks are that video callback is called exactly once, i.e. it does not have to come last. Also, input polling must be called at least once.
#### Input
Abstracting joypad and other input devices is the hardest part of defining a multi-system API as it differs across every system. The libretro API therefore provides the RetroPad -- a joypad abstraction available with digital and analog controls -- to allow cores to be written without platform-specific input code.
Abstracting gamepad and other input devices is the hardest part of defining a multi-system API as it differs across every system. The libretro API therefore provides the RetroPad -- a gamepad/joystick abstraction available with digital and analog controls -- to allow cores to be written without platform-specific input code.
Input device abstractions are also available for keyboards, mice, pointers, and lightguns.

10
docs/development/input-api.md
View file

@ -9,8 +9,8 @@ For example, native libretro cores and source ports could be written to poll the
Libretro input device abstractions include:
* RetroPad
- Digital Joypad
- Analog and Digital Joypad
- Digital Gamepad or Joystick
- Digital Gamepad or Joystick with Analog Controls
* Mouse
* Pointer
* Keyboard
@ -22,14 +22,14 @@ The [`libretro-test` core](https://github.com/libretro/libretro-samples/tree/mas
# Input Abstractions
## RetroPad
The **RetroPad** is a joypad abstraction interface defined by the Libretro API. It is the primary input device for a libretro frontend. Unless a core absolutely requires the use of a keyboard with no possible fallback for gamepad-type controls, a [[Libretro core]] should always be implemented as such that it is directly controllable by the RetroPad.
The **RetroPad** is a controller abstraction interface defined by the Libretro API. It is the primary input device for a libretro frontend. Unless a core absolutely requires the use of a keyboard with no possible fallback for gamepad-type controls, a [[Libretro core]] should always be implemented as such that it is directly controllable by the RetroPad.
![RetroPad Conceptual Diagram](../image/guides/retropad-conceptual-diagram.png)
In terms of button layout and functionality, the RetroPad is based on the original PlayStation joypad and the Super Nintendo joypad.
In terms of button layout and functionality, the RetroPad is based on the original PlayStation gamepad and the Super Nintendo gamepad.
![Mega Drive 6-Button Gamepad](../image/controller/md6.png)
Above: An example of the RetroPad joypad abstraction mapped to the Megadrive 6-Button gamepad.
Above: An example of the RetroPad gamepad abstraction mapped to the Megadrive 6-Button gamepad.
### Digital RetroPad
`RETRO_DEVICE_JOYPAD`: A RetroPad abstraction with all digital controls can be used. The conceptual arrangement for the buttons for the RetroPad is inspired by the Super Nintendo controller and the Sony Playstation DualShock.

2
docs/development/libretro-overview.md
View file

@ -9,7 +9,7 @@ There are two sides to Libretro development:
- **frontends** are programs that can run libretro-compatible cores.
- **cores** are program (such as a game, emulator, or media player) that has been ported to the libretro API so that it can be executed by libretro frontends.
Developers of cores such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, joypads, etc.
Developers of cores such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, gamepads, etc.
Cores are built as a single library file which can be executed by any frontend that supports the libretro API. The frontend's responsibility is to provide all the implementation-specific details. The core's responsibility is solely to provide the main program.

18
docs/development/retroarch/input/input-drivers.md
View file

@ -19,8 +19,8 @@ Other documentation that contextualizes this input driver specification includes
RetroArch's input system is based on abstracted input device types which are polled via callbacks provided by the libretro API. Libretro input device abstractions include:
* RetroPad
- Digital Joypad
- Analog and Digital Joypad
- Digital Gamepad or Joystick
- Digital Gamepad or Joystick with Analog
* Mouse
* Pointer
* Keyboard
@ -30,7 +30,7 @@ RetroArch's input system is based on abstracted input device types which are pol
As the libretro reference frontend, RetroArch's goal is to implement the API in a way that provides users a full experience across as wide a variety of platforms as possible. This includes the ability to map and remap physical input hardware to as many different types of libretro input device abstractions as possible, although the amount of flexibility can vary due to the limitations of specific platforms.
!!! Note
The minimum API requirement for a libretro frontend is to implement polling responses for one "RetroPad", libretro's digital joypad device abstraction. A compliant frontend could therefore support only a single input source -- for example, a frontend written for a handheld game system that has a built-in hardware controller, or a frontend that only accepts RetroPad input over a network connection.
The minimum API requirement for a libretro frontend is to implement polling responses for one "RetroPad", libretro's digital gamepad controller device abstraction. A compliant frontend could therefore support only a single input source -- for example, a frontend written for a handheld game system that has a built-in hardware controller, or a frontend that only accepts RetroPad input over a network connection.
For libretro core developers, the value of a frontend like RetroArch that fully implements these abstractions with robust remapping abilities is that cores can be coded with the 'ideal' input type abstraction in mind using simple polling logic. Meanwhile users have the freedom to map that abstraction to any number of hardware or software input sources.
@ -39,8 +39,8 @@ These tables presents RetroArch's input driver functionality organized into cate
| RetroPad Function | Supported | Notes |
| ---------------------------------------------- | --------- | --------------------------------------- |
| Map physical joypad to RetroPad (Port 0) | | |
| Map physical joypad w/analog to RetroPad | | |
| Map physical gamepad to RetroPad (Port 0) | | |
| Map physical gamepad w/analog to RetroPad | | |
| Support multiple RetroPads | | |
| Remap one RetroPad control to another | | |
| Map physical keyboard to RetroPad controls | | |
@ -52,7 +52,7 @@ These tables presents RetroArch's input driver functionality organized into cate
| Map physical keyboard to RetroKeyboard | | |
| Remap one RetroKey to another | | |
| Respect `keyboard_mapping_blocked` | | |
| Map physical joypad controls to RetroKeys | | |
| Map physical gamepad controls to RetroKeys | | |
| Map physical mouse buttons to RetroKeys | | |
| Map physical pointer taps/controls to RetroKeys | | |
@ -64,7 +64,7 @@ These tables presents RetroArch's input driver functionality organized into cate
| Remap one mouse control to another | | |
| Map physical pointer/touchpad to RetroMouse | | |
| Map physical analog controls to RetroMouse coordinates | | |
| Map physical digital joypad controls to RetroMouse buttons | | |
| Map physical digital gamepad controls to RetroMouse buttons | | |
| Map physical keyboard to RetroMouse buttons | | |
| Pointer Function | Supported | Notes |
@ -76,7 +76,7 @@ These tables presents RetroArch's input driver functionality organized into cate
| Support remapping one touchpad control to another | | |
| Map physical mouse to RetroPointer | | |
| Map physical analog controls to RetroPointer coordinates | | |
| Map physical digital joypad controls to taps/controls | | |
| Map physical digital gamepad controls to taps/controls | | |
| Map physical keyboard to taps/controls | | |
| Lightgun Function | Supported | Notes |
@ -87,7 +87,7 @@ These tables presents RetroArch's input driver functionality organized into cate
| Support multiple Lightguns | | |
| Map multiple mice to multiple Lightguns | | |
| Map multiple pointers/touchpads to multiple Lightguns | | |
| Map physical digital joypad to Lightgun controls | | |
| Map physical digital gamepad to Lightgun controls | | |
| Map physical keyboard to Lightgun controls | | |
| Sensor Function* | Supported | Notes |

4
docs/development/retroarch/netplay.md
View file

@ -9,7 +9,7 @@ supports up to 16 players and many spectators. Netplay in RetroArch is
guaranteed¹ to work with perfect synchronization given a few minor constraints:
1. The core is deterministic,
2. The only input devices the core interacts with are the joypad and analog sticks, and
2. The only input devices the core interacts with are the gamepad and analog sticks, and
3. Both the core and the loaded content are identical on host and client.
Cores are expected to support serialization for proper netplay behavior, but
@ -231,7 +231,7 @@ Payload:
frame number: uint32
is server data: 1 bit
player: 31 bits
joypad input: uint32
controller input: uint32
analog 1 input: uint32
analog 2 input: uint32
}

8
docs/guides/install-ludo.md
View file

@ -33,7 +33,7 @@ Please note that due to early development phase, Ludo _may_ not work on your OS
- Gamers can configure emulators all at once
- The user interface, configuration, and storage are consistent across emulators
From the gamer perspective, Ludo is a universal retro game browser and player. It offers a gaming experience optimized for TV and joypads, but can also be used on a traditional PC with a keyboard.
From the gamer perspective, Ludo is a universal retro game browser and player. It offers a gaming experience optimized for TV and gamepads, but can also be used on a traditional PC with a keyboard.
Currently, Ludo can run on the following platforms:
@ -48,9 +48,9 @@ There is also an Operating System version of Ludo called LudOS. It looks and beh
Ludo's User Interface has the following functionalities:
- Joypad driven: everything can be done through the joypad instead of the mouse
- Gamepad driven: everything can be done through the gamepad instead of the mouse
- TV optimized: looks nice on a wide screen
- Joypads auto configuration when plugged
- Controller auto configuration when plugged
- Automatic configuration of literally everything
- Game collection scanner for generating playlists with thumbnails
- Video filters through simple shaders
@ -109,7 +109,7 @@ Some design choices are different, for example we support less cores, and choose
### How is Ludo similar to RetroArch?
As RetroArch, Ludo is a libretro frontend, so the way of communicating with the emulators is the same.
Same cores, similar UI patterns, joypad driven UI, same game thumbnails, mostly the same game database, same terminology. I think we can also say same developers, as I am an important contributor of the libretro team, and all the people who provided me with help are also member of the libretro community.
Same cores, similar UI patterns, gamepad driven UI, same game thumbnails, mostly the same game database, same terminology. I think we can also say same developers, as I am an important contributor of the libretro team, and all the people who provided me with help are also member of the libretro community.
It definitely shares the same values.
### Why not implementing Ludo as a menu driver in RetroArch?

2
docs/guides/ozone.md
View file

@ -28,7 +28,7 @@ Only Ozone has background music, **OK**, **Cancel** and **Notice** sounds. The b
### Navigating the menu
Ozone is controlled like any other user interface. Regular input binds will apply, and binds here are defined in terms of the RetroPad, RetroArch's joypad abstraction.
Ozone is controlled like any other user interface. Regular input binds will apply, and binds here are defined in terms of the RetroPad, RetroArch's gamepad and joystick abstraction.
- **A button** (Default PC: Z&ENTER&Left mouse click): Accept/OK
- **B button** (Default PC: X&Backspace&Right mouse click): Back/Cancel

4
docs/meta/core-template.md
View file

@ -232,7 +232,7 @@ The [Core name] core supports the following device type(s) in the controls menu,
// Add [Core name] and device types
/// Possible device types
/// Joypad
/// Gamepad
/// Analog
/// Keyboard
/// Mouse
@ -259,7 +259,7 @@ Rumble only works in the [Core name] core when
- The content being ran has rumble support.
- The frontend being used has rumble support.
- The joypad device being used has rumble support.
- The controller device being used has rumble support.
## Multitap

2
docs/tech/developing-cores.md
View file

@ -2,7 +2,7 @@
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/KxJ6ZbWnAc4?start=92" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
The Libretro API is a lightweight C-based Application Programming Interface (API) that exposes generic audio, video, and input callbacks. Developers of "cores" such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, joypads, etc.
The Libretro API is a lightweight C-based Application Programming Interface (API) that exposes generic audio, video, and input callbacks. Developers of "cores" such as standalone games, game emulators, media players, and other applications don’t have to worry about writing different video drivers for Direct3D, OpenGL or worrying about catering to all possible input APIs, sound APIs, gamepads, etc.
When you choose to use the libretro API, your program gets turned into a single library file (called a ‘libretro core’). A frontend that supports the libretro API can then load that library file and run the app. The frontend’s responsibility is to provide all the implementation-specific details. The libretro core’s responsibility is solely to provide the main program.

6
mkdocs.yml
View file

@ -40,7 +40,7 @@ nav:
- 'User Guides':
- 'User Interface': 'guides/navigating.md'
- 'Input and Controls': 'guides/input-and-controls.md'
- 'Joypad Auto-Configuration': 'guides/joypad-autoconfiguration.md'
- 'Controller Auto-Configuration': 'guides/controller-autoconfiguration.md'
- 'Installing Cores': 'guides/download-cores.md'
- 'Directory Configuration': 'guides/change-directories.md'
- 'File Browser': 'guides/file-browser.md'
@ -71,7 +71,7 @@ nav:
- 'Advanced':
- 'AI Service': 'guides/ai-service.md'
- 'Command-Line Interface (CLI)': 'guides/cli-intro.md'
- 'Input and Joypad Drivers': 'guides/input-joypad-drivers.md'
- 'Input and Controller Drivers': 'guides/input-controller-drivers.md'
- 'Linux KMS Mode': 'guides/kms-mode.md'
- 'Optimal Vsync Performance': 'guides/optimal-vsync.md'
- 'Run Ahead': 'guides/runahead.md'
@ -295,7 +295,7 @@ nav:
- 'Input':
- 'Input Driver Specification': 'development/retroarch/input/input-drivers.md'
- 'Input Overlays': 'development/retroarch/input/overlay.md'
- 'Parallel Port Joypads': 'development/retroarch/input/parallel-port-joypads.md'
- 'Parallel Port Controllers': 'development/retroarch/input/parallel-port-controllers.md'
- 'Adding Translations(not active)': 'development/retroarch/new-translations.md'
- 'Adding Translations with Crowdin': 'development/retroarch/new-translations-crowdin.md'
- 'Network Protocols':