[mame2003/-plus] Removing individual per-game bindings via Tab menu

markwkidd

I still need to reread this thread carefully, but to echo Grant -- each time someone has posted a specific game where they want a None mapping, it has turned out that there is an input bug with that game driver underlying the reason for wanting None. In that sense, it does seem very productive to keep giving examples because bugs are being fixed.

markwkidd

I apologize for making on the fly replies, but also in general I think it's good to keep up with either what current MAME or FB Alpha does when there is some part of the user experience that can be unified across the emulators.

So in principle I'm also interested in bringing things into conformity. Grant and I have both been committing a relatively large amount of code the last few days as we try to take care of some outstanding bugs and other cleanup. When I say I need to reread this thread, I also need to look at Grant's prototype of this new functionality.

Is a best of both worlds where 1) you and Riverstorm keep listing games that require this treatment so that they can be investigated while also 2) I try to understand how this works in later MAME from a user experience and work with Grant's initial code to see if we can make it work in a way that is compatible with everything else that is going on in our version of the MAME input code?

Riverstorm

@markwkidd - Yeah I am ok with that proposal. It's pretty much the same as what I posted above. This enhanced functionality puts Plus inline with MAME "current", AdvMAME and some derivative works so the user may handle these types of exceptions themselves and without using "placeholders". It was implied for TAB only input as Input (this game) doesn't exist in RA.

I agree it does help track down bugs and there's been some updates for classic games. You have to love that Assault tank roll or the split stick mortar shot. It's a fun game the same as Vindicators is great also. They both work great with tank stick not mappings as well as Battle Zone.

I don't know if you saw the list earlier. You might have squashed some of these bugs already and some are not necessarily related to this post but they are bugs. I can post them in the main thread if it helps.

Assault (control issues and extraneous fields 4 total; player 1). Also with Assault the input fields are grouped by name so P1 Right/Up is below P2 Right/Up or P1 Button 1 is in the middle of the list and P1 Button 2 at the bottom. So this basically interleaves the P1 and P2 fields all the way to the bottom instead of listing all the P1 fields first and then all the P2 fields. It's very difficult to follow.
Vindicators same issue of extraneous fields (8 total; 4 for each player)
Button labels on controller show incorrectly in TAB input (i.e. - Button B = RetroPad1 B RetroPad1 Rstick Down)
Joust, Joust 2, Robotron & Food Fight have bootstrap issues. Food Fight looks like it just needs an enter, so that one might be ok. It's not really an issue on the Pi but other platforms I believe that need that bootstrap to start. Those are some pretty classic games.

I tested the rest of the list posted in the Github issue where SapphireTactician left off. I updated the last post with the results a few weeks ago. If there's other bootstraps to test just let me know.

Parent and clones needing bootstraps:

foodf
foodf2
foodfc

joust
joustwr

joust2

robotron
robotryo

grant2258

i have to leave for work have you read the issue? explanation rstick isint wrong it is mapped and is mappable in mame2003+

Riverstorm

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

i have to leave for work have you read the issue?

I haven't, if it's been fixed that's fine. I know you guys did a lot of updates yesterday and I am actually behind several days now.

Clyde

Hi, just popping in to say that although I did read every post since my last one, I'm too tired to answer adequately at the moment. But I'll do so in the course of tomorrow; and in short, I concur with most of what's being said.

Thanks to all of you for participating in this and for keeping it civil despite of some misunderstandings and disagreements. 👍 (<- In case you can't read this; it's a Thumbs Up unicode character.)

Good night. 😴

Riverstorm

@Clyde - Thumbs up is looking good but the finger nail needs trimming.

markwkidd

@Riverstorm IIRC you logged those NVRAM bootstrap issues in the bootstrap issue on github, right?

I will eventually sit down for an afternoon of generating NVRAM and turning it into bootstrap files, and I'll get those. It may be a little bit longer but not forever.

I also have it in mind to write a tutorial to make it easier for someone like yourself to generate the NVRAM file, submit it to me, and then I do the processing.

No need to set up a compiler environment or anything like that. In a nutshell: use standalone MAME 0.78 (usually) to generate an NVRAM that works, test it in mame2003-plus, then send it in. But I digress -- I will definitely get back to the bootstrap issue. And write a simpler guide to NVRAM.

Maybe that's going to be my Thanksgiving holiday project.

Riverstorm

@markwkidd said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

IIRC you logged those NVRAM bootstrap issues in the bootstrap issue on github, right?

I did I do have them generated if you can use them. I generated several from 2003 and Plus to compared CRC's and they match. I wasn't sure if there would be differences between the two versions but from the ones that need bootstraps both versions of 2003 are identical.

markwkidd

Actually yes, this could speed things up for me! What I'll need is the .nv file itself and the list of romsets which it can be applied to.

As you may know, sometimes clones can use the exact same NVRAM but sometimes it has to be generated uniquely for one clone (or uniquely for every clone, three out of seven, etc.) The more of this you post, the less I have to check myself, pretty much :)

If you zip the NVRAM files, github will let you drag and drop a zipfile right into a comment in a issue discussion to attach the zip to your message.

Riverstorm

@markwkidd said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

What I'll need is the .nv file itself and the list of romsets which it can be applied to.

Ok, that sounds good. I'll generate the DAT from each separately to be sure, compare hashes and post over on Github flagging any duplicate hashes but will leave the files separate for each ROM set.

grant2258

@Clyde im going to try get the manual for assault and make sure out controls are the same as the arcade cab they should be without any extra mapping. When i find the info and test what we have ill post my findings. That way we we know its done right.

grant2258

https://www.arcade-museum.com/manuals-videogames/A/Assault.pdf

page 10

I went into the service menu everything is mapped right for us.

retropad dpad p1 js1 in service menu
retropad rstick p1 js2 in service menu

ill need to find my second xbox360 pad to confirm p2

@clyde there is an option to map the mame rstick to buttons this is not really a good idea for this game as it used a button just map the rstick mame tab menu in the game.

grant2258

2:49 confirmed as working right as per arcade controls and manual. I will accept this as default for mame. If you want to customize this to something different to the original arcade. Please give us the setup your doing and we can try help you achieve what you want within the input system

Clyde

Finally some spare time to address some of your comments. ,:)

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

you wont have these issues on other mames if you disable cheats. its explained in the github issue whats happening with this game and a few others .

The issues about cheats & inputs are a interesting read. I never thought of the additional single stick bindings in e.g. Assault to be connected to cheats.

sorry if i wasnt clear the fix is none user intervention the code posted where to set the key to none is something else.

It's okay, I got it now. :)

@markwkidd said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

Is a best of both worlds where 1) you and Riverstorm keep listing games that require this treatment so that they can be investigated while also 2) I try to understand how this works in later MAME from a user experience and work with Grant's initial code to see if we can make it work in a way that is compatible with everything else that is going on in our version of the MAME input code?

Like @Riverstorm, I am (very much) ok with that proposal.

I caution though that I may not be able to post problems in single games very often, as I do not test that many games regularly, and my recollection about past problems (which I may have fixed somehow or just left alone) leaves much to be desired. 😇 My motivation for proposing the none binding mainly comes from longstanding MAME experience and a general preference for clear and consistant configurations (i.e. an undesired binding should be set to none and not to a dummy key).

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

2:49 confirmed as working right as per arcade controls and manual. I will accept this as default for mame. If you want to customize this to something different to the original arcade. Please give us the setup your doing and we can try help you achieve what you want within the input system

I can't test this right now, because my Pi is occupied with a legthy scraping process. I will get back to you on this.

@all I answered everything I thought that needed to be. I any of you thinks I missed something you want me to address, feel free to remind me about it.

edit: some typos

Riverstorm

@grant2258 - It looks like everything is working ok but some fields seem to be locked to NONE. I thought you were just going to default the values to NONE but I can't change them at all that I could fine while testing. I'm ok with that but wanted to verify that was the intended behavior?

Is it only Assault and Vindicators with locked fields or are their other games too?

grant2258

They shouldnt be settable i will hide eventually if mark wants. We will need another core option the though allow cheat/dip input ports enable|disable else i can just hide them.

To be more clear the cheat puts hacked input port in and lets you set it. Thats why you had to do that crazy not mapping because it added a normal joystick that shouldnt be there. Only the buttons and the left/right stick should be settable.

grant2258

@Riverstorm details are here for the explanation

https://github.com/libretro/mame2003-plus-libretro/issues/464

Riverstorm

@grant2258 - That sounds good. Hopefully Mark will get a chance to look at that code to potentially implement it. Whether related or not I know I've seen a few 2 players games with inputs for player 3 credits or extra buttons that are not even part of a game.

He did a great job with 4-way games, it works well. I like how it turned out as toggle option as either enabled/disabled. I made it much further in Congo Bongo with the "rotated" stick.

grant2258

@Riverstorm said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

ill get a chance to look at that code to pot

the code to disable these cheat ports has been implemented already its up to Make or Arcazde if they wants to hide them when disabled or not and infact let them be in enabled or disabled.

Just like the 4 way I can provide the code but the decissoin on what to do with it isnt for me to make as im only a contrubuter now. If i want to try something the guys are usually ok with it to be fair.

If we had more testers I would have implemented it. Only got feedback from yourself and robert so it remained a core opition from my perspective.

I havent tested the auto dectection code yet will need to do that have had other stuff ive been testing atm. I will get round to it though