Retropad Y and A are reversed (hardcoded)

[nikkoman]

It appears that retropad Y and A are reversed on lr-mame2003. This is evident for titles that use X/B/Y/A as up/down/left/right (such as sheriff.zip) and can be verified via the MAME menu (tab key) where they're swapped when entered.

There are workarounds for this but it should be fixed since it's erroneous... unless I'm not getting something and it should be that way.

I also posted this to the RetroPie forums but I feel that I need to report here. I am using lr-mame2003 a4f22ed on the latest builds available as of today on a Raspberry Pi 3B+.

[dankcushions]

it’s difficult. if you fix this globally it would mess up capcom fighting game layouts, which are already different to FBA’s layouts, etc. i wonder how standalone mame current maps to sticks/gamepads by default?

[ghost]

changing the sf2 at source level isint ideal the solution I have a cleaner on for you to consider put the source back to what it was. The do a setup controller setup in mame for the street fighter games that matches the retropad buttonsyou want. Include the remap file in metadata and copy it on install. It has the same effect without messing with other people trying to remap the buttons in mame on arcade sticks ect. I know how to fix this up myself its just an idea maybe a bad one im not sure I suppose it depends on your perspective.

[dankcushions]

nah i don’t like including remap files with source - libretro emulators aren’t neccesarily for use with retroarch front end and config structure.

i think the approach may be to take out all the input edits from the drivers (cps2 has some for example) and see if there’s not a sensible default. FBA uses

Y X R1 B A R2

for CPS2, which makes sense in a modern context ... i wonder how that translates globally if the drivers are all back to stock

[ghost]

well i know on thing when i set the my default buttons up on stock mame078 for my arcade joysticks i have no issues. It messed every other game up when you set you setup your controls as default for sf2 as a default config with the changes we have now. It seems to me the changes should be implemented into sf2 rather games setting everything up around them games.

[nikkoman]

I understand what's going on. But in my humble opinion a handful of games, albeit popular, shouldn't set the standard for countless others. CPS games are still playable with a different layout but many MAME games rely on the ABXY cross type physical placement.

[dankcushions]

I wasn't saying the current situation is right!

if you check the commits the controls were edited at the driver level for CPS2, and then after that the global retropad mapping was edited. we would get into a deeper mess if we change the global retropad mapping again. the whole thing needs to be reverted back to the mame defaults in all drivers, and remapped to the retropad in a sensible way.

this would be fiddly work, and presumes that mame 0.78 had a default button layout that presumed a specific controller/button layout. i'm not sure it did.

[ghost]

I would echo the last comments from @nikkoman, i do feel with any MAME port it's important not to stray too far from the original path only altering code if and when you have to so it will function correctly for the target platform or platforms.

There have been alot of input changes for this core over and above the MAME78 defaults i do suspect not all of these changes were needed and some of them might be responsible for the problems with the Bally / Midway MCR games not coining or locking into service mode on boot.

Ofcourse there is a high probability im totally wrong about this and the problems with the aforementioned games are caused by something else, it's something i plan to look at down the road.

[ghost]

i dont think you are I just done a quick test and copied mames original inptport.c and inptport.c to see if rampage woudl stop resetting and it did i just displayed a pallet screen. no resetting ect

[ghost]

That still sounds like it's stuck in service mode eg the colour test screen, so you used input.c / h and inptport.c / h from MAME78..??

[ghost]

No just used inptport.c and the header I doubt it will compile the libreto stuff if u messed with the Input.h

[ghost]

Yeah i know what you mean as input.c is tied in with the libretro side of the core, the trick would be for testing purposes to rollback to an older version of mame2003 from a time before alot of input changes were done.

like 6th july 2016 for example.........

https://github.com/arcadez/mame2003-plus-libretro/tree/7da127055ce603d5c1bba81127a994ae6c8ee9e7

Then we can rule in or out the input changes that came after this date with regards to causing the MCR game breakage.

[ghost]

Might take a while for me to get to but im going to look into how the inputports are hooked up to the core. I get the feeling custom input ports are not implemented could be wrong though

[markwkidd]

@nikkoman we now have a fix in place for this in mame2003-plus. could you give that a try?

[dankcushions]

still a valid issue in 2003, again.

[markwkidd]

Can you submit a PR? I'm helping maintain this repo and keeping it fresh, but I don't feel like I have a strong say in its mission statement. For myself though I think it would be fine to bring over any and all of this from the other core.

[dankcushions]

i don't plan on working on it but there is zero point closing valid issues even if they don't look like being fixed. that is bad stewardship

[markwkidd]

I was closing it more as a WONTFIX but I should have been clearer. That is what I meant about the "mission" of the core. There are longstanding issues I'm leaving open because they are clearly bugs. This is fixed in mame2003-plus so it's easy to bring over.

There are areas, particularly around input, which I have left alone in this core because of the concern expressed many times that mame2003 has a large userbase with settings already built around its quirks -- that it would be to much chaos if an update changed their rig unexpectedly.

Do you feel that this issue is in fact enough of a bug that it would not be an undue inconvenience to the current userbase to make a change? If so I'll definitely leave it open and probably at some point it wouldn't take long to port the mappings from mame2003-plus back over here.

[dankcushions]

I don't think the mame2003plus input changes are appropriate but i think there's clearly improvements to be made and issues to be fixed, like this issue.