a pair of new features for retropad integration / input device selection

[markwkidd]

I have just merged two new features intended to further integrate the libretro retropad into mame2003 by making it easier to use.

1. There is a new core option that shows the MAME menu whenever the option is on. This described in a TODO: https://github.com/libretro/mame2003-plus-libretro/issues/112 . That means that users can access this menu without mapping a button to it at all.
2. There is a new core option to select primary input. The options are retropad, keyboard, and simultaneous.

When this is set to retropad, keyboard input is ignored. And vice versa.

@dankcushions I can't help but think that this latter feature would have saved a lot of configuration anguish in the retropie forums over the years.

[markwkidd]

@sapphiretactician was it you who was wondering how to get rid of 'double binding' in the MAME input remapping system? This core option solves that issue as well.

[ghost]

@markwkidd how is this going to work with arcade panels i have a 8 button setup. With the state the input system is in the only way I can use my arcade stick is to set the buttons in teh tab menu. Can we still do this or are we stuck with a bad layout now? I think its a step in the right direction though :)

[markwkidd]

This will make things the same, if not better for an arcade stick setup (my brother has one too).

For an arcade stick which functions as a keyboard, like my brother's, you might set primary_input to keyboard only and not even use the RetroPad abstraction. That will make it even cleaner to map your arcade stick via the Tab menu because there will not also be RetroPad mappings showing up.

I hope this makes sense. It's hard to write about keymapping since it's so visual/physical!

[ghost]

Well my arcade stick isint a keyboad input its joystick input ill check it out though. If im stuck with the snes pad bindings its game over for my arcade stick. Because its been changed in some drivers as well

[markwkidd]

I would like to look at the bigger picture of these mangled inputs/altered drivers in the future.

It has been discussed before and I think everyone started miscommunication and nothing was fixed/improved. So in the future I want to only bring it up once I have a good way of talking about it. Maybe with some illustrations

[ghost]

@markwkidd it does need to change it isint working the way it is. Dont get me wrong in not complaining just curios. It is something that can be refined. The way mame078 is setup normally if you map your buttons right it works for all games well 95%. if problems arise its probably because of driver input changes

[ghost]

I just finished a shift ill compile it on pie and test when i get myself out of bed.

[ghost]

@markwkidd this is my setup for the bartop i made. Please dont judge me in not the greatest when it comes to wood work.

https://drive.google.com/drive/folders/17Qp1sVEQqHYE2IX6XCXukbwWBO2PNhTq

[markwkidd]

NIICE! I have yet to build my own cabinet, just repurpose a gutted old arcade cabinet.

What encoders are you using for your controls?

[ghost]

dragonrise ( Zero Delay Arcade USB Encoder)

got my first one from aliexpress and teh second one from amazon

https://www.amazon.co.uk/gp/product/B06XDJBT43/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

the one from aliexpress was of better quality. I had to lubricate the one from amazon. Be very careful what you use on plastic though. I use ceratec

[ghost]

Ill connect a xbox or ps3 controller up to my pc. For development ive switch to retroarch. Im using 64 bit at the moment which is probably a good thing that why i found the 64 bit problem on rtype leo when irem games where mentioned. I also keep retroarch updated to the latest as well.

ps just compiled the latest version on the pie. Bad news the compile is broken again as the target name has changed. I really dont want to post another pull req though

[markwkidd]

From a different thread with @SapphireTactician -- My intention is that the display_setup core option plus the input_interface option can work together to provide two input 'modes' -- a libretro input mode based around the retropad as well as a 'legacy' input mode that uses the libretro keyboard api to give access to the mame keyboard input interface.

Or of course someone can set input_interface to simultaneous and get the double inputs that are also 'traditional' at this point.

[markwkidd]

retropad input_interface does not mean you can't use your keyboard

The RetroPad itself has keyboard mappings which are mapped for one player by default in RetroArch but which can be mapped for as many players as there are keys.

(The fact that there is a keyboard api reading input from the keys directly as well as a retropad abstraction that is reading from the keys is what has led to people seeing 'double binds' in the MAME menu historically)

This seems like a good time to post the default RetroArch player one keyboard controls. Note: No default mapping for the MAME menu (maybe just turn it on via core option!) -- just like a SNES controller. Remember, just set it to simultaneous if you want the classic behavior at any time.

RetroArch Keyboard Gameplay Controls

User 1 Keyboard	Default RetroPad Mapping	User 1 Keyboard	Default RetroPad Mapping
Up		Z
Down		X
Left		A
Right		S
Q		-	-
W		-	-
Shift		-	-
Enter		-	-

[dankcushions]

@dankcushions I can't help but think that this latter feature would have saved a lot of configuration anguish in the retropie forums over the years.

yes the solution if you do it in the core is trivial, but IMO it's a philosophical issue - the core should not be handling input preferences; that is what retroarch is for.

essentially, by default retroarch binds the keyboard as a retropad, so by default every time you press a key that is bound to a retropad button, ANY core receives both the keyboard key, and the retropad button. mame happens to be listening for both, but if retroarch is sending both, i think that's right.

you CAN handle this via retroarch - you just unbind your retropad buttons from the keyboard (set to 'nul'). i think this use case isn't particularly obvious or user friendly, but that's a retroarch issue.

the other way i thought might be sensible is for mame to ignore double inputs - always give one priority if both are pressed. i started this but wasn't motivated to finish it. might be on my fork somewhere!

so yeah, i don't agree with handling it via a core option, but it's the quickest route to results!

[markwkidd]

I don't know why you would have seen it, so I'll mention that it is totally possible to run your whole keyboard through the retropad. I've posted such a configuration here for the X-Arcade tankstick: https://forums.libretro.com/t/experimental-configuration-for-x-arcade-tankstick-dual-joystick/15283

In this scenario you put the new core option on retropad and then you map all your keyboard/x-arcade bindings through the retropad. I'm not sure that, even if you are using a keyboard, there really needs to be a keyboard interface in this core.

The input at my link above may speak better to this than I can say here. If a full x-arcade tankstick, which is seen as a keyboard, can be mapped through the retropad and used in mame2003 that way, then what use is the libretro keyboard (ie legacy) interface?

Just some preliminary thoughts.

[dankcushions]

I'm not sure that, even if you are using a keyboard, there really needs to be a keyboard interface in this core.

for people familiar with mame that are expecting the old keyboard inputs to work.

now, that might not be a great argument in a libretro core, but at least in something like retropie we would get many complaints if they suddenly needed to set up your above bindings to get the old functionality back (i guess all their existing per game cfgs would need redoing also). this is the same reason why we haven't 'fixed' the cps2 bindings - once they're there, it's difficult to justify changing them.

...so i think you're right to have the legacy mode here.

personally i'd like to be able to make the core smart enough to ignore double inputs, but still handle either if sent alone.

[markwkidd]

Something I have in the back of my mind is the upcoming RetroArch 1.7.2 update.

It may be six months or a year before that's available in RetroPie, but when it does arrive, from what I understand all existing RetroArch input remaps will no longer be valid. For lots of RetroArch users it'll be sooner than that.

It's not a bad time to be thinking about long-time input paradigm issues.

[dankcushions]

that seems like a good argument for keeping the legacy mode, then - since the input changes won't change how the api delivers keyboard inputs :) currently, you don't need any retropad inputs configured if you have a keyboard connected (other than UNconfiguring the default retropad bindings, to avoid those weird bugs)

[markwkidd]

yeah, it occurs to me I may not have stated this at any point but I don't think we need to get rid of any of these three at all. simultaneous is the only one that has no technical value IMO in its current form, except that it's what everyone knows, has built around, and loves to hate so it has to stay in some form for a long long time.

I am trying to move to a brave new world where 1) this codebase is clean, c89 compatible, and here for the next 100 years and b) where you really can fully control the emulator with a SNES (even if some individual games take more buttons)

Having the 'retropad' input option is I think a step towards making that one way to use the core. Continued feedback is welcome.

[markwkidd]

@KMFDManic I was thinking you might fight this update relevant, particularly access to the MAME menu via libretro core option.

[ghost]

Well the good thing we have here is its a new core we don't have to stick with anyone's key bindings from mame 2003 a fresh start for new ideas :). Is there a list of these libretto rules im finding this very confusing or is it interpenetration of how someone wants something done? For example if retroarch had to be forced to display 60fps how would it handle pal or anything slower and why even have a timing fps and sample option if that was the case?

[KMFDManic]

@grant2258 @markwkidd To use keyboard on NES/SNES Classic, we have to use a special Forced Host Mode, called USB-HOST. It allows an OTG Device to be connected to the Mini, and a flash drive to run all the games, etc:) But, it also allows ability to plug in a mouse and keyboard! Before we had this support, running DOSBox, BlueMSX, etc, were much trickier, due to the obvious Keyboard, lack thereof. But, I was in communication with R-Type and fr500, and both helped out. One huge change that is currently in RetroArch, thanks to fr500, is the ability to change to RetroKeyboard (For several Cores), and map the entire keyboard to the controller. It is a tremendous asset on our end!

And, of course, having MAME Options, within Core Options would be hella cool, especially if they were able to save Inputs on a game by game or core by core basis!

Anything is possible:)

[ghost]

I stumbled upon this before even realizing I was tagged for it. Works good. The only change I'd suggest is that when changing the "Tab" menu inputs via RetroPad or Simultaneous, that any input can be nulled out by simply pressing Retropad Y once the desired input is highlighted instead of having to press Retropad Y twice during binding, which would keep the behavior consistent with RA's input settings controls.

[Wilstorm]

Here, I hate double bindings...uuugh! When in the TAB menu and I press z to assign input to a command and I get "z Retropad1 B". Isn't Retropad1 B more of variable and not the value it holds?

If I assign input_player1_b_btn = "ctrl" = Retropad1 B or no? Does that mean z works and also ctrl (Retropad1 B) in MAME work too? If that makes sense?

Hard to explain but a pain.

Where do I nul "Retropad1 B"?

[ghost]

@Wilstorm You can null inputs by pressing Backspace twice (or RetroPad Y twice if using the latest build) while assigning the input. To assign just a keypress OR retropad button instead of both simultaneously, you'll need to do one of the following:

• With the latest build compiled from source, you'll need to go to Options in the Quick Menu and then change Input Interface to Legacy or Keyboard. This will let you use keyboard controls and map inputs exclusively to keyboard keys without also mapping them to the retropad.

• With the latest build compiled from source, you'll need to go to Options in the Quick Menu and then change Input Interface to Retropad. This will let you use retropad controls only and map inputs exclusively to retropad buttons without also mapping them to the keyboard.

  • You could also use a real controller to bypass the keyboard as well.

[Wilstorm]

This is the holy grail of features guys, never thought I would see this. The Retropad abstraction layer has haunted my dreams. As Freddie Mercury would say born to be kings [you're] princes of the universe, thank you! :)

[markwkidd]

LOL thank you. I feel appreciated. :guitar: :drum: :microphone: :dancer:

[markwkidd]

Breaking news: you don't have to press Del Del to unbind a map in the MAME menu. You can also do Right Right, which works with both the retropad interface and with mame_keyboard

[markwkidd]

closing this issue as input discussion has moved forward from here