-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controls use non-standard interface #46
Comments
"Due to the direct interface with the controller that bypasses the standard control mappings" Can you elaborate? All the input is read using |
Sorry, I meant to edit this one. This is perhaps a bit more complex of an issue than I gave it credit for. I don't know much about the actual code involved, I haven't looked at this core's code at all. That said, the way controls are handled now, the "Controls" interface in retroarch (and other libretro implementations) appears to be bypassed. You can turn all controllers to none and get the exact same result as if you had left retropad enabled. Individual buttons have no mappings provided to choose between. Originally I had assumed that was the root of the problem with RALibretro, but it seems on that point I may have been incorrect. RALibretro still shows memory changes on button presses, they just don't do anything. So beyond observing that, I'm at a bit of a loss there. |
I'm sorry to just pop my head in for a minute but I do know what this issue
is about. The way the buttons are mapped from this core through libretro
more or less ignores the controller paradigm that the API expects. I am
very ill and I feel irresponsible mentioning this problem without being
able to offer to help, but I'm very confident that this core is still
relatively raw and that it doesn't embrace the retropad paradigm in the API.
to say one more thing, the libreto API was originally very inflexible with
regard to it's controller abstraction. Even now, the API is still not very
well set up to create a mapping between the intellivision physical
controller and its own abstraction
…On Sat, Apr 18, 2020, 5:18 PM Sanaki ***@***.***> wrote:
Sorry, I meant to edit this one. This is perhaps a bit more complex of an
issue than I gave it credit for. I don't know much about the actual code
involved, I haven't looked at this core's code at all. That said, the way
controls are handled now, the "Controls" interface in retroarch (and other
libretro implementations) appears to be bypassed. You can turn all
controllers to none and get the exact same result as if you had left
retropad enabled. Individual buttons have no mappings provided to choose
between.
Originally I had assumed that was the root of the problem with RALibretro,
but it seems on that point I may have been incorrect. RALibretro still
shows memory changes on button presses, they just don't do anything. So
beyond observing that, I'm at a bit of a loss there.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5UBKY2S7X6IS2DI3KDRNIKJHANCNFSM4MKMRSEA>
.
|
The basic problem we're facing is that we can open the virtual pad, and navigate around that, but cannot seem to get a game to load past the title card. It's relatively simple to get past the title card in RetroArch by pressing any of the buttons on the controller. It looks like the button states are being queried through the |
This is why good documentation is important. How I could do anything different is a mystery. I start off using
On every frame:
How that "doesn't embrace the retropad paradigm" is beyond me. What could I possibly be missing?
markwkidd -- I hope you get to feeling better soon. You seem to be the only one who knows what the problem could possibly be. |
I don't know how this will come across, but I literally struggle to be able
to focus my eyes on a laptop screen. I also have, just for the last year,
major issues with my fingers not being able to press on keyboards without
dislocating. That being said I'm getting better but I hate to butt in.
Libretro is in my opinion the best thing that is happening for emulation
and -- moving forward -- multiplatform source ports. Since you first
released this emulator as a libretro core, I've been aware that it in
essence 'bypassess' the retropad abstraction. one of the challenges for the
Intellivision with libretro is that Intellivision is IMO more like a
console that uses a keyboard than one that uses a gamepad, so there will
always be a challenge adapting it to the "retropad" abstraction
@recompileorg I haven't kept a minute eye on this repository but I have
never disabled notifications so I feel like you're pretty versed in
libretro API so I don't even know if I can tell you something you're not
already aware of. I did a lot of libretro input API on the mame2003 and
mame2003-plus cores. I also did a lot of writing on the libretro docs.
I can't access https://docs.libretro.com/development/input-api/ right now
-- what about you? hopefully that's where I've recorded what I could
document.
I want to help figure this out, and unless there is a breakthrough by then
I'll set up a development environment in May so that I can try to provide a
prototype. I haven't written a line of code in almost a year, but I would
love to test the waters again
…On Sat, Apr 18, 2020 at 5:51 PM recompileorg ***@***.***> wrote:
This is why good documentation is important. How I could do anything
different is a mystery.
I start off using retro_set_input_state:
void retro_set_input_poll(retro_input_poll_t fn) { InputPoll = fn; }
void retro_set_input_state(retro_input_state_t fn) { InputState = fn; }
On every frame:
I call InputPoll once.
I call InputState once for every input on two controllers, copying the
results to an array.
InputPoll();
...
joypad0[0] = InputState(0, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_UP);
...
joypad1[0] = InputState(1, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_UP);
How that "doesn't embrace the retropad paradigm" is beyond me. What could
I possibly be missing?
The way the buttons are mapped from this core through libretro more or
less ignores the controller paradigm that the API expects.
markwkidd -- I hope you get to feeling better soon. You seem to be the
only one who knows what the problem could possibly be.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEVGC5TD7I4XG3D6YE5YPZTRNIOG7ANCNFSM4MKMRSEA>
.
--
Mark W. Kidd
http://facebook.com/markwkidd
(606)536-0115
|
Docs have had issues lately. Check the repo directly for the time being. |
Thanks Mark, I guess we'll worry about this, possibly, in May. I had thought I embraced the retropad abstraction wholeheartedly. I still don't see what I'm missing. If you mean the virtual keypad, that was my solution to making the intellivision work with the retropad abstraction. Whatever it is, technical philosophical, we'll worry about it when you're feeling better and have the time. |
Really thrilled to see all of your continued interested in this project especially recompileorg for making this a libretro core and implementing the virtual keypad. As Jamiras mentioned some of the inputs are unresponsive with RALibretro which is a retroachievements.org build for creating achievements. Typically when you load a game and see the Mattel title screen you can push the d-pad or another button to launch the game. This is where you get stuck. I have been able to get into some gameplay with another title and this gave some further insight into the control issue. For example if you run ice trek by imagic you can get into the gameplay and see that the inputs are out of whack. Pressing one of the viking's axe buttons also activates right on the d-pad, the other axe button moves down I believe. Basically It seems like multi-inputs are being registered with only a single button. You can also observe this behavior by monitoring an input byte in the RAM (0x7f8) and seeing multiple bits activated by a single input. This seemingly unusual behavior is not occuring when using the core through RetroArch. I'm happy to help test or troubleshoot in any way I can, just let me know. Thanks again guys. I hope you feel better Mark and I'm grateful that you popped your head in to help hone in on the issue even if it does, as you said, require a bit of a paradigm shift to keep this core moving forward. |
Did anyone figure out what "the direct interface with the controller that bypasses the standard control mappings" means? Also, does the problem in RALibretro still exist? If anyone knows someone on that project, I wonder if they could help figure out what we're missing. I still can't find any explanation for the behavior @Keltron3030 described. |
Things seem to be working just as well in RALibretro as RetroArch currently. I tried five games:
I believe this lines up with #39, so this issue can be closed. Previously, I could not get past the title card in most of these games. The only notable changes in RALibretro are adding support for |
Thanks @Jamiras -- I'll look at those other interfaces to see if we need to add anything, though nothing seems obvious at the moment. |
Does anyone know why I don't have the option to close this issue? |
@Sanaki, while I'm sure @markwkidd has valid points regarding the cores not aligning ideally with the retropad abstraction; the original input problems seen in RALibretro which the issue sought to convey are no longer a problem and this issue can be closed in my opinion. |
I'm using FreeIntv 1.1 on recalbox 8.1.1 and I can't make the virtual keyboard appear, even pressing L or R on the gamepad. I'm using the Playsytation 5 wireless gamepad. Can anybody help me? Games that allow you to select 1 or 2 players (Burgertime, Shark Shark, etc...) are impossible to start because I don't have access to the virtual keyboard. |
Due to the direct interface with the controller that bypasses the standard control mappings, while retroarch can handle the core acceptably (though can't really remap), other libretro implementation such as RALibretro fail to fully map the controls. Fixing this would be beneficial both for user control purposes and for allowing other libretro implementations, and via RALibretro in particular achievement support as well.
Reproduction:
Result:
The triggers will display the button overlay, but no buttons respond otherwise.
The text was updated successfully, but these errors were encountered: