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

Riverstorm

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

Wow! that sounds great! Is this a public repository that could be shared? Or maybe just the updated resolution_db files for the different libreto cores so that generated shaders can cover the latest additions?

Yes, you're more than welcome. You can find it here. mame2015 and mame2016 are exponentially larger so I tried to clean them up a bit. I removed entries by driver. For example any entry tagged with xbox, xerox820, zaurus, etc. are skipped. I can also add back any that are erroneously removed etc. Basically it's a work in progress.

fba2012 is still supported in RetroPie but it's list is not 100% accurate. I used the DAT supplied in the RetroPie docs and then did some manual cleanup. If an accurate list of games that are supported in the build ever popups I can easily build the database.

For the most part they should be accurate and current. mame2003+ and FBNeo are the two that are updated with new games regularly. I updated them last week.

Riverstorm

@janderclander14 - Also the resolution_db files are sorted alphabetically. I find it easier to search for games that way.

There are some bat files with different parameters to see some good examples of using it. Every value has a default, the only required value is the core, such as 2003plus = mame2003+. You can take a look, it's all documented.

janderclander14

@Riverstorm Great, thanks! The coverage difference with respect to the older version is massive.

Riverstorm

@janderclander14 - Yeah, I was on a roll and decided to add them all!

arcadez2003

A couple more Sega games which can now be played using MAME2003+

Bullet

Cotton

arcadez2003

Another Sega System 16 game which can now be played in MAME2003+

Action Fighter

Sega's take on Spy Hunter i suppose not a bad wee game though

WeirdH

@arcadez2003 Updated to give Cotton a whirl, but couldn't get a working romset going through clrmamepro. ~~But even stranger: after the update, fantzn2x lost all sound. I just reflashed a backup from a few days ago and then it's fine again. Could the Bullet/Cotton update have broken Fantasy Zone's sound?~~

EDIT: just noticed it lost sound again, but only after I added autoloading and saving of savestates (to get around the hiscore not sticking issue). Does autoloading and saving not play nice with sound? The game? The core? Will do some more testing...

EDIT2: it appears that mainly savestate_auto_load = true wreaks varying degrees of havoc on some games (and doesn't even seem to work in others), so ignore the above about the update. Also, I have on-screen notifications turned off, so maybe I'm just dense.

Carry on!

Ashpool

Ok, first I wanted to follow @Riverstorm's advice in the FBNeo threat and open a ticket over at GIT, but somehow asking/mentioning it here 1st feels more comfortable:

I don't want to start any semi-religious war about proper DARs, but eventually (checked in mame2003/mame2003+ and 0.247) assuming a DAR of Horizontal 4:3 per screen for NES based (VS.) titles is debatable and 8:7 may be more appropriate (FBNeo is treating them with a PAR of 1) ? Maybe that could even be a per-game (miss-)interpretation, as eventually some developers may have designed the games with a 4:3 in mind and others went just for a PAR of 1 ?

some references:
https://www.nesdev.org/wiki/Overscan [For_emulator_developers ]
https://forums.libretro.com/t/correct-geometry-aspect-ratio-for-different-systems/1502
~~https://videogameperfection.com/forums/topic/43-87-aspect-ratio-correction-for-snes/~~

Edit: after reading the 1st link again and comparing the output from lrfceum (using the video mode default (PAR 8:7)) with mame and fbneo, i can only say that I got pictures of three different width (mame > lrfceum > fbneo) and hard to say which may be the right size (though the picture in mame looks imho a bit too stretched).
Edit2: and obviously there is one more difference between mame & fbneo: pixel_res mame 256x240 vs. fbneo 256x224 (if I understood the NESDev-link correct, 240 should be what the nes ppu provides, but top/bottom 8 pixel of that are never meant to be visible?).

Riverstorm

@Ashpool - Yeah it's a thought provoking discussion for sure. It might help to keep in mind there's a difference between the calculated aspect ratio using the game's actual/real resolution and the target aspect ratio of old arcade monitors, which were usually 4:3 (or 3:4) displays.

Also I believe typically they were stretched, a little, horizontally or vertically to achieve that DAR. That alone would change the PAR but the DAR of 4:3 or 3:4 was still pretty much the target for typical arcade games.

Modern displays usually have perfectly square pixels with no "bleed" but old monitors not so much.

It's pretty easy to get the DAR of any old arcade monitor. Measure the height and width and divide it. There's a lot of threads on the subject over the years that you could look up that might help.

I a few pixels off off the screen (or on the screen) change the look of the game but I would just go with how it typically looked but that's the beauty of the Pi, you can tweak it to your hearts content and liking.

Also, you probably already know this but you can set custom viewports to pretty much any size or even do a 1:1 PAR on all games (but I think usually you need a bit of stretch on one axis or the other to get it looking proper). These are just quick tweaks in the Libretro menus to help get your rig setup to your liking.

Ashpool

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

Also, you probably already know this but you can set custom viewports to pretty much any size or even do a 1:1 PAR on all games (but I think usually you need a bit of stretch on one axis or the other to get it looking proper). These are just quick tweaks in the Libretro menus to help get your rig setup to your liking.

Jup (thanks for the reminder!), you're right there - any ideas where I can rtfm some deeper infos about the .cfg entry for the geometry config parts (like aspect_ratio_index = ##, etc.)? The DAR in question [1] isn't available as a preset (ok, 6:5 is pretty damned close) and otherwise setting a custom viewport is done by bounding box (w/h) in pixel + offset in regards to the displayed resolution - or is there a generic way of providing just PAR or DAR?

1: SAR * PAR = DAR -> 256:240 * 8:7 = 1.2190... which complies to the information provided in the NESDev link, and also matches what lr-mesen displays with its defaults on a fresh install (curious as I am, I tried it out after it was mentioned by @barbudreadmon, and the image dimension from gradius where 292x240, lr-fceumms image was 274x224 (= 1.2232...). So i guess, for myself it will be 292':240 what i am going to use (until further/contraticting info comes to my notice ;] )).

Riverstorm

@Ashpool - Sorry, for some reason I'm not getting replies from the thread even though I'm watching.

Custom cfg's don't have much to them. Use a ratio index of 23 for custom. The other commonly used ratios should be in the menu list. I've only used 23 in a cfg but any should work. If I'm testing then I just defer to the menus for a quick changing/testing vs. something more permanent in a cfg.

After that you basically need viewport width & height and viewport x&y (the offsets). I use one on every game to improve shaders.

Converting between PAR and DAR is pretty straight forward but I'm curious on the 292. Can you show me the formula you're using to get to that resolution?

Ashpool

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

but I'm curious on the 292. Can you show me the formula you're using to get to that resolution?

By resizing "source"-image (256x240) with a 8:7 PAR to one of 1:1 -> 256*8/7 = 292.571428(repeating), rounded down to even (292x240). Just to mention it: by reproducing the steps mentioned in the nesdev-link in PSP12 (adding 2x12px border, then (pixel-)resize to DAR 4:3) I am getting 293px for the game-image-area, but imho even numbers are easier to handle.

Riverstorm

@Ashpool - Thanks for sharing the link. That was useful. I was getting there but more of a round about way. I could only get there with the DAR and not the aspect ratio.

aspect ratio = ?
(width / height) / DAR = pixel squareness
width / pixel squareness = 292.55999...

or as 8:7
(width / height) / aspect ratio = pixel squareness
width / pixel squareness = 274.28571...

or as 4:3
(width / height) / aspect ratio = pixel squareness
width / pixel squareness = 320

I guess I usually trust the core to do a good enough job on resolution and conversion adjustments or like you pointed out even certain PARs like 6:5 (1.2:1) are damn close. For me to raise a red flag of this doesn't like right it has to be pretty far off.

If it helps here's a script I use to generate shader cfg's. It wouldn't fit the bill of "exactness" you're looking for but it shows the basic parameters of creating a custom cfg. to hit that 292:240 exactly. Do you know what the core generates for a resolution by default? I take it it's not 292:240? Are you scaling up to 1080p? How are you scaling up (manually; integer scaling to keep the AR?) It's a big task to adjust every game without some type of script to generate custom cfgs.

https://github.com/Wilstorm/retropie_shader_configs/blob/main/retropie_shader_configs.py

For vertical games it fills the y axis and adjusts the x axis based on the inputted target resolution to attempt to make them divisible by whole numbers within a user set % tolerance and more or less vice versa for horizontal games. Basically it helps clean up shader artefacts at the slight expense of some stretching on the x or y axis.

The math is somewhat similar. I update the databases once in a while. Mainly m3plus and FBNeo change and add games but the rest are fairly static. The newer MAME DAT's like mame2015 and mame2016 have a lot of unneeded entries that I try to pull based on the driver such as xbox or xerox820 or zrt80, etc. but the extraneous cfgs generated don't hurt anything but I continue to tidy them up. The newer ones are just huge!

Ashpool

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

I guess I usually trust the core to do a good enough job on resolution and conversion adjustments or like you pointed out even certain PARs like 6:5 (1.2:1) are damn close.

1st: by 6:5 i've meant the DAR not PAR you get from resizing 256x240 by the PAR of 8:7, without adding the borders needed to get a 4:3 DAR covered - or maybe we may need another term instead of DAR here? PAR1-AR? [AFAIR setting a DAR in the core is in reference to the targeted/source DAR and will be blanked/bordered if the used display is of other dimensions/aspect-ratio |my assumption: -> so, if MAME is simply ommiting the step of adding the blanks from 256 to 280, 6:5 is the DAR to be set in core options to get the "292", instead of the "320" the core is stretching to by assuming a "direct" DAR calculation from SAR to 4:3|]
2nd: I too, in general, keep faith in the cores... But somehow they are (in regards to one emulation they share (nes in our current context)) in some form of disarray (For instance by just using the SAR size of 256x224 (ommiting the 2x8px invisible bars on a analogue crt screen (if you ever captured a video tape or analogue tv signal you will remember the areas in the captures you have not seen on tv's screen - more real visible picture left/right, but also some blank/bar above and garbage below the image (which in fact could have incorporated digital data transmissions))) you are not changing the PAR, so 292x240 (with the 2x8px top/bottom offscreen bars) should also be identical to the image in 292x224, and 272x224 is simply the +-~same Image-AR covered, but gained from a wrong pixel-stretch... And now you got me (eventually) hooked .:. It reminds me on old VHS captures and getting the captured signal right (guides and information) ... and well .. I am not sure who (in general; not me nor you meant) is right, or more close to be exact... and maybe this should go to some seperated threat in general or wherever if we continue it (on the example of, and solemnly for the nes?) ;)

p.s.: Thanks for the link to your script! I have/had a project to calculate a custom viewport running (also in python)... but with a different goal/aim in mind (unfinished by now) - and such things/observations as this one are always telling me that there is another case to be captured (my scripts build upon the assumption Arcade (MAME) is 4/3 or 3/4 per screen if the xml information ain't providing contratictinging data)...

Riverstorm

@Ashpool - ooops! Easy now, just a typo on PAR…I’ve got PAR/DAR/SAR on the brain. 292:240=73:60 should work to calculate squareness. I was just trying to help you get to that perfect res. ;)

No need to make a new thread. I have no opposition to your math or point of view. I simply don’t play enough NES to care about the finer details. I forgo the perfect dimensions to use shaders. All these questions should be easy enough to answer by firing up a core and see what it outputs with different settings. Worst case scenario screen capture should grab any “dark” pixels as well as the picture.

Ashpool

@arcadez2003 since the catver.ini wasn't updated in a while, and as I just brought it up2date for my personal use (in regards to the last datfile commit from december 22), I would like to ask whether forking the rep and opening a pull-request for it would be ok and if so, are there any conditions I should be aware of for the format of the catver.ini? For now I just inserted/removed in place, but by that there may be a chance that I eventually will break/have broken the clones under parent-name ordering as it is now (at least that is what I assume to be the reason of all the breaks in the pure alphanumerical ordering of catvers I am aware of).

arcadez2003

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

@arcadez2003 since the catver.ini wasn't updated in a while, and as I just brought it up2date for my personal use (in regards to the last datfile commit from december 22), I would like to ask whether forking the rep and opening a pull-request for it would be ok and if so, are there any conditions I should be aware of for the format of the catver.ini? For now I just inserted/removed in place, but by that there may be a chance that I eventually will break/have broken the clones under parent-name ordering as it is now (at least that is what I assume to be the reason of all the breaks in the pure alphanumerical ordering of catvers I am aware of).

First i've spotted this having been busy with code and things, you could always open an issue on the MAME2003+ git then the whole team
can have a chance to discuss this further.

Regards.

Ashpool

@arcadez2003 Thanks & Done...

Ashpool

Sorry to bother again [!], and not shure whom i should @ here, @arcadez2003 / @administrators (?).
In regards to the doc-pages for retropie/mame2003-Plus...

Currently cite for the catver.ini is:

The MAME 2003-Plus catver.ini also contains data on games definitively known not to work, as well as sorting data for mature games or other, less desirable, romsets.

I am not a native speaker, but for me it implies that the catver.ini holds the metadata for the working state within the emulation (plainly wrong assumption), but maybe it could also be read as "it also includes genre informations for games known as not working" - the information working state is (AFAIK) part of the mame datfile, not of the catver and I would either like to change that phrasing to a plain definition of the catvers function (assigning genre/subgenre and mature state (and of no relevance in this case, but for younger mame/catver generations additional mame version information) ) or remove the mentioning of the catver from the docs.
Nevertheless, as said, I am not a native speaker and I am not sure whether i missed some meaning of that phrasing ~~and~~, or if not how it could be rephrased into something simpler and short that just implies/states that as the m2k3+ core diviates from the pure mame branch and the catvers (from the progetto-SNAPS page) for a certain mame version can't be matched to it, the projects git page provides its own catver.ini to supplement this core.

Riverstorm

@Ashpool - It might be just misreading it. The word 'definitively' isn't really required to make the point but it does let you know what is written is absolutely correct, without doubts. Pretty much by definition. I suppose you could use 'definitely' vs 'definitively' but they are kind of different. Similarities with two different uses.

It's just saying some entries exist that aren't part of the working set or basically extraneous entries. I think you're saying the same thing but it sure can't hurt to make the verbiage more clear if the doc folks feel the same.

"it also includes genre informations for games known as not working"

I think you need to make information(s) singular and I would change it to something like this:

"It also includes genre information for games known to not work."

You could also drop 'genre' implying the subject is the catver.ini if it's been mentioned previously or is the section heading, etc.

"It also includes information for games that do not work."

but that might be to close to what was originally written or by inserting definitively again.

"It also includes information for games that definitively do not work."

There's definitely more than one way to skin a cat on this one! ;) Regional dialect can dictate the verbiage. I think you can have a lot of fun with it honestly but I'm not sure who maintains the docs.