Controls use non-standard interface

[Sanaki]

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:

1. Load core in RALibretro (core must manually be added to cores.json at this time)
2. Load any game (I tested Astrosmash)
3. Attempt to get past the title screen via any means.

Result:
The triggers will display the button overlay, but no buttons respond otherwise.

[recompileorg]

"Due to the direct interface with the controller that bypasses the standard control mappings"

Can you elaborate? All the input is read using InputState What about that isn't standard?

[Sanaki]

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.

[markwkidd]

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> .

[Jamiras]

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 retro_set_input_state callback, so I'm not sure where the disconnect is.

[recompileorg]

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.

[markwkidd]

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

[Sanaki]

Docs have had issues lately. Check the repo directly for the time being.
https://github.com/libretro/docs/blob/master/docs/development/input-api.md

[recompileorg]

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.

[Keltron3030]

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.

[recompileorg]

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.

[Jamiras]

Things seem to be working just as well in RALibretro as RetroArch currently.

I tried five games:

• Astrosmash seems to work fine, though I often manage to activate autofire and can't figure out how to turn it off.
• BurgerTime seems to work fine.
• Carnival, Donkey Kong Jr., and Frogger all get into the game, but I can't figure out how to make the characters move.

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 RETRO_ENVIRONMENT_GET_INPUT_BITMASKS, RETRO_ENVIRONMENT_GET_RUMBLE_INTERFACE, RETRO_ENVIRONMENT_SET_CORE_OPTIONS_DISPLAY, RETRO_HW_CONTEXT_OPENGL, and RETRO_DEVICE_KEYBOARD. I don't see any references to any of these in the FreeIntv codebase, so I'm not sure why they would matter.

[recompileorg]

Thanks @Jamiras -- I'll look at those other interfaces to see if we need to add anything, though nothing seems obvious at the moment.

[recompileorg]

Does anyone know why I don't have the option to close this issue?

[Keltron3030]

@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.

[madvpro]

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.