[bite_your_idols]

In the future, Kodi will support RetroArch configurations, giving you the best of both worlds.

That would be awesome!

[natethomas]

Not exactly. For example: In 2048 I press and hold start. Immediately the game is paused in-game, then after a second the OSD pops up (currently without pausing the game, but that is trivial to change). When the OSD is closed, we return to 2048 which is still on the pause screen. Start must be pressed again to resume gameplay.

The discussion here is how to improve this flawed behavior. Basically when start is pressed, we need to *not* send the press to the game and pause the game loop when the OSD is opened. The question is, how, when and for how long do we send a regular start press to the game?

Hm, interesting. My initial thought is one that's probably pretty hacky, so probably not ideal. What if exiting the OSD simply sent the pause button signal again, as long as the long pause was used to call it up in the first place? If a separate remote called up the OSD, the behavior would not happen. So yes, you do go to the pause screen in the game, but it's gone when you dismiss the OSD. The biggest disadvantage I see to doing this, off hand, is screenshots could be a real hell. But I'm not sure what other issues there might be.

[garbear]

I activated retroplayer using konami code and I can play Super Mario Bros. but I can not get into OSD, if I long press start or select button nothing happens, but if I press my PS button in my dualshock I go to home screen and the game pauses in background. ¿?

That is because PR12180 isn't merged. We need to answer the questions in the discussion above before PR12180 is ready.

PR12180 has been merged, so expect this functionality in the next milhouse build. Even though it's not perfect, it still improves things, so I'll follow up later with another PR implementing the ideas in this discussion.

[garbear]

What if exiting the OSD simply sent the pause button signal again, as long as the long pause was used to call it up in the first place?

What does a button signal look like? For GUI actions that's simple - the signal is simply an instantaneous button press. For games, this is much more complicated. The signal is a button press, followed by a button release. These must be separated by >= 1 frame. So the system needs an internal state. It must generate a button press and a button release, both different from when the button was actually pressed/released!

Right now I'm trying to design the state machine that decides when/if to fire these events. It's useful to think of several test cases:

Button is pressed for >= 1 second:

In this case, we simply launch the OSD, because Kodi actions don't need a button-up event. The game never sees a button press or release. If it requires the button to be held, we're screwed.

Button is pressed for 0.1 seconds and released:

In this case, we send a button press to the game at 0.1 seconds. When do we send the button release? After 0.016 seconds (1 frame @ 60fps)? After another 0.1 seconds?

Button is pressed for 0.5 seconds and released:

In this case, we send a button press to the game at 0.5 seconds. When do we send the button release? Also after 0.1 seconds? So the game sees the button held for a different time that the real world?

Button is pressed for 0.5 seconds, released for 0.05 seconds, then pressed for 0.5 seconds:

Uh-oh, at 0.55 seconds we encounter another button press but the button release might not have been sent yet!

---

So do you see the difficulty now? It's because the signal sent to the game looks very different (much more complicated with multiple time delays) than the signal sent to Kodi.

If a separate remote called up the OSD, the behavior would not happen.

We don't have access to which controller/device invoked the GUI action. I've thought about adding this capability, but it's easily another thousand-line patch. To give you a sense of scale:

• PR12180 (OSD) took about 50 hours and 1,200 lines, touching 50 files
  
• PR11944 (iMON conflicts) (and PR:98) from two months ago was 800 lines, touched 60 files and took far longer
  
• PR11645 (button mapping ignores certain presses) from four months ago was 1,100 lines, touched 110 files
  
• PR11571 (offset axis detection) from 5 months ago was 1,100 lines and touched 45 files
  
• PR9663 (rumble) from 10 months ago was 1,100 lines and touched 65 files
  

So at this rate, maybe in another 2 months I'll have another week to burn for this task

In all cases the input system has expanded beautifully to accompany these additions. To handle the extreme complexity of the problem (every device with every flaw controlling every emulator) I designed the system in abstract layers, with each layer of abstraction transforming the input or information slightly before handing it off to the next (or previous) layer.

The extreme effort involved comes from the fact that even for simple changes, I have to punch through so many layers. Controller input destined for gameplay travels through about 8 layers, input for Kodi actions about 7 layers, input for button mapping about 7 layers, with the bottom 3 layers common to all. Which controller originated the action is lost between the 3rd and 4th layer. Not as bad as rumble, when I had to extend 10 different layers to allow input to travel in the other direction (from the game/GUI to the controller)

[Ferk]

The problem with combos is that not all controllers have the same buttons. Genesis controllers are missing a Select key. Some controllers are missing shoulder buttons or triggers. The gamecube controller has two triggers but only 1 shoulder button, for example. This means we can't show button names in the GUI, and documentation will always need a long explanation of logical vs. physical controller mappings. etc.

You are referencing controller schemes from consoles. Isn't retroplayer using the retropad?
The retropad does have select and start buttons that can be bound to a physical gamepad or even a keyboard.

It shouldn't be a problem if Genesis, N64 or MAME have weird control schemes, at least in Retroarch, because the cores do not really read input from Genesis or N64 but from the libretro retropad. Some N64 cores even use some input hacks (like having one shoulderpad act as "meta" modifier) to simulate the N64 input with the retropad.

Maybe the problem would be more about the physical controller the user is connecting to their kodi device, if it does not have enough buttons to bind them to the retropad. In this case the "holdtime" for "Start" might have an advantage vs the button combination (as long as "Start" can be bound to the physical gamepad).
Though, imho, maybe that case is not one that retroplayer should care that much about. If a user has a physical controller that cannot fully support all the functions retroplayer can offer, users could either edit the config to match their gamepad, use an alternative (IR?) control or get a gamepad with more buttons.

In RetroArch, if select is used as a combo button, how do you send a select press to the game? If you press Select + L1, does the select press also get sent to the game?

That's a good question. I expect it doesn't send the Select+L1 buttons when they are detected, but if you don't press them exactly at the same time it probably does set either Select or L1 (whichever was pressed first) during the instant of time that one was pressed before the second one was.
I would have to test that. I think most games I've played do not really use Select much, outside of menus, so I wouldn't have noticed.

[MechanicalWhispers]

I did found a small bug: when i control kodi with the controller i don't get the navigation sounds.
When i use the keyboard to navigate the menu's i get a click.
Or is this by design?

Nope, this is a bug. I'll look into it, thanks for reporting.

Any updates on this? I haven't had GUI sounds using an XBox360 controller on Krypton (Windows 7), since updating from Jarvis. Even the recent 17.3 build is still lacking controller GUI sounds. I do get the sounds when using a keyboard for navigation. In Jarvis sounds were present all the time.

[garbear]

You are referencing controller schemes from consoles. Isn't retroplayer using the retropad?

Nope, an unbelievable amount of work went in on my part to leave the retropad behind. The retropad is hardcoded for every emulator. This leads to ugly hacks like you see in Mupen64. Worse, these hacks can be inconsistent between every core.

However, my main reason is something I'll call "technological overhead". This means that to configure the retropad, you need to understand the concept of a retropad. This is not a hard concept. Yet we take it for granted because we've been exposed to technology our whole lives.

Last year I gave a career talk to sixth graders in a poor neighborhood. When I said "I work with emulators", I got blank stares. Most had parents who couldn't afford game consoles growing up. Some had friends with an xbox or playstation. That one console could "emulate" another was not a concept these eleven-year-olds had ever been exposed to.

How do you configure an emulator without the concept of "emulation"? Much less configure, how do you even choose an emulator? The entire ecosystem of emulator software is unapproachable to a large portion of the population. And that's my goal - to hide emulation entirely, making the games accessible to people regardless of their lack of exposure to technology.

Maybe the problem would be more about the physical controller the user is connecting to their kodi device, if it does not have enough buttons to bind them to the retropad. In this case the "holdtime" for "Start" might have an advantage vs the button combination (as long as "Start" can be bound to the physical gamepad).

Yes, this is the reason I chose a holdtime instead of a combo. I haven't decided if this is the best choice yet :p

users could either edit the config to match their gamepad

Nope, the goal is zero-configuration.

use an alternative (IR?) control or get a gamepad with more buttons.

Telling the user "you're holding it wrong" doesn't solve the problem.

In RetroArch, if select is used as a combo button, how do you send a select press to the game? If you press Select + L1, does the select press also get sent to the game?

That's a good question. I expect it doesn't send the Select+L1 buttons when they are detected, but if you don't press them exactly at the same time it probably does set either Select or L1 (whichever was pressed first) during the instant of time that one was pressed before the second one was.
I would have to test that. I think most games I've played do not really use Select much, outside of menus, so I wouldn't have noticed.

Could you look into this?

[zachmorris]

Wouldn't the best choice be an option for bringing up the OSD? That would be potentially simple to incorporate in the already proposed PR.

Standard hold button method:

Code:

<FullscreenGame>
    <joystick profile="game.controller.default">
        <start holdtime="1000">OSD</start>
        <back holdtime="1000">OSD</back>
        <guide holdtime="1000">OSD</guide>
    </joystick>
</FullscreenGame>

Combo Method:

Code:

<FullscreenGame>
    <joystick profile="game.controller.default">
        <start+back holdtime="100">OSD</start>
        <guide holdtime="1000">OSD</guide>
    </joystick>
</FullscreenGame>

or

Code:

<FullscreenGame>
    <joystick profile="game.controller.default">
        <start+back+guide holdtime="20">OSD</start>
    </joystick>
</FullscreenGame>

etc..

[garbear]

Wouldn't the best choice be an option for bringing up the OSD? That would be potentially simple to incorporate in the already proposed PR.

Combo Method:

Code:

<FullscreenGame>
    <joystick profile="game.controller.default">
        <start+back holdtime="100">OSD</start>
        <guide holdtime="1000">OSD</guide>
    </joystick>
</FullscreenGame>

Combos are a good idea, but this has the same problem as above - doesn't work if controller only has a start button. This includes Genesis and N64 controllers, but I can also imagine a DIY arcade cabinet that doesn't have enough buttons to map Back and Guide.

My goal is to cater to the lowest common denominator, which ATM is the Genesis controller: A / B / C / X / Y / Z / Start / Up / Right / Down / Left. The best I can think of is holding Start. Any combinations on this controller don't generalize well to other controllers, because A/B might be switched and C and Z don't map to other buttons consistently.

However, it would be nice to also appease the power users. What about the Start/Back/Guide holding idea, to include Genesis and N64 controllers, and Select combos for controllers with a Back/Select button?

The combos could match RetroArch:

Select+Start = Exit
Select+Right Shoulder = Save
Select+Left Shoulder = Load
Select+Right = Input State Slot Increase
Select+Left = Input State Slot Decrease
Select+X/Y = OSD
Select+B/A = Reset

And maybe add:

Select+Left trigger = analog rewind
Select+Right trigger = analog fast-forward

joystick.xml could possibly look like:

Code:

<FullscreenGame>
    <joystick profile="game.controller.default">
        <start holdtime="1000">OSD</start>
        <back holdtime="1000">OSD</back>
        <guide holdtime="1000">OSD</guide>

        <start meta="select">Stop</start>
        <rightbumper meta="select">Save</rightbumper>
        <leftbumper meta="select">Load</leftbumper>
        <righttrigger meta="select">AnalogFastForward</righttrigger>
        <lefttrigger meta="select">AnalogRewind</lefttrigger>
        <right meta="select">SaveSlotIncrease</right>
        <left meta="select">SaveSlotDecrease</left>
        <x meta="select">OSD</x>
        <y meta="select">OSD</y>
        <a meta="select">Reset</a>
        <b meta="select">Reset</b>
    </joystick>
</FullscreenGame>

Using a meta button instead of allowing arbitrary combos would be a much simpler system from a coding standpoint.

[bite_your_idols]

I created a couple of addons for RetroPlayer:

RetroArch: https://github.com/bite-your-idols/game.retroarch
EmulationStation: https://github.com/bite-your-idols/game....ionstation

The first one scans addons folder for any retroplayer libretro core installed and creates a symlink to it into retroarch's cores folder. Then exits kodi and launches retroarch. It includes gamepads configs and core infos. Since kodi is stopped performance is a little better than using retroplayer (specially in low power devices such as RPi) and all settings/options are available in menus.

Since we are exiting kodi I guess there is no way to use any binary from retroplayer game engine for running games so Emulationstation addon uses retroarch passing to it core name and rom file (also this can be used by other frontends like IARL, AEL...)
I think launching a frontend over a frontend is not the best way but this is how it works also in RetroPie or Recalbox...

When I have some time I am going to make a new thread about it...

[cmiller1]

use an alternative (IR?) control or get a gamepad with more buttons.

Telling the user "you're holding it wrong" doesn't solve the problem.

Fair enough, I can understand wanting to make the software more accessible, but I've been using your builds with the IR remote(I use the silver Apple remote) plus a bluetooth gamepad (8bitdo SNES clone) and I highly recommend trying out this combo just for your own personal use. The seamlessness of using it this way was why I was initially giving such praise to the experience. So sure, keep working on new ways to access the OSD from gamepads, but seriously, give it a try just for your own use, it's really awesome!

[Ferk]

Nope, an unbelievable amount of work went in on my part to leave the retropad behind.

I see. While I can understand why the libretro team chose to introduce the retropad concept, I can understand too why you decided it wasn't a good idea.

There might also be some level of "technological overhead" when the game itself presents buttons that might have a different name in the physical gamepad than what is indicated in-game, though. So it's good to be able to go to the settings and see a graphical representation of the controllers for each system, being able to change it and have it applied to all the cores of the same system in the same way.

But what happens with the remaining 6 physical buttons when you play with a 10 button physical gamepad a Genesis game?
I can play NES games in Retroarch and yet the unused buttons can be bound in the joystick.xml to show the OSD, so I guess the default mapping takes over for buttons that are not bound in the core-specific "virtual gamepad".

It might be more important to know what physical gamepad most users will be using, rather than which ones are the "virtual gamepads" that wouldn't be able to use select. I still think this isn't really about console gamepads but about the physical ones.
I expect virtual gamepads with less buttons would be actually the easier ones to handle because there might be more spare buttons in the physical gamepad to dedicate to retroplayer actions.

Telling the user "you're holding it wrong" doesn't solve the problem.

Well, at some point the user needs to concede.He cannot expect to, for example, play a 8-button game with a 4-button gamepad, unless he's ready for some workarounds.

But I know that what you mean, as long as there's the possibility, you want to get the most compatible configuration possible. And there are also those who use retro gamepads, like the 8bitdo ones. Though I'm not sure if retro genesis gamepads are really that common.

I expect it doesn't send the Select+L1 buttons when they are detected, but if you don't press them exactly at the same time it probably does set either Select or L1 (whichever was pressed first) during the instant of time that one was pressed before the second one was.
I would have to test that. I think most games I've played do not really use Select much, outside of menus, so I wouldn't have noticed.

Could you look into this?

I don't have Retropie (the Select+L1 is from Retropie, not Retroarch), but I have verified just now that behavior in Retroarch for the "Menu Toggle Gamepad Combo" option.
The combination I'm using in Retroarch is Select+Start to open the menu, and always one of the keys gets registered, either select or start. I usually press select first and then start, probably that's why I didn't notice, though pressing Start and then Select wouldn't be too much of a problem either, just that the game would be paused.

Imho, whether it's using holdtime or button combinations, I think low latency on the game's response is important enough that I wouldn't mind the keypresses being registered in the game when performing an action in Kodi. Plus, for those who might prefer a separate control it would be very annoying to have an input delay.
There's one advantage for the button combination in this case, though. With holdtime the same key would always have to be registered, but with a button combination you can decide which button to press first to get the result you want.
So if there was a "Start+L1" combination and you want the game to pause maybe you would press first Start then L1, but if you don't want the game to pause you can decide to press first L1 in a moment where pressing L1 wouldn't matter and then Start.

[garbear]

But what happens with the remaining 6 physical buttons when you play with a 10 button physical gamepad a Genesis game?

Right now, if you're using a 16 button controller to play a Genesis game, the 6 unused physical buttons are captured by the running game with no effect. Previously, unused buttons were passed to Kodi, but this caused some people to accidentally FF/RW the game. Now the extraneous buttons are just ignored, leading to less confused users.

I can play NES games in Retroarch and yet the unused buttons can be bound in the joystick.xml to show the OSD, so I guess the default mapping takes over for buttons that are not bound in the core-specific "virtual gamepad".

I've noticed this can cause confusion, because the user isn't always aware which buttons are unused by the emulator (also, requires an understanding of "emulation"). If we want Kodi actions from within games, I think we should force a meta-button approach (like holding Select first) instead of emulator-specific behavior.

What do you think about this idea: Instead of leaving unused buttons ignored, we can double-map them to virtual features. For example, when emulating a SNES controler, both the D-pad and left analog stick can control the player. In a N64 or Genesis game, the physical Start and Back buttons would both map to the virtual Start button. In math terms, this would be called a surjective button map.

I still think this isn't really about console gamepads but about the physical ones.

I agree entirely, physical gamepads are much easier for users to conceptualize than emulated ones. I would prefer to center everything entirely around a physical gamepad in the GUI.

However, a hard design constraint that I've been working with since day one is that we don't know enough about the physical gamepad in use. We only know what the (very flawed) joystick drivers can tell us, which is basically nothing. Especially for DIY-style arcade cabinet controls, there's no way to meaningfully and concisely explain the physical setup.

It'd be nice to show a user a picture of what they're holding, maybe use the correct button names, but this just isn't technically possible ATM. If you have any clever solutions to this problem I'd like to hear them.

The combination I'm using in Retroarch is Select+Start to open the menu, and always one of the keys gets registered, either select or start.

Imho, whether it's using holdtime or button combinations, I think low latency on the game's response is important enough that I wouldn't mind the keypresses being registered in the game when performing an action in Kodi. Plus, for those who might prefer a separate control it would be very annoying to have an input delay.

You seem to be the first person here who's acknowledged that you can't have your cake and eat it too. Either you have high latency, or you have unintended button presses. This seems to be an unavoidable input truth, similar to the choice between physical and logical button mappings. This is the debate we need to be having.

With holdtime the same key would always have to be registered, but with a button combination you can decide which button to press first to get the result you want.

So if there was a "Start+L1" combination and you want the game to pause maybe you would press first Start then L1, but if you don't want the game to pause you can decide to press first L1 in a moment where pressing L1 wouldn't matter and then Start.

This is an argument for lower latency with the extra button press. By choosing which button gets the extra press, you can minimize the in-game effects without sacrificing latency.

However, the problem with this approach is that it's game-specific. Avoiding unnecessary button presses requires an understanding of the current game's input controls, and this goal changes with every game.

Because extra button presses yields an experience that changes for every game, I think our only option is to chose high latency. While undesirable, it's the only choice whose effect is independent across all games and emulators, leading to the least confusion for new users.

[OmniBlade]

When you talk of people not all that familiar with emulation and then worrying how they will struggle to map something like a genesis controller, the intersection of people that are both unfamiliar with emulators and plugged a genesis controller into their kodi box is surely going to be vanishingly small. Most people unfamiliar with emulation are probably going to plug their xbox or PS3/4 controller in and they have guide buttons that can be mapped and will behave pretty much like it does on an xbox/playstation. Anyone else can probably live with the shortcomings of button combos as I would expect them to be preferred over anything that increases input latency like waiting to decide if there was just a push or a hold.

[cmiller1]

Yeah, increased input latency is the number one game killer for me, I was actually surprised at how good it is currently.