MAME2010 support for -rompath #159
Comments
|
This is the libretro core of MAME standalone as of ~2010. as such, it still contains a lot of redundant documentation for standalone MAME that does not apply to this libretro core. e.g. Rom access is controlled via Retroarch (or whatever you're launching this with) system_dir/rom_dir. This comment in the linked pull request sums it up: batocera-linux/batocera.linux#11907 (comment) I suppose all these old docs and redundant code should be deleted from this repo but it's a bit of busywork, really, and I suppose that stuff sometimes ends up being useful as a reference. |
|
@dankcushions Thanks for your input. Are you familiar enough w the codebase to assess how easy it would be to backport the |
|
It would be a bit antithetical to how a Libretro core works. It's not launched on its own, but via a front end (typically Retroarch), so there's no mame executable that you're passing arguments to - a libretro core is a library that's interacted with by the front end. As for exposing rompath as a Retroarch core option or whatever - again I think that's a bit antithetical. The front end already has a configurable rom_dir so any other option would duplicate/conflict with that. It's just a redundant option in this context I'm afraid. |
What I see happening in both Launchbox and Batocera Linux is a config generator passes either a command file or in the case of MAME2010, a so implementing a rompath option is not an issue from this perspective.
I have to respectfully disagree. what a MAME2010 was built inside a different mindset - we're managing rom sets at a whole new level today. Im aware I could easily file this issue & throw it over the fence but if I've learned anything about open source contribution is what seems to work is taking 100% responsibility over one's request to the point of being willing to do whatever it takes to make the change yourself inside the listening of developers at large (even outside this repo!) So thanks again for forwarding this conversation. I still would like to get a sense of the scope of this change or if I'm biting off more than I can chew 🐘 but I'll make this call once I get a sense of whether it's an architectural issue introduced in the C++ rewrite of MAME. |
|
While it's not the normal/preferred "libretro way" to do things, we usually err on the side of cores being as useful as possible vs ideological purity. Having the precedence/consistency of the mame-current core is in its favor, as well. |
|
Perhaps I'm not really following what issue this would be solving. If you want to use a specific rom_dir with mame2010 (only), you can do that via retroarch via a core override: https://docs.libretro.com/guides/overrides/ if your launcher is launching straight into retroarch + mame2010_game_X, then it is passing the location of that game in the launch command: how either of these hook in with batocera/launch box I couldn't tell you, but they're launching retroarch so it should be possible to configure the above. |
|
Yeah, I wasn't clear on what it's actually achieving. I guess streamlining navigation through the MAME OSD? |
Use Casebackporting it allows MAME2010 to have the following which resolves to:
while a MAME (current version) declares the following rompath: resolving to:
path resolution differs on a per rom basis. hope this helps clarify the desired use case! |
why would you want to have mame2010 pointing to different rom/bios directories? the romsets for mame2010 are ~14 years older than current mame, for example, so the cross-over of compatible romsets will be pretty small. is that what you're attempting to do above (sharing i can see the utility of having a separate bios directory to the roms directory (eg, you want to isolate the bios files away from the game files - useful for some launchers as they might want to add the bios files as separate launchable entries - with that said, most launchers should have solved this problem with a 'hide' flag or whatever), however there's already a mechanism in retroarch for that: system_dir, which can be configured to a different path to rom_dir. mame2010 should retrieve bios files from system_dir. |
that was arbitrary. it isn’t what you or I would do personally but the edge case needs to work even if that person is inviting headaches :) to be fair, there also exists the user who might create merged bios files since they are very small. for CHDs, it definitely matters as some of the laserdisc CHDs are over 14GB each (cliffhgr, mach3, usvsthem, etc) and haven’t changed since 2010.
you got it - this is the primary use case. and I personally have experienced MAME2010 and MAME bios files getting clobbered in system_dir all the time so being able to have two separate bios directories (and rom directories) makes things a bit cleaner. |
good news ! core overrides should fix this for you. paraphrasing the link above: .chg (which i think is mame2010) stick that in your config dir like: /config//name-of-core.cfg or could fix it in os with sym links etc the problem with solving it another way is that libretro cores can’t accept arguments as explained above, so you’d need it to be a core option. but core options aren’t really good for free text. i believe you can have file paths in core options, but not N-paths. |
|
I appreciate you exploring other workarounds.
We went down this path but unfortunately MAME2010 ignores
if and when we backport |
that, imo, would be an issue worth solving, at least if anyone wants to maintain this old core ;) probably other mame cores implement system_directory for bios so you could check them. i recall doing something similar for https://github.com/libretro/mame2003-libretro - but i think that was just for samples and things of that nature, not bios files (tbh i would just merge my bios files into the game romsets themselves if i wanted to tidy up the content directory).
again, you can't pass any kind of argument to the core. you launch a libretro core via a frontend (typically) retroarch - they don't launch directly. i gave an example of a launch command above: #159 (comment) retroarch accepts arguments, but they're used by retroarch, not the underlying core (at least, not directly). you're not going to be able to add a new -foo argument to retroarch. so to get anything to the generated mame.ini, you'll need to go via core options, or i supppose allow it retrieve values from a user-generated mame.ini (but imo this is a bit antithetical to how libretro cores are supposed to work so wouldn't recommend that) |
one of the primary roles of Batocera Linux is to be middleware of sorts & the meat & potatoes of it is a config generator for all its components. (but even this is downplaying how powerful the distro is!) It generates a retroarchcustom.cfg on the launch of every core & found code to create a custom mame.ini & verified it passes arguments to the core. The official libretro documentation for MAME2010 does request bios files be put in the same directory as your ROMs so your hunch about still looking for someone to help assess the relative difficulty of backporting |
|
Ah, so you're not talking about an argument (something you pass to the executable via the launch command) but retrieving an ini file setting. Well you could certainly implement that - it's existing code so should be easy to reconnect, but you would just have to make sure it still respects the romdir set by retroarch (so whatever is in the ini is only supplementary) i still think it's a bit antithetical to how libretro cores should work - a completed libretro core wouldn't use the mame.ini at all - all configuration would be done via the api (retroarch.cfg / core options). However in unfinished/abandoned/archival curio cores like this one, I think it's fair enough to do whatever you want if you think it deserves the time. you should be able to locate the original mame2010 source code if you need deleted code. eg MAME 0.139 - https://archive.org/details/mame0139-official-source seems to be it |
actually the code is even closer - the https://github.com/libretro/mame the reason I’m asking for help is there was a rewrite from C to C++ and could use the input of someone who understands the code from an architectural level as to the feasibility of porting the -rompath code. |
The documentation in GitHub states the option exists:
mame2010-libretro/docs/config.txt
Lines 291 to 296 in 5f524dd
In reality, the option doesn’t appear to function after trying to put “rompath” into
ini/mame.ini:While I’m not an expert in MAME code, a casual look around does look like the -rompath code in the v0.265 core isn’t present in romload.c
I made an attempt to workaround the lack of a rompath in this Batocera Linux pull request but since a few corner cases are not covered and it symlinks nearly every zip under the sun on every rom boot, it’s kludgey and hardcoded at best (but it does become possible to put bios files in locations other than the directory the rom is found (eg. bios/mame2010) which keeps bios files separate from roms and also prevents clobbering with 0.265 bios files which has been a pain point)
I believe a reliable path forward is to backport the
-rompathoption to MAME2010 & would love input on if this straightforward (but considering it looks like there was a C to C++ rewrite that took place, perhaps it isn’t…)And for those who do not specify the
-rompathoption, MAME2010’s current rom search behavior remains unchanged - therefore, will not break any existing systems.The text was updated successfully, but these errors were encountered: