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

Riverstorm

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

As said elsewhere, MAME2003+ is about performance/accuracy compromises.
Current MAME and FBNeo are more likely to be faithful to the original hardware if that's what you are specifically looking for.

@barbudreadmon - I don't know if you agree with that or just quoting but could you clarify a question if you do?

I always think mame2003+ is based on MAME 0.78 official code. A majority of the code and 95% of the ROMs are original. Why is mame2003+ less faithful than FBNeo? I know with the additions some are hacky to get them running and others backport seamlessly and seem to play perfectly but mostly it's original.

I would consider current MAME the benchmark and they always seem to be perpetually tweaking, adding, changing and improving drivers.

Does FBNeo follow the MAME in similar coding? Does it go back and add the updates and tweaks that MAME adds in every revision to stay current as to be lumped into the same class as official MAME or maybe FBNeo just does things better than official MAME?

I know of some very specific examples but beyond cherry picking examples and focusing on the bigger picture of 5,000+ ROMs. I basically load up ROMs in mame2003+ and just enjoy them and find they play reasonably well. I just don't see a big enough difference for a majority of games. There's some games in the mame2003+ that aren't in FBNeo and vice versa so I use both cores. On low spec hardware it's a winning combo (or trio if you count AdvMAME ;) for a majority of my needs.

When it comes to vector games I just prefer AdvMAME. I think it can fine tune the vector lines a bit better than mame2003+. I don't know if RP ever fixed AdvMAME (I think it was slow) but I found a commit prior, made some minor tweaks, loaded all my ROMs and made an image. That is mainly what I use when I play vector games.

I'm not trying to challenge you because I know what you do (I've opened an issue or two with broken games on Github and you/the group always get them fixed) but anyway I was hoping for a better understanding if there's a reasonably straight forward answer because every time you write something similar I ask myself why would that be true.

barbudreadmon

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

Why is mame2003+ less faithful than FBNeo?

FBNeo's goal is to be just as accurate as current MAME, and it's sometimes better, it'll rarely make compromises about accuracy. MAME2003+ is more performance oriented and usually won't include fixes that would have a major negative impact on performance.

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

Does FBNeo follow the MAME in similar coding?

It doesn't, FBNeo's framework has less overhead, hence why it's usually faster.

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

Does it go back and add the updates and tweaks that MAME adds in every revision to stay current

If an update is necessary and we are aware of it, and it goes both ways.

Riverstorm

@barbudreadmon - Ah, ok, thanks for explaining. I wasn't aware FBNeo strove for accuracy as a fundamental. I know I always think of clones that's for sure. :)

I am a heavy m3plus user but I learned a few new things about FBNeo and know where you're coming from a bit better now when I read your posts.

I poke through the FBNeo code quite a bit and use some python scripts to pull info. and did notice it's definitely structured differently then MAME. I prefer it. Easier to work with.

I was curious in your DATs. Will ever add a display/video type to the status line like video type="raster" vs. "vector"? The information is very complete in the current status line except that one tidbit of info. It would make it accurate/complete. I think newer MAME DAT's contain it. ;)

I also noticed minor things like some tabs vs. spaces in the front of some lines, some resolution*2 on the resolution/ratio line in the drivers and some minor capitalization like Akatana vs akatana or Pinkswtsx vs pinkswtsx under the BurnDrv. I was going to open issue on Github but thought maybe some this stuff is intentional and/or minor things like that are not really what you like to focus on.

Regardless have a great evening and thanks again for the additional info on FBNeo. It's a great core and your time and effort spent improving it is very much appreciated!

barbudreadmon

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

I wasn't aware FBNeo strove for accuracy as a fundamental.

With some freedom, some things wouldn't be accepted in MAME, like improvements over the original game, or fixing a game through an approach which is more HLE than LLE, or using speedhacks that won't change the game in any known way, hence why we often say we have a "playability" focus.

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

maybe FBNeo just does things better than official MAME?

I wouldn't say that, MAME is focused on preservation and is doing that job perfectly. Without their detailled information a lot of emulators (like ours) would struggle improving things.

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

I prefer it. Easier to work with.

Me too, MAME has too much abstraction, it became very hard to read their code.

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

Will ever add a display/video type to the status line like video type="raster" vs. "vector"?

Hmm that information isn't available right now without launching the actual game, which is why i omitted it when i added the line about game geometry. Is it very important to have it ?

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

minor things like that are not really what you like to focus on.

Indeed, don't bother reporting issues for this :), drivers are cleaned up from time to time anyway.

Riverstorm

@barbudreadmon - That's great information. I figured the core developers are the best folks to direct that question at because...well, they develop them! :) I definitely have a different point of view about FBNeo. Thanks!

As for the geometry information it helps create shaders for Libretro cores. Basically it was a project Dankcushions started several years ago. Over this past year or so I corrected several things, added a few features like pulling horizontal or vertical games only, argparse() input (every parameter has a default and you can run the script with no parameters), restructured the output and basically added in all the Libretro cores that RetroPie supports to create shaders.

All official MAME DAT's have the same geometry so it's easy to extract all the info and create a shader. Raster vs. vertical is used in the fact vector games don't use shaders so discard that game, in regards to shaders.

Sorry long story short is the FBNeo doesn't contain that one piece of info. so basically I have to read the DAT and extract every game ROM name, then open every driver file searching for information related to the game and build a shader file.

It works flawlessly but it takes time as I read one game then it loops through every driver file. After it finds it and writes a shader file (or not), it reads the next game and starts over. If the game is a (or not) found I write out to different files on the status, like what info. is missing. I think some drivers for example like Dig Dug, Galaga, Xevious drivers are setup a little differently and not in the BurnDrv(gameName) format.

Speaking overall FBNeo code is very clean and consistent which makes it much--much easier to work with. I do have to use regex to get around some of the anomolies like space vs. tab or capitalization etc.

With mame2003, mame2003+, mame2010, mame2015, mame2016 they are super fast because complete geometry info. is contained in the DAT but FBNeo is missing that one piece of info. hence the long way.

I don't know when the geometry info. was added to FBNeo (or maybe it's been there for years) but I don't think it was all there, I'm not 100% sure. Then one day I was like shoot everything is here but the display type...I wasn't sure if it was easy to add as it's useful for other projects, as well as, set building. For me DAT's are my holy grail path to building a proper set. I'm a hard core DAT user. Sorry that was a bit long.

Riverstorm

@barbudreadmon - The other piece is FBNeo is the most actively developed (in regards to adding new games) followed by mame2003+ so I need to run it regularly to keep those two cores shader files up to date.

arcadez2003

Another new playable one......

Fantasy Zone II The Tears Of Opa Opa (Sega System C Version)

WeirdH

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

Another new playable one......

Fantasy Zone II The Tears Of Opa Opa (Sega System C Version)

Awesome, thanks! Confirmed working. On FBNeo it is too demanding for my ancient Pi 3B+, so this is great news. Will high score saving be implemented as well? (doesn't seem to save scores right now for me)

arcadez2003

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

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

Another new playable one......

Fantasy Zone II The Tears Of Opa Opa (Sega System C Version)

Awesome, thanks! Confirmed working. On FBNeo it is too demanding for my ancient Pi 3B+, so this is great news. Will high score saving be implemented as well? (doesn't seem to save scores right now for me)

It hangs off the same code as all the other Sega System 16 games it should save if they do.?? and equally if they dont save then neither
will this one :)

janderclander14

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

As for the geometry information it helps create shaders for Libretro cores. Basically it was a project Dankcushions started several years ago. Over this past year or so I corrected several things, added a few features like pulling horizontal or vertical games only, argparse() input (every parameter has a default and you can run the script with no parameters), restructured the output and basically added in all the Libretro cores that RetroPie supports to create shaders.

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?

Thanks!

WeirdH

@arcadez2003 Just tested with Alien Syndrome and that DOES save scores. Do I need a newer hiscore.dat or something else externally for Fantasy Zone 2?

EDIT: First Fantasy Zone also saves correctly, btw.

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.