Re:How I Dumped an Arcade Game for MAME
by derefr on Sunday October 30, 2022 @01:10PM
(#33396333)
> when if you actually spent a few minutes actually using MAME
First, to be petulant for a bit: Why would I? There's no arcade game I have ever had the desire to play (didn't grow up in the right era to have nostalgia for them); and so, despite tinkering with emulators / contributing to emulator development in general, I've never had any reason to use MAME.
The only interest I have in MAME is technological; and in that respect, I was trusting the explanation of the GP poster (whose authoritative phrasing implied them to be a contributor to the MAME project.) So when they said:
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect
— which strongly suggests not "allowing you to proceed anyway" — well, why wouldn't I believe that that's what happens?
But now, to actually rebut the spirit of this argument: how would you imagine I would learn this from MAME in only "a few minutes", without having a bad dump on hand to provide MAME with? As, presumably, you'd never see this dialog if you don't specifically trigger it by handing the emulator a bad dump as a ROM-chip asset for a game and then telling it to try running it.
Should I be downloading good dumps and then POKEing them in a hex editor to find out what happens? That doesn't sound like "a few minutes." Sounds more like something you'd only know if you're very involved indeed in MAME emulation, either deeply, on the game-archiving side; or for a long time — at least a decade or more — since back when sites archiving ROM dumps didn't care about the verified-ness of said dumps.
Going off the StackExchange thread linked in a sibling reply here, there seems to be no actual click-through in the UI version of MAME; rather, the way you are enabled to "run the game anyway" is by running the game from the command line — not something you'd be doing in your first few minutes spent tinkering around with MAME. (Thus, presumably, the GP's phrasing: "prevents people from easily using [...]".) Meaning that this is (much) less discoverable than you're implying; and, in fact, that my original suggestion — that this should be made to work more like a click-through browser security warning on the UI side, rather than being a full-stop blocker — is entirely a plausible and warranted change.
> You’d also know that dumping the database in MAME is very straightforward.
Would I? Again, sounds like something you'd only know if you're intimately involved in the MAME ecosystem.
Given that I spend my day professionally figuring out how to make production deployments out of undocumented alpha-quality software, I am able to educated-guess my way through Google, and then the MAME wiki, to finding this CLI subcommand — https://docs.mamedev.org/commandline/commandline-all.html#ma... — but that's not something I ever would have run into by just poking around.
> The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
When the database is independent of the emulator, but there is only one such database that everyone agrees to use, that is also "a single source of truth." The database is effectively upstream of the emulator, like a library. The single source of truth is the canonical version at some URL pointed at by some RSS feed; the emulator's local copy is a mere cache, and one that would be invalidated by any change to the upstream database.
More importantly, though, is the practicality of the two setups.
A standalone database — or even a database living as a data file inside a release of a project — is just data, and therefore able to be extracted + transformed by anyone with the right file-encoding library to work with that data.
A database that's burned into the code of a project, where you must run the program itself with some flags to get the DB out, means that for any downstream project that wants to track the database for its own releases, this downstream project must acquire a copy of, and then run the upstream project, within its own build infrastructure. Which, for projects that would otherwise be simple CLI utilities, can massively bloat the build dependencies required of the project. (Some romset-verifier tool might just need libc to build; but for the fact that it needs to run MAME to extract its DB, and so now requires every library MAME requires to run, to build.)
First, to be petulant for a bit: Why would I? There's no arcade game I have ever had the desire to play (didn't grow up in the right era to have nostalgia for them); and so, despite tinkering with emulators / contributing to emulator development in general, I've never had any reason to use MAME.
The only interest I have in MAME is technological; and in that respect, I was trusting the explanation of the GP poster (whose authoritative phrasing implied them to be a contributor to the MAME project.) So when they said:
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect
— which strongly suggests not "allowing you to proceed anyway" — well, why wouldn't I believe that that's what happens?
But now, to actually rebut the spirit of this argument: how would you imagine I would learn this from MAME in only "a few minutes", without having a bad dump on hand to provide MAME with? As, presumably, you'd never see this dialog if you don't specifically trigger it by handing the emulator a bad dump as a ROM-chip asset for a game and then telling it to try running it.
Should I be downloading good dumps and then POKEing them in a hex editor to find out what happens? That doesn't sound like "a few minutes." Sounds more like something you'd only know if you're very involved indeed in MAME emulation, either deeply, on the game-archiving side; or for a long time — at least a decade or more — since back when sites archiving ROM dumps didn't care about the verified-ness of said dumps.
Going off the StackExchange thread linked in a sibling reply here, there seems to be no actual click-through in the UI version of MAME; rather, the way you are enabled to "run the game anyway" is by running the game from the command line — not something you'd be doing in your first few minutes spent tinkering around with MAME. (Thus, presumably, the GP's phrasing: "prevents people from easily using [...]".) Meaning that this is (much) less discoverable than you're implying; and, in fact, that my original suggestion — that this should be made to work more like a click-through browser security warning on the UI side, rather than being a full-stop blocker — is entirely a plausible and warranted change.
> You’d also know that dumping the database in MAME is very straightforward.
Would I? Again, sounds like something you'd only know if you're intimately involved in the MAME ecosystem.
Given that I spend my day professionally figuring out how to make production deployments out of undocumented alpha-quality software, I am able to educated-guess my way through Google, and then the MAME wiki, to finding this CLI subcommand — https://docs.mamedev.org/commandline/commandline-all.html#ma... — but that's not something I ever would have run into by just poking around.
> The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
When the database is independent of the emulator, but there is only one such database that everyone agrees to use, that is also "a single source of truth." The database is effectively upstream of the emulator, like a library. The single source of truth is the canonical version at some URL pointed at by some RSS feed; the emulator's local copy is a mere cache, and one that would be invalidated by any change to the upstream database.
More importantly, though, is the practicality of the two setups.
A standalone database — or even a database living as a data file inside a release of a project — is just data, and therefore able to be extracted + transformed by anyone with the right file-encoding library to work with that data.
A database that's burned into the code of a project, where you must run the program itself with some flags to get the DB out, means that for any downstream project that wants to track the database for its own releases, this downstream project must acquire a copy of, and then run the upstream project, within its own build infrastructure. Which, for projects that would otherwise be simple CLI utilities, can massively bloat the build dependencies required of the project. (Some romset-verifier tool might just need libc to build; but for the fact that it needs to run MAME to extract its DB, and so now requires every library MAME requires to run, to build.)