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

Riverstorm

@Ashpool - Ah, ok, yeah it's much less "formal". It's basically one long string of commits. There's no official change list between builds/commits with version numbers to help make an educated decision on the best version(s).

They have over 4,000 commits. You can see half dozen changes one day down to none for several in a row. They add and tweak games here and there when they have time.

You could search pull requests something like is:pr is:closed llander and see there have been some updates to llander but that's not quite as handy. There's nothing quite as organized like in mameinfo.dat.

If I remember someone built a fairly extensive spreadsheet of games, based on which emulator works best for each game. That's in the context of RetroPie supported emulators but I don't have the link off hand. I suppose that changes over time too! :-)

Riverstorm

@Ashpool - Or Barbudreadmon has another good suggestion! :)

barbudreadmon

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

If I remember someone built a fairly extensive spreadsheet of games, based on which emulator works best for each game.

You are probably refering to @roslof's spreadsheet.

Ashpool

@Riverstorm As I had hoped to express in my above post... llander1 was just an example and I was aware of the fact that it still is .78 stuff... but it was the 1st rom that came to my mind to use it as an example in regards to the mameinfo stuff... could as well have used indytemp or others... for one that is in the changelog of m2k3+ it could have been lupin3, but even if the changelog mentions it under "Games now with Sound" it lists sampleof "invaders" in the current listxml.dat, I can deduct -> better then .78, as that had no sampleset, but less then .147u3 as that changed the sampleof to "lupin3"... Oh well, and sorry - I am expanding on a topic which is answered by now. And your explanation about the development/commits was also helpfull to understand the whies of it.

Riverstorm

@barbudreadmon - Yeah, that's it, thank you! :)

@Ashpool - I agree that kind of "intermediate" build detail currently happening on these forlonged cores would be quite useful. But since it's all for-the-love-of-it volunteer work I think the devs mostly put their energy and focus into development vs. documenting...not saying someone couldn't add it for the benefit of all, it's on Github, a perfect spot for it under metadata! ;)

If you're using RetroPie you could check out the spreadsheet link @barbudreadmon posted above as a potential starting point. @roslof's spreadsheet has always been impressive from the sheer amount of time he put into testing each game to find a decent running version/emulator.

I don't know...but I think with these old patch work of cores, it's down to elbow grease and a bit of spit and shine to build that "perfect" game roster! ;)

Riverstorm

@Ashpool - One other thought (sorry to make assumptions), was the target hardware is the Pi 4 or some similar low power device. I always assume RetroPie (thanks to their grace for an amazing piece of software) targets a niche demographic, well a pretty large one. Due to it's multi-faceted, multi-platform, arcade, console, DOS, porting, retro-gaming support all-in-one game--jack knife utility! Whew...they're gonna have to steal the Nethack slogan, "the devs thought of everything"...

Anyway I think if you're running "contemporary" hardware there are more elegant solutions to running MAME with fantastic results. Funny thing is most days I still prefer the tinkering on the Pi to get these old cores chugging along with some less than perfect game satisfactorily, hence the spreadsheet posted above.

Ashpool

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

@Ashpool - One other thought (sorry to make assumptions), was the target hardware is the Pi 4 or some similar low power device. I always assume RetroPie (thanks to their grace for an amazing piece of software) targets a niche demographic, well a pretty large one. Due to it's multi-faceted, multi-platform, arcade, console, DOS, porting, retro-gaming support all-in-one game--jack knife utility! Whew...they're gonna have to steal the Nethack slogan, "the devs thought of everything"...

Ok, You've got me there... I was still building up my reply to some former posts... but your wording here is somewhat in grip of what I was trying to express ;>

@Riverstorm Yup, that spreadsheet was new to me and a good resource added in my bookmarks ;) My intention instead was not based on a use case for a specific system/install, but instead somewhat more general - I am not interested in best performance/or whatsoever on a certain system, but instead I want(ed) to check the (min. version of emulator) for the most accurate emulation for now (even if that would mean that I cannot run it on a Pi 3/4, or even my desktop pcs, nor in current mame) available for that rom. As history has shown driver/emulation/color/graphic/whatsoever states within the listxml changed from greed to yellow or red and for some they still remain on ~not_good...

And here I noticed your reply whilst I was typing my answer... so shortcut: I am just a metadata hungry junky, I am not asking about a certain environment/system/whatsoever for a certain game... it is just my interest to get a personal mind map of what game/what system/what state to be played (if at all or wait) on what emulator/simulator/hardware and therefore the question where m2k3+ roms may be located... and sadly there are still many where I am not sure if any emulator will perform like the machine I played in my childhood (Indytemp, Astron Belt (ok, that is not MAME for now), etc.)...

Riverstorm

@Ashpool - Ok that makes sense. One quick question. Are you saying the mame2003-plus DAT has incorrect metadata on the game status? If so I think the devs over on Github would find it useful. They try and keep the DAT correct and current and have done a decent job. If I read it wrong or if you meant "generally speaking" of DATs, disregard.

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

and sadly there are still many where I am not sure if any emulator will perform like the machine I played in my childhood (Indytemp, Astron Belt...

Sadly no game performs like nostalgia! ;)

barbudreadmon

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

there are still many where I am not sure if any emulator will perform like the machine I played in my childhood

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.

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.