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

robertvb83

@riverstorm wow thanks for clarifying! this is great news acutally and i think this is how it should be! only one sample.zip for all the versions. and its nice that all the versions can use the cd quality samples.

i am also missing the second channel files for ffight.zip.

@markwkidd i hear you man! it is sometimes insanly overly complicated. normal people who just want to play will just give up on trying to get a working romset i am afraid...

Riverstorm

I agree I am a bit of purist but it's nice to have options as he made things quite flexible. If you can live with the sample errors in ClrMamePro it works great without them too. It drives some folks crazy seeing set errors! ;)

@robertvb83 - I think in time the right channel will surface somewhere to see if we can hear the difference between mono and simulated-stereo.

@markwkidd - We have a long weekend coming for the holiday and we have plans to go out of town but I hope to get a chance to do some more Unibios testing toward the end of the weekend. I built the set last night and I am going to merge the FBA BIOS also. Thanks for the new BIOS options, it's some good stuff. :)

markwkidd

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

agree I am a bit of purist but it's nice to have options as he made things quite flexible. If you can live with the sample errors in ClrMamePro it works great without them too. It drives some folks crazy seeing set errors! ;)
@robertvb83 - I think in time the right channel will surface somewhere to see if we can hear the difference between mono and simulated-stereo.

I think I probably should add a core option to toggle the CD soundtrack samples, so when you are playing Outrun you can select whether to use the original music or the CD tracks. TODO added!

markwkidd

A considerable amount of the time that I put into working on the core is spent on learning, documenting, improving, and sometimes adding to the internal "systems" that provide the basic functionality of the core. Some examples of what I mean by systems are the hiscore functions, file loading and paths, input (re)mapping, core options, etc.

Today's update to the input system falls under this heading. I'll get back to that.

As of this week we now have preliminary support for making core options and control systems behave in ways customized to the game that is being played. (FBA is famous for having similar functionality.)

This new freedom allowed me to set the Neo Geo BIOS core option to display and be available only when Neo Geo games are being played. That core option implementation is a prototype which will eventually let us do things like only display vector-related core options when vector games are loaded, only display the DCS Speedhack option for games that support the speedhack, etc.

Bringing me back to today's minor update. As a proof-of-concept and with some help from radius, one of the RetroArch developers, I've added custom control labels for Neo Geo games and Street Fighter 2 and its clones. This means that when you are looking at the Controller remapping options for those titles, you will see something like BTN 1: Neo Geo A or BTN 2: Weak Punchwhere before you would have just seen Button 1 and Button 2.

There is still a fair amount of work needed to get new systems in place that would make it practical to create these content-specific control labels on a large scale, but having these two implemented means that as I'm working on the new code I can always be sure that my changes are compatible with the custom labels.

In conclusion, the last couple of days have not been producing any more cool screenshots or new games added but there is plenty of fun stuff rolling forward towards implementation.

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