ui: Support changing controller/keyboard mappings #1516
Conversation
|
Hello! Good job! Will there be mouse support? |
Mouse support is out of scope for this PR |
antangelo
force-pushed
the
ui/rebinding
branch
from
bd67afa
to
a33bec2
Compare
ui/xemu-controllers.cc
Outdated
| const char *base_path = get_binding_path(); | ||
|
|
||
| assert(strlen(guid) > 0); | ||
| char *binding_path = g_strdup_printf("%s/%s.toml", base_path, guid); |
There was a problem hiding this comment.
I assume storing non-keyboard mappings in separate files was done to work around genconfig limitations. From a user perspective, it seems weird to have them in separate spots. Should we try to move these input mappings into xemu.toml or do you think it's better to have them separated like this
There was a problem hiding this comment.
I didn't want to overly clutter xemu.toml, as there are many entries for the various mappings and if a user has multiple controllers then the file can fill up quickly (especially with the addition of more devices later on, or if we support setting mappings per title).
There were genconfig limitations either way (which I resolved separately to allow for multiple configs in the same program), but those required to support maps with string keys would be more involved as well.
There was a problem hiding this comment.
I expect most people have at most a handful of devices they intend to use, so I don't think storing button mappings in xemu.toml would add much clutter in the typical case. Would you consider looking into migrating device input mapping into the main config?
There was a problem hiding this comment.
I have a solution that stores the bindings in an array in the main config. It depends on mborgerson/genconfig#10
I also looked into adding support for tables with arbitrary string keys to genconfig but there's some added complexity there with serialization and efficiently adding nodes to the map without invalidating pointers to the previous nodes within the serialized struct. I don't personally think this complexity is worthwhile if there won't usually be many controllers in the array, as you say, but can finish this approach if you think it's better.
antangelo
force-pushed
the
ui/rebinding
branch
2 times, most recently
from
2df6c52
to
d9a01b2
Compare
|
Can we also have an option to switch the controller image to Controller S? |
antangelo
force-pushed
the
ui/rebinding
branch
from
d9a01b2
to
2a055d3
Compare
antangelo
force-pushed
the
ui/rebinding
branch
from
2a055d3
to
35244d8
Compare
|
It is planned to add mapping profiles? That way they can be assigned per-game. |
Adds a configuration scheme and UI for remapping keyboard/gamepad inputs to the emulated controller. I tried to keep it as modular as possible so that #1478 can extend this system with other devices and the other devices can be mapped independently.
Resolves #136 and supersedes #1301
Leaving in draft initially as this requires some genconfig PRs to be merged-- the genconfig submodule is currently pointed to my fork. I've formatted the PR using clang-format, which is why it differs at points from neighboring code. I am leaving it as-is because formatting code I haven't touched will make this already large change harder to review, but can do so if needed.