Closed pjft closed 6 years ago
pjft
commented
6 years ago Actually, after searching through the code history, it seems the files I was looking to change actually seem to have already been customized on the lr-fuse side of things, so I take it that my changes would only need to be on the lr-fuse side of things.
Please let me know if there's any fundamental disagreement from your part, or misunderstanding on my end.
Thank you!
leiradel
commented
6 years ago Hi @pjft
a) would this have a chance to be accepted as a PR here, if it works as intended?
Absolutely. It will be a great addition to the core.
b) is this the right repository for such PR, or should I submit a PR to the main Fuse repository for changes to the actual Fuse code, and then a separate one here for the changes for the Libretro fork?
This change will only change some libretro specific files, so the PR belongs here.
The changes would be - as far as I can tell so far - limited to a handful of files, but some would be part of the main Fuse code.
All the necessary changes can and should be done only in libretro specific code. Changes made on files in the build, bzip2, etc, fuse, libspectrum, and zlib folders will likely be lost when the Fuse version is upgraded.
I'm not quite sure what the best route forward here would be, so before I invest a lot of time in it I just wanted to make sure I checked here.
Take a look at the 81-libretro, it already implements this functionality. If you look into src/libretro.cpp, in the core_vars array, options to map all RetroPad buttons except L3 and R3 are there. The implementation for the Fuse core should be an almost direct copy of that.
These options end up in the zx81ovl.joymap array, which is then handled used in src/keybovl.c, inside the update function.
I'm not even sure if the Libretro fork is up to date with 1.5.0
It's not. The core was done as a wrapper around Fuse, using it as if it was a library. The next update will attempt to be a proper port and merged in the upstream repository.
or if the main Fuse project is still being developed, so let me know.
It is.
Actually, after searching through the code history, it seems the files I was looking to change actually seem to have already been customized on the lr-fuse side of things, so I take it that my changes would only need to be on the lr-fuse side of things.
Ah, I should've read the entire comments first :) As you already know, yes, you are correct.
Thanks for willing to improve the ZX Spectrum libretro core!
pjft
commented
6 years ago Thank you @leiradel for your thorough reply, and especially for sending me some very relevant pointers.
After some initial exploration I was able to create a new input type and make the joypad easily emulate some pre-defined keys, but when it came to allowing them to be redefined on RetroArch I ran into the issue that every LR input event needs to be mapped to one LR input button, so I couldn't easily set up the keyboard configuration in the Controls section. I remembered that lr-fbalpha did something for macros on some games, and after checking they implemented it in the Core Options rather than in the controls section - which seems to be exactly what 81-libretro does after inspecting their code!
Thank you for pointing me in that direction as it's great to have a running example of someone who attempted a similar effort for the ZX Spectrum!
I'll let you know how it goes as well as if I run into some decisions I don't have enough context on my own to make the best call on according to the project's roadmap and prior decisions.
Have a fantastic week ahead!
leiradel
commented
6 years ago Thank you @leiradel for your thorough reply, and especially for sending me some very relevant pointers.
No problem, it's the least I can do.
After some initial exploration I was able to create a new input type and make the joypad easily emulate some pre-defined keys
You mean a new input device like RETRO_DEVICE_CURSOR_JOYSTICK, using the RETRO_ENVIRONMENT_SET_CONTROLLER_INFO environment callback? No, these devices must be actual hardware devices that the core can emulate. You should map the buttons to keys using core options, just like in 81-libretro.
... and after checking they implemented it in the Core Options rather than in the controls section - which seems to be exactly what 81-libretro does after inspecting their code!
Exactly!
Have a fantastic week ahead!
You too, feel free to ping with any doubt you may have.
Hi team,
Apologies if this is the wrong place to ask for this. I was planning on trying to implement (or fail miserably) a joystick-to-keyboard remapping input for lr-fuse, as several games need more than just the standard joystick inputs to be correctly played, and constantly calling the keyboard overlay isn't really practical. I'm looking to implement a way to assign the RetroPad buttons to individual keys and that's what I'll be attempting to pursue.
My main questions are: a) would this have a chance to be accepted as a PR here, if it works as intended? b) is this the right repository for such PR, or should I submit a PR to the main Fuse repository for changes to the actual Fuse code, and then a separate one here for the changes for the Libretro fork? The changes would be - as far as I can tell so far - limited to a handful of files, but some would be part of the main Fuse code.
I'm not quite sure what the best route forward here would be, so before I invest a lot of time in it I just wanted to make sure I checked here. I'm not even sure if the Libretro fork is up to date with 1.5.0, or if the main Fuse project is still being developed, so let me know. Also, the other one seems to be hosted on SourceForge.
Thanks.