input mapping discussion: phase 1

[markwkidd]

I'd like to consolidate this conversation in an open thread, with the right title, in this repository. Right now it's excitingly sparking up in several places. In addition to being able to talk about individual PRs there might need to be an Issue to capture any overall discussion about the input mapping reverts that are going on.

The first phase of the plan is to revert the input hacks that were put in mame2003 "way back in the day" that only addressed specific input scenarios.

Then we will have three input modes, each with a clean MAME slate:

• retropad which only sends input via the retropad abstraction. In other words, if you are using a keyboard and you're in RetroArch, right Shift inserts a coin. If you are using a joypad, Select inserts a coin.
• mame_keyboard which sends keyboard input directly to the MAME keyboard interface. By default a RetroPad will do nothing in this mode, although starting with RetroArch 1.7.2 you can remap a button to a key so you still might be able to make your joypad work this way. It might be very counter-intuitive and not recommended to set up your input this way though. To be tested.
• simultaneous renders input from both interfaces at the same time, which results in double-inputs when the retropad is mapped to something that also has a mame_keyboard binding. this is the way that mame2003 has worked for a long time, so it does work this way and has worked well for lots of people.

The plan is to look at current MAME for any updates that would affect the default maps in the mame_keyboard interface, as well as to look at how MAME maps to joypads for ways to improve the default mappings via retropad

I think this will be great!

Do I have the concept right? @dankcushions @grant2258 @Wilstorm

[dankcushions]

The plan is to revert the input hacks that were put in mame2003 "way back in the day" that only addressed specific input scenarios.

i had a quick look and as far as i can tell this is only 2 drivers - csp1 and 2, both of which there is a PR to revert. so i think that issue is "solved"

Then we will have three input modes, each with a clean MAME slate:

this is a separate issue for me. it's not to do with hacks or pad bindings, but rather how libretro handles a keyboard bound to a retropad. i think we should look at this separately.

The plan is to look at current MAME for any updates that would affect the default maps in the mame-keyboard interface, as well as to look at how MAME maps to joypads for ways to improve the default mappings via retropad

yes, as far as i know current (standalone) mame has a -joystick command line option, which will automatically bind a connected joystick (eg, 360 controller) to mame buttons. we should find out what those are for a 360 contoller, and how it pertains to sf2 (a great litmus test for controller bindings). once we know what they do, we can decide if it's a worth adopting.

[ghost]

indeed the problem goes away for arcade control panel users assuming we can choose to use default mapping or customize the mapping. And the old school way is still available.

ie mamebutton1=retropad a

if game == sf2 && retopie remap the buttons for this one game to work on snes pads else leave it alone and default to normal

[Wilstorm]

I like it. It allows a lot of flexibility and options for almost any scenario without completely hacking MAME apart.

[dankcushions]

i don't agree with having different layouts/overrides for sf2 and/or retropie (which you couldn't test for anyway). i think we make things sensible and universal. people don't have to update mame2003, and it's only a handful of games that would need rebinding.

plus, if we get the mapping right, then they would only need to delete their (now unnecessary) configs.

[markwkidd]

yeah the second phase seems to be to look at the MAME joypad mapping and see how that compares to our retropad mapping here

[Wilstorm]

i don't agree with having different layouts/overrides for sf2 and/or retropie

I might be missing a bigger picture but how does this affect the proposal? My controllers are completely a separate configuration and doesn't really seem to effect my keyboard mappings?

[ghost]

mames default binding should have no baring on what we map we should know what we want to map

[markwkidd]

I think we're all saying the same thing.

• Yes to separate mapping and input for joypads versus keyboards. That is what the new input_interface option is all about.
• Yes to starting fresh with the default MAME keyboard mappings for mame_keyboard input mode (that will be the new/final name for "legacy".
• Yes to looking at MAME's system for mapping to joypads to see if our default retropad mapping could be simplified/improved by looking at theirs

When the mapping is changed for the retropad interface, it need not change the mame_keyboard interface as well. That was one issue with simultaneous mode that we don't have with these two new ones.

[dankcushions]

mames default binding should have no baring on what we map we should know what we want to map

it saves us having the same conversation mame will have already had. we need to fill out this table:

mame button	sf2 move	retropad button
1	?	?
2	?	?
3	?	?
4	?	?
5	?	?
6	?	?
7	?	?
8	?	?

a sensible layout (assuming snes controller with triggers) would be

mame button	sf2 move	retropad button
?	LP	Y
?	LK	B
?	MP	X
?	MK	A
?	HP	R1
?	HK	R2
?	?	?
?	?	?

i wonder if mames's pairs up? if it doesn't, we may have issues with other games that have specific physical layouts (eg, games with cardinal directions as buttons)

[Wilstorm]

When the mapping is changed for the retropad interface, it need not change the mame_keyboard interface as well. That was one issue with simultaneous mode that we don't have with these two new ones.

I really like this flexibility. If you don't like it, flip the switch, and your input is changed to exactly what you prefer. You want Retroarch only, bang, you want MAME only, bang, you want both, bang, bang! ;)

[ghost]

@markwkidd @dankcushions

mame defaults are set at inptport.c line 190 in the mame src that is

[markwkidd]

Minor point: This makes it easier to play some arcade games with a keyboard-based arcade controller, and then switch to a joypad for other games. Maybe some people want that. :man_shrugging:

[dankcushions]

inptport.c

yes but a given joycode button does not translate to a given retropad button, so i don't see how that helps us?

[ghost]

@dankcushions you emiting the button

[ghost]

INLINE const struct JoystickInfo internal_oscode_find_joystick(unsigned oscode) { const struct JoystickInfo joyinfo; joyinfo = osd_get_joy_list(); while (joyinfo->name) { if (joyinfo->code == oscode) return joyinfo; ++joyinfo; } return 0; }

[Wilstorm]

mames default binding should have no baring on what we map we should know what we want to map

I am still kind of trying to wrap my head around everything still. If not MAME defaults what other options are available? It's a MAME core. I don't mind the Retroarch way either? Other suggestions?

If you think about it, keyboard inputs are arbitrary to a point. I've been doing a lot of work on the keyboard and using WASD and keys A and S for player 2 with player 1 (MAME defaults) works fine for testing. I think that was the whole point in the beginning, using a keyboard.

My player 4 is y/n for up/down and u/v for left right. That's a pain in the ass when on a keyboard vs a WASD layout. Try using those keys quickly and reaching for the 'right control' to fire.

Once you start building an arcade cabinet you can actually map any input to any button so what is the deciding factor on keyboard input values and does layout/grouping of keys matter even at the most basic setup you'll probably be using a keyboard so that seems to make some sense.

[ghost]

i have mentioned a few times about not using the osd functions

[ghost]

int return_os_joycode(InputCode code) { const struct JoystickInfo *joyinfo;

assert( code < code_mac );

if (code < __code_max)
{
    if (code_map[code].type == CODE_TYPE_JOYSTICK)
    {
        joyinfo = internal_code_find_joystick(code);
        if (joyinfo)
            return joyinfo->code;
    }
} else {
    if (code_map[code].type == CODE_TYPE_JOYSTICK)
    {
        return code_map[code].oscode;
    }
}
return 0;

}

[Wilstorm]

@grant2258 - Sorry good sir you could bury me in code. I am more looking at it from a higher level philosophical discussion at this point not actual implementation. I guess if you're showing a point with code only the coders really understand your point, maybe? :)

[ghost]

point is this 1 button games use button1 2 button games use buttons1 and 2 3 button games use buttons1 and 2 and 3

its just up to us how we map these buttons on a controller

edit had player instead of button

previously i just use the tab menu and set my buttons in mame everything worked right accept sf2 i changed that in input this games because of the code at the top we are thinking about reverting

[Wilstorm]

Ah, ok, that helps! ;) I map my joystick exactly like Retropad does it. I use Emulationstation A/B button swap to keep joystick "return" on A and "escape" on B. Are joysticks part of the OP? I don't fuss over the idea of joystick layout and the defaults have worked for me fairly well. My main focus is on an actual arcade stick layout with buttons but I suppose this is a chance to refine the joystick layout?

So...does anyone have a table filled in so we can see real keyboard values? I like Mark's idea it's just nailing down values. I still go off this idea if I am forced or only have a real keyboard what keys makes sense, KISS principle, maybe! :)

[markwkidd]

In MAME there is a BUTTON_1, BUTTON_2, BUTTON_3, COIN_BUTTON (paraphrasing, and so on).

MAME has, paraphrasing a keyboard input mode that says BUTTON_1 = DEFAULT_KEY_MAPPING_1.

mame2003 has a default gamepad/joypad mapping that says more or less BUTTON_1 = DEFAULT_JOYPAD_MAPPING_1

We're trying to get mame2003-plus back to the MAME 0.78 originals as a starting point.

As always you can remap to suit your on controls.

We're just looking for an intuitive baseline that is a good match for the keyboard input systems you and my brother use as well as a default joypad mapping that makes sense for the retropad users.

[ghost]

@Wilstorm does sf2 work right for you? the layout for this game is 2 x3 not sure whick row is punch and kick but it shoud work like this

0 1 2 kick 3 4 5 punches

the code we want to revert changes that layout to how it should be above look at the button number changes in the code

[markwkidd]

not to speak for arcadez but they are using these drivers in a very different way on an original xbox so I don't think he's even been affected by the code we're talking about.

so I just merged the PR

[ghost]

is the buildbot done with the updates mark?

[markwkidd]

Yes just now. RetroArch 1.7.2 is released!

[ghost]

ive been using that for a while not the stable though i just compile from source

[Wilstorm]

@markwkidd - It sounds like your brother and I have similar interests in the context of MAME. I think you have a sensible approach and great handle on the situation overall. Actually all you guys do so many different and valued points of view but I like you style to approaching challenges outlining your ideas. The first step is important. Stating the goals. We spend so much time planning and about 10% is the actual implementation here at work.

Honestly your OP allows allows almost any configuration to modified so I am more curious just to see what you come up with and can work with that. I do trust your judgement and it seems you have more of an "executive" view geared toward the good of the project as a whole on many platforms that's unbiased. Not toward a specific/personal agenda. In honesty though I do like keeping MAME's original TAB input flexibility intact.

@grant2258 - I never worked many fighter games it wasn't my thing but we did a whole lot of real life fist fighting growing up! We were a bunch of angry drunks! ;) 80% of my DNA is Great Britain and another 7% is Scotland, Ireland and Wales. Dang near 90% is overseas. You and Mark are incredible programmers and Dank brings a sh!t ton of institutional knowledge. I might not be the best person for this discussion but I am interested on how you guys decide to do it and will follow for sure.

[ghost]

@Wilstorm yes well i know where your comming from 90% scotland and a 10 year detour in south africa! I think its improtant for end users to give input like to keep us on track of what users want

[ghost]

@dankcushions I dont think its possible to get a workable framework for a joypad to work for every arcade pannel but we can get a generic one that works that sets a map on 1 ,2,3,4,5,6 ect

ie double dragon 2 in 3 button mode hits to the side you pressing and the middle jumps

if a config doesnt work as the one set its up to the end user to customise it this is the case for mame as well but to be fair i havent noticed and issues using the arcade panel but i haven't played every game either

[markwkidd]

Just something consistent that we can then remap as needed.

For instance, in NBA jam the turbo button is BUTTON_1. In that game you really want turbo to be a shoulder button. That will always need to be remapped by me per game, which is fine. As long as it's a good baseline where button 1 is usually where you want it, and only sometimes do you have to remap it from the default.

I think that is what the MAME joypad defaults should give us.. if ever we can find them

[ghost]

they are in the source mark https://github.com/libretro/mame2003-plus-libretro/blob/master/src/inptport.c

line 403

[ghost]

this is where i mentions about the seq5 possibly being the reason for the xybots buttons arent mapping in mame078 or mame 2003 they the inputport will need to be updated in the driveras is currently set for seq3 will need to do more testing. See the mame2003 xybots threads for more info i posted

[ghost]

@markwkidd we had alotta input troubles on the xbox as well, we did find alotta games which either did not have certain inputs binding to a button on the gamepad or the button layouts not lending themselfs to the game style both of which were easily sorted.

Unlike in this core however MAME84 which tends to be the xbox arcade emulator of choice was slap bang in the middle of a major upgrade and overhaul of the input system so due to this we had alotta issues with analog games being uncontolable until we actually tweaked the the analog sensitivity values for certain games at driver level.

In the end alotta people got together and pre-configed most of the games to get them controlable and we actually release the emulators with these input cfg and nvram saves included which meant that novice users could easily play the games without having to worry about setting up the inputs.

And in turn this cutdown all those "i cant get this game to work" threads down to almost zero.

[ghost]

@arcadez that is completely the way to go about on a fixed controller setup not so good when you do these changes and try use an arcade stick or any other controller that has a different setup

[ghost]

@markwkidd the joystick button setup will depend on how the os sets the controller button numbers. Just plug a controller into the windows machine and check the game controller to see how windows sets the button numbers. Im willing to bet the ps3 and xbox controller set differently

[ghost]

Sure i wasn't suggesting we actually go down that route more a case of just letting ya's know about some of the problems we had with MAME cores and inputs im sure for most platforms it's the same deal.

[ghost]

@arcadez I know you werent i was just saying you did so it the right way for a fixed controller system. That how i would be doing it if we all had xbox(one) controllers because i love the digital pad on that one

[dankcushions]

here's the current mame xbox mapping. a good start for us: https://github.com/mamedev/mame/blob/b363e92b5d14d988833242b4ce876bcdfac3cc65/src/osd/modules/input/input_uwp.cpp#L371

i'll update the table

[dankcushions]

mame button	sf2 move	xbox button	retropad equivalent
1	WP	A	B
2	MP	B	A
3	HP	X	Y
4	WK	Y	X
5	MK	LB	L1
6	HK	RB	R1
7	?	Left Stick button	?
8	?	Right Stick button	?

i can already tell this isn't going to be a great layout for sf2, but that may be acceptable if it's a sensible layout in other games. can anyone map the mame buttons to the sf2 moves, please?

[ghost]

button1 soft punch button2 medium punch button 3 hard punch

button 4 soft kick button 5 medium kick buttonn 6 hard kick

[dankcushions]

thanks - updated the table. that's actually the exact layout that mame2003 had with the hacked drivers, haha!

well, i can do a PR mapping the retropad bindings the same as the 360 in current mame, and if everything lines up we should be back where we started, but with less hacks!

[ghost]

@dankcushions thats the buttons with reverted code

[ghost]

old input for punches was 2 =soft 3= meduim 5= hard

[ghost]

@markwkidd why do i get the feeling your coding fingers are on fire?

[dankcushions]

here's the PR: https://github.com/libretro/mame2003-plus-libretro/pull/145

let me build and test it with my controllers first!

[dankcushions]

huh, getting a build error with current mame2003 plus install script.

Could not successfully build lr-mame2003-plus - Arcade emu - updated MAME 0.78 port for libretro with added game support (/home/pi/RetroPie-Setup/tmp/build/lr-mame2003-plus/mame2003-plus_libretro.so not found).

looks like the actual filename is underscores, not a dash. will look into it.

[ghost]

i posted this info for jools dank just do a ln -s newname oldname that all i done

https://github.com/RetroPie/RetroPie-Setup/issues/2374#issuecomment-383811263

[markwkidd]

twinaphex had a specific reason to change that dash recently. I was hoping somehow that RetroPie setup would not be affected but alas

On Wed, Apr 25, 2018, 5:04 PM dankcushions notifications@github.com wrote:

huh, getting a build error with current mame2003 plus install script.

Could not successfully build lr-mame2003-plus - Arcade emu - updated MAME 0.78 port for libretro with added game support (/home/pi/RetroPie-Setup/tmp/build/lr-mame2003-plus/mame2003-plus_libretro.so not found).

looks like the actual filename is underscores, not a dash. will look into it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/mame2003-plus-libretro/issues/143#issuecomment-384433403, or mute the thread https://github.com/notifications/unsubscribe-auth/ASphdquNOKoeyodI6Bv355mi7H8hZCQyks5tsOTCgaJpZM4Tjvwm .

[dankcushions]

oh...haha, i just changed the makefile to use an underscore :) i'll just get it building and then get rid of that commit from the PR.