Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP
This PR adds mouse and keyboard controls for aplicable Libretro cores.
As simple as it may sound, the main idea is to capture browser Keyboard and Mouse API events and then feed them in a digestible form to the Libretro frontend. Unfortunately, there are several problems related to the original design choices of cloud-game.
Initially, it was assumed that each player would have just one controller device occupying a single controller port in terms of the underlying Libretro API. This way, it would be pretty easy to distinguish controller events of each player, knowing that you can safely forward player control events to their dedicated port without the fear of interfering with other players. However, that was quite a wrong assumption, thinking that one player occupies just one device port. In reality, many cores allow the use of several different controller devices, in theory mapped to an unlimited number of ports (in practice, only up to 9 ports can be used), or even multiplex multiple devices (merge controller events) on a single port, as in the case of the DOSBox Pure core.
Keyboard in Libretro
To use a keyboard with Libretro, two callback functions from the core are required:
Keyboard Callback Function:
RETRO_ENVIRONMENT_SET_KEYBOARD_CALLBACK
bool down
: Indicates if the key is pressed.unsigned keycode
: Internal Libretro representation of the pressed key.uint32_t character
: Ignored.uint16_t key_modifiers
: Special key modifiers such as shift, alt, ctrl, meta, num/caps/scroll-locks.Device Callback Function:
RETRO_DEVICE_KEYBOARD
core_input_state
polling function.Mouse in Libretro
Mouse controls in Libretro are polled similarly to the keyboard, using the
core_input_state
function with the device nameRETRO_DEVICE_MOUSE
. The behavior of the callback depends on theid
parameter:Button States:
id
parameter corresponds to a mouse button, the callback returns the state of that button (pressed or released).Cursor Position:
id
parameter corresponds to the cursor position, the callback returns the position of the mouse cursor.Scale cursor speed to native resolution
Since raw pointer movement is not supported in all browsers or platforms, when you stream a display which size is different from a display on which you use mouse, the mouse movement (DPI) should be approximated accordingly.
Used algorithm takes coordinates (movement delta) from the virtual display (cursor over the browser video element) and scales them to the default DosBox VGA display size of 640x480.
Because the scale ratio value is a floating point number and we can't use subpixel coordinates on the server side, we need to take into account accumulated floating point errors when rounding coordinates to the destination screen (Libretro framebuffer). See an example.