lr-mame2003 driver improvement and backport

dankcushions

@andershp said in lr-mame2003 driver improvement and backport:

Apologies are on me, I was not aware that mame2003_plus_libretro existed. But what exactly are the differences to lr-mame2003 if both are maintained? Just two parties updating mame2003 alongside each other?

the two exist separately (at the moment) because we don't want to break existing mame2003 functionality/romsets. the plus changes started life as changes to mame2003 but there were a few issues with builds failing and samples not working, so having it as a separate entity frees the developers from these concerns and also means that mame2003 remains stable.

really, mame2003plus should a branch of mame2003, or something like that, but it's semantics i suppose.

Riverstorm

@andershp said in lr-mame2003 driver improvement and backport:

Apologies are on me, I was not aware that mame2003_plus_libretro existed. But what exactly are the differences to lr-mame2003 if both are maintained? Just two parties updating mame2003 alongside each other?

To add to what Dank mentioned a programmer named Arcadez decided to add and fix additional games not working in lr-mame2003 but it was causing some minor issues. So then it kind of became a derivative of lr-mame2003 and has kind of taken a life of it's own. Their are 3 very active developers (Arcadez, @markwkidd & @grant2258) that have added 100+ games and updated another 30+.

I think the goals are similar of both projects in getting some lost classic arcades games working but it allows each the freedom to develop down a path of their choosing without worry of breaking lr-mame2003 or vice versa but they can also share the code too if there's a fix one or the other may utilize.

Basically they both run the same games but mame2003_plus_libretro has some additional games that lr-mame2003 does not. lr-mame2003 has 2 games that mame2003_plus_libretro does not listed below.

Only exist in lr-mame2003:
• Cabal (US set 2) (cabal2)
• Urashima Mahjong (urashima)

I haven't updated it in about a week so the numbers are actually higher but mame2003_plus_libretro has 4,810 total ROMs, 4,687 are the 'hash' duplicates of lr-mame2003, 92 ROMs are new only to mame2003_plus_libretro and 31 ROMs have been updated. They may be either clones or sound samples, etc.

ROM Count:
Total ROMs in mame2003_plus_libretro - 4810
Duplicate ROMs matching lr-mame2003 - 4687
New ROMs only exist in mame2003_plus_libretro - 92
Updated ROMs in mame2003_plus_libretro - 31

grant2258

old games that ran 47 fps and below are now working in mame2003 and mame 2003 plus (bally atari and more)

AndersHP

@riverstorm said in lr-mame2003 driver improvement and backport:

Basically they both run the same games but mame2003_plus_libretro has some additional games that lr-mame2003 does not.

Why then is lr-mame2003 the recommended emulator? It seems everyone should use mame2003_plus?

mediamogul

@andershp

The vanilla 0.78 ROM set and samples used by lr-mame2003 are more accessible, making it an easier setup for most.

AndersHP

@mediamogul but in the docs for mame2003 plus it says "The MAME 2003-plus core accepts MAME 0.78 ROMsets for 99.9% of games" ?

mediamogul

@andershp

If you were to make use of the vanilla 0.78 ROM set with lr-mame2003-plus, 99.9% of the games would work, but there's really no reason not to use the original lr-mame2003 and get that extra 00.1% that would otherwise be incompatible.

Riverstorm

@AndersHP - Also remember right now it's still experimental. It's in that section. It's in a very rapid development cycle and some things might be broken and fixed an hour later. I've downloaded from source 5 or 6 times this past week.

You can definitely make it your preferred emulator (especially if there's new games that are favs) if you have the correct ROMs to build a set and are alright with some occasional quirky behavior.

You can also pull only the new/updated ROMs that run only in Plus and use the Arcade folder that allows multiple emulators for one platform. I can make a DAT for that too.

Any testing and feedback is great of what works and what's broke. It might become the preferred emulator down the road or merged with lr-mame2003 down the road. It's hard to say as folks higher up will need to decide a course of action.

dankcushions

plus has had issues with failing builds and so forth. it will get there! just be patient whilst development goes on :)

edwardthehuman

When I install this I get:
Could not successfully install . /home/pi?RetroPie-Setup/tmp/build/lr-mame2003-plus/changed.txt not found.

Then it tells me to see the log to see what the error was about. TO whom can I provide the log file?

mitu

@edwardthehuman What version of RetroPie are you using ? I remember this has been corrected a few versions ago - you should update your setup script to 4.4.

edwardthehuman

@mitu Hi, i tried it first using 4.3 and didn't work. So I just updated it to 4.4 and still the same result. Thanks

mitu

@edwardthehuman It seems the github repository is undergoing a few changes which have not been picked up by the install script. Wait a few days until things settle down and I'm sure it will work again.

edwardthehuman

@mitu Okay I will wait a few days before installing it again. Thank you

markwkidd

I think this PR should update RetroPie-Setup the way it needs to in order to compile again: https://github.com/RetroPie/RetroPie-Setup/pull/2369

I've been making changes oriented towards having a long-term stable period in the repository. I've updated the license and documentation within the repository to match github convention.

I've also been removing one of the layers of abstraction between libretro and MAME around file handling functions. There's a bit more to do but the end is in sight. Not the sexiest section of the code, but this project is intended to make it easier for new developers to come along in the future and understand how mame2003/mame2003-plus locates, loads, and handles files internally.

grant2258

@markwkidd said in lr-mame2003 driver improvement and backport:

I think this PR should update RetroPie-Setup the way it needs to in order to compile again: https://github.com/RetroPie/RetroPie-Setup/pull/2369

I've been making changes oriented towards having a long-term stable period in the repository. I've updated the license and documentation within the repository to match github convention.

I've also been removing one of the layers of abstraction between libretro and MAME around file handling functions. There's a bit more to do but the end is in sight. Not the sexiest section of the code, but this project is intended to make it easier for new developers to come along in the future and understand how mame2003/mame2003-plus locates, loads, and handles files internally.

I seen youve been doing quite a bit of work mark. I noticed issues when changing the sample rate the changes your doing are needed and appreciated. It could be a wild guess where a variable was being set at times in the options

markwkidd

@grant2258 I actually started out just wanting to clarify how the paths were selected for the various filetypes, specifically with samples in mind. Of course it got to be a bigger project than that as these things do.

I would still like to simplify the file path section but I think with my latest PR I am done for now. Assuming there are no regressions.

The only other project I have is to try figure out why I don't have access to the libretro logging interface at some times when I think I should, for example when samples are being loaded. I've been told in the past to try to avoid logging to printfbut I must not understand something about the libretro log callback because it's not always there when I need it.

markwkidd

One nice thing that is happening today is that twinaphex is putting in time updating the Makefile and updating some other mame2003-plus components. It's good to have the lead dev working in the codebase every once in a while I think :)

grant2258

@markwkidd would need an example in the code to see where you need the logging to work and it's not. I can take a look if you like

markwkidd

@grant2258 said in lr-mame2003 driver improvement and backport:

@markwkidd would need an example in the code to see where you need the logging to work and it's not. I can take a look if you like

Thanks, I keep putting this off. The background to this is that twinaphex asked in general for me to not add more printf logging, so I'm trying to use libretro's log system to the greatest extent possible.

Here's some logging code that I think should be executing with any game that supports samples: https://github.com/libretro/mame2003-plus-libretro/blob/master/src/common.c#L260

I'm not seeing that logged to in the console in --verbose mode.

From my understanding, log_cb should already be initialized here: https://github.com/libretro/mame2003-plus-libretro/blob/master/src/libretro/mame2003.c#L480-L483

I assume it's that I don't understand something about libretro logging.

I could just try to initialize log_cb again in common.c like it's done in mame2003.cbut that seems like an ugly way to go.

   struct retro_log_callback log;
   if (environ_cb(RETRO_ENVIRONMENT_GET_LOG_INTERFACE, &log))
      log_cb = log.log;
   else
      log_cb = NULL;