Completely rework the input subsystem #235
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a big one. Rework the input interface to have the concept of separate input devices instead of treating all input devices like extensions of a giant keyboard. A single input device is now assigned to each player. The rewrite of the SDL input code also adds support for the SDL game controller (XInput) interface, so XInput-compatible controllers can have sane default mappings. There are some things incomplete (saving/loading control mappings, reassigning devices to players) but games are playable. This change will break consoles until their input code is rewritten. It probably also breaks Android, but hopefully it will not be too hard to fix since Android-specific code has been taken from the original control.c.
Control mappings are now saved to a separate file from the main save data.
When changing the input config for a button, it would pick up the newly configured button as a "newly pressed button" on the next update, so it would go right back into waiting for a button press again.
Now the only way to cancel out of input config when it's waiting for a key/button press is for another player to press "cancel".
It compiles and runs now, but control config doesn't pick up on-screen button presses yet.
This isn't super useful since on-screen buttons are actually mapped directly to directions, Jump, Special, Attack 1, etc. But it's better than having to cancel out of control config with the Esc button.
SDL uses the joystick interface to expose the functionality of the accelerometer on Android devices. Since the accelerometer is not actually a joystick/controller, blacklist it from being counted as an input device.
The implementation is buggy and incomplete, but it at least compiles and runs okay.
DCurrent
approved these changes
Jul 19, 2021
|
Impressive update :) For my part we are patching OB to make the INI readable by a human, to make it easier to integrate in a system, to use OB like any other emulator or game engine ... Do you think it can be possible to add it officially too ? |
|
I did a quick test, the automatic controller detection is fantastic. But it seems that some buttons are not working and others are inverted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is it: the big input rework. The platform-specific control code for SDL and Wii has been completely rewritten. Input devices are now assigned to individual players, controller hotplugging is handled gracefully, and it is easy to reassign which player uses which device. This should fix most of the control issues people have traditionally had with OpenBOR. The days of OpenBOR treating all input devices like pieces of a giant imaginary keyboard are over!
The new input subsystem works very well on Windows/Linux. I haven't been able to test controller support on Android, but these changes at least don't break the regular touch-based input system. The Wii implementation is in worse shape; it is still incomplete and buggy, and will need someone to improve it in the future.