mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support

robertvb83

@markwkidd this is so f****** awesome! this would be a very big step for user friendly control adjustment. it would make game specific configuration so much easier. Does this work together well with the new input system of latest RA?

to be honest at the moment this is the main reason for me to prefer fbalpha and only use mame2003-plus for games not working in fba.

Is there a basis like a database or xml-file containing that information that you can use for information exchange with the core?

another thing: you have built this new input schemes in mame2003-plus where we can chose from 3 different input types (modern/SNES/classic). This is cool, but I think it still needs improvement. Changing this option is always global but there are games fitting better to different input types even if you always control with your joystick control pad. Chances are good that you only have to change the control scheme and everything is setup right. so when switching between different games I always need to switch to the corresponding scheme and change it again for another game...

For me it would make more sense if the change of this option behaves the same like button input changes only per game (without saving a game options file). Games for which this option has not specifically been changed can still use the global value in main core-options.cfg

second: could you make this option per player? because many people use 2 arcadesticks and 2 usb controllers (snes) for 4player games. would be great to allow input scheme per player depending of the players actual controller.

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

@markwkidd this is so f****** awesome! this would be a very big step for user friendly control adjustment. it would make game specific configuration so much easier. Does this work together well with the new input system of latest RA?

The button naming feature is focused on on how the core communicates to the frontend (RetroArch in this case). Once the frontend has the name for a control, whether its generic like Button 1 or specific like BTN1: Neo Geo A that name should be used consistently for that control throughout the frontend.

The short answer is yes, it should dovetail with the new RA button remapping and all other frontend features. If it doesn't I would like to know, please!

For me it would make more sense if the change of this option behaves the same like button input changes only per game (without saving a game options file). Games for which this option has not specifically been changed can still use the global value in main core-options.cfg

second: could you make this option per player? because many people use 2 arcadesticks and 2 usb controllers (snes) for 4player games. would be great to allow input scheme per player depending of the players actual controller.

The second thing you're asking, per-player setting per-player controller types, is something I'm working to to by adapting dankcushion's code with advice from radius.

I believe that once per-player controller types is implemented that may inherently work like your first question, that changing the controller type changes per game without saving a game options file. I'm not as sure about that answer, so you might want to ask it again if and when the new controller type code is workin.

UDb23

@markwkidd
Can't remember if I already asked this and I absolutely don't want to abuse your kindness (your're making already so much good stuff) but, as you're working on backdrop support... is there any possibility to implement also "LED" support? I mean emulating physical leds ,that were lit on some games' marquee or bezel, thru activation of "led on" specific graphic overlays.

According to Mr Do:
"Games that support lamps or LEDs are a little trickier, as additional programming in the driver for that game is also necessary. Some games that now have these features didn't have them added until after 0.107. For any of these games, whichever version of MAME that was out the day the artwork was last updated fully supports that artwork (e.g. Seawolf is fully working in any version of MAME released since 2007-01-28)."
I fear that this functionality also requires support for the newer .LAY overlay format that seems not possible backport to mame2003.

markwkidd

@udb23 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Can't remember if I already asked this and I absolutely don't want to abuse your kindness (your're making already so much good stuff) but, as you're working on backdrop support... is there any possibility to implement also "LED" support? I mean emulating physical leds ,that were lit on some games' marquee or bezel, thru activation of "led on" specific graphic overlays.

I don't think we've talked about this before. I don't know anything about the LEDs -- I agree the text on the Mr. Do site is not encouraging but this will need to be researched. Could you create a github issue so that someone can look into it?

UDb23

@markwkidd Will check for more docs on this topic and then open the issue. In this way you'll have more info already available.

markwkidd

@udb23 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

@markwkidd Will check for more docs on this topic and then open the issue. In this way you'll have more info already available.

That is what I love to hear! Thank you

Edit: New Backport! Lethal Enforcers

arcadez has just filled a backport request that I think many people will find interesting. The DAT on github isn't updated yet but in the meantime you can generate your own DAT or just try the mame 0.139 romset for this game, which is what I'll be doing soon!

markwkidd

@robertvb83 I spoke too soon yesterday about when I would finish an implementation of the "fancy" button naming system that would be viable long-term and at full scale.

I found that I could not seem to make headway on my other input project without the naming system squared away. Sooo I went ahead and refactored everything for the third time. Now I think it's ready for mass production.

Would you -- or anyone else -- be interested in taking a role in testing this and helping submit a few more sets of button names to make sure everything is indeed working?

Right now the button names still only appear in Neo Geo and Street Fighter 2 & clones.

Adding new button names

In anticipation of eventually opening this up to users to submit button names I have written a doc outlining what information is necessary to add button names. It's not too onerous: https://github.com/libretro/mame2003-plus-libretro/wiki/Submitting-Button-Names

For people who know how to submit PRs on github or are willing to learn, it's also not very difficult IMO to add code for button names yourself now.

robertvb83

@markwkidd what do you mean in the wiki

Naming standard
The standard we use for determining the proper text to use for the name is to refer to current MAME. That is considered the canonical reference.

For example the button names for Street Fighter 2 would be submitted as:

BUTTON1: "Jab Punch"
BUTTON2: "Strong Punch"
BUTTON3: "Fierce Punch"
BUTTON4: "Short Kick"
BUTTON5: "Forward Kick"
BUTTON6: "Roundhouse Kick"

Where do i get this information about the naming standard?

i just made a PR with an example for stonebal. is this like you indended this to be submitted? or is there a better way. i never did this before so it might look strange to you :-)

i have only very limited time right now. we are preparing for a 2month europe road trip this summer... i do my best for testing and contributing but mainly will continue in September again

darknior

@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Lethal Enforcers

WOAW LETHAL ENFORCERS !!! so excellent <3
Really wish we will have more shooter like it on our PI, i love them :p
I don't remember if Mad Dog McCree is working too or not ?
Not working on Daphne for now ...

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

i just made a PR with an example for stonebal. is this like you indended this to be submitted? or is there a better way. i never did this before so it might look strange to you :-)

What you submitted looks viable to me, it should be straightforward to convert to a code patch.

Thank you for also testing out the docs, and providing feedback. I will add some language about how to find MAME's button names.

I'm glad I asked for your help before your trip -- that sounds awesome! I'll try to code your stonebalbutton names ASAP in hopes you can see that in effect before you go :)

robertvb83

@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Thank you for also testing out the docs, and providing feedback. I will add some language about how to find MAME's button names.

also how do we know the button order, e.g. why is it 1,2,3 for punch and 4,5,6 for kicks in sf? could also be vice versa, is there a general rule for that?

I'm glad I asked for your help before your trip -- that sounds awesome! I'll try to code your stonebalbutton names ASAP in hopes you can see that in effect before you go :)

hey cool thanks. i will test this today. i'll be leaving around second week in june so there still is some time...

i have one additional thought about this. please tell me your opinion. i have the feeling that the way of implementing all button schemes is s lot of work and can almost never be finished plus you always have to deal with it again for new games added to mame2003-plus. i thought more of a more generic approach like coding the module for button naming only once (for up to 8 buttons) and for each game apply this generic module filled with the button naming metadata of a general or per game cfg (i would prefer a general cfg)

sf_button1="Jab Punch"
sf_button2="Strong Punch"
sf_button3="Fierce Punch"
sf_button4="Short Kick"
sf_button5="Forward Kick"
sf_button6="Roundhouse Kick"

stonebal_button1="Shoot/Fight"
stonebal_button2="Push"
stonebal_button3="Pass/Tackle"

stonebal2_button=stonebal_button

this way you can finish this whole coding approach applied for all games and if there is an entry in the cfg it will show the respective values in the menu. This database can than be filled from various people and reviewed/released by you.

does this make sense?

robertvb83

it seems like such button naming DB is already existent! there is a controls.ini / controls.dat / controls.xml file. I cannot find one that is later than 0.141.1

there is someone who made a github project to convert controls.xml into controls.json here. which is discussed here

it looks like something that could be used here?

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

it seems like such button naming DB is already existent! there is a controls.ini / controls.dat / controls.xml file. I cannot find one that is later than 0.140

there is someone who made a github project to convert controls.xml into controls.json here. which is discussed here

it looks like something that could be used here?

I think you are really onto something here! It might be possible to write a script that parses the controls.dat/ini/xml and turns it into something that can be automatically added to mame2003-plus. BTW MAME 0.140 is probably a good starting point anyway.

I have some ideas based on your post on how this could be implemented at a large scale and it's killing me not to be trying the ideas out right now! hehe

robertvb83

@markwkidd ok i guess then the old approach is not so relevant anymore, however i testet street fighter and it works perfectly

also ingame the functions are represented correctly!

markwkidd

@robertvb83 said in mame2003-plus: 250 new games, new input system, new features, new bugs:

@markwkidd ok i guess then the old approach is not so relevant anymore, however i testet street fighter and it works perfectly

also ingame the functions are represented correctly!

Yay, thanks! That is definitely relevant. Starting with a solid baseline is something I have started to appreciate as a philosophy when it comes to input code.

grant2258

you should be able to grab all this info from the latest mame with xml or any other list function it provides and parse it with python. just be careful with the usual rom zip name changes ect because different revisions of roms sometimes user different inputport settings

Darksavior

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

grant2258

@darksavior said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

yea does seem off but so does the driver I compared the cpu speeds and ym speeds in lastest mame and they dont match up with the speeds our driver has. mame2003+ aims to run the at the speed the hardware intended. I could be a glitch in timing system as well cant rule that out.

You can see mame2003+ when playing data east games. mame2003 just plays these games too fast the pitch is completely in them. I dont know how fba handles robocop if its running 60fps the pitch will be wrong like mame2003.

markwkidd

Is this one of those issues which can be resolved by turning off/down the RetroArch 'audio stretch' function?

grant2258

@darksavior said in mame2003-plus: 250 new games, new input system, new features, new bugs:

Looks like the system32 games have a lower pitched audio. Not sure when it started. The bug is only in Plus. Original 2003 is fine.

I tested in mame078 mame2003 mame 2003 plus none of them are correct to current mame in pitch its more pronounced in mame2003+ because the timing of the driver wrong