Previous  1, 2, 3  Next
Mining MAME's game data 
Author Message
User avatar

Joined: 2014-09-27 09:27
Posts: 1222
 Re: Mining MAME's game data
Screwtape wrote:
If you click through to the source-code Caedhros linked and search for "kde_30a.11e", you'll see it's part of the game "kod", while the chunk above describes "kodu". There's also "kodr1", "kodj" and "kodja" which has the comment "Note that this set is equivalent to kodj, but each 4Mbit EPROM is replaced by 4 1Mbit EPROMs." I'm guessing that's regions-and-prototypes again.


Yep, they're from the (World) version. How they came in my kodu.zip, I dunno. Seems that MAME grants db recognition to archives with extraneous files in it. Which means that someone dicked around and accidentally put them in there, and MAME is foolishly ignoring it so it never got caught.

Now I'm wondering how higan handles this, I've never tried putting garbage files in a game folder...

_________________
GB/GBA Buglist for Higan 103r26


2017-10-02 10:06
User avatar

Joined: 2014-10-29 21:24
Posts: 1814
Location: People's Republic of America
 Re: Mining MAME's game data
higan also ignores extraneous junk in game folders. You could put "manual.pdf" into a cartridge folder if you want. However, if any of them are named "data.rom", "*.program.rom", or "*.data.rom", icarus will capture them into the SHA256 hash and throw off manifest generation.

_________________
bsnes-mcfly: A port of the Qt GUI from v073 to v106.
nSide: A higan fork w/NES boards and peripherals and Sonic & Knuckles Lock-On.
Dragon Quest I & II RPGOne Beran Inn bugfix


2017-10-02 13:51
User avatar

Joined: 2014-09-25 13:52
Posts: 8294
 Re: Mining MAME's game data
icarus having to use pattern matching to rebuild the ROMs is definitely the sketchiest part of dynamic manifest generation, but it works for all cases on all systems, so ... whatever.

Just saying though, don't put any *.rom files in there you don't want to be considered part of the ROM, whether icarus currently matches it or not.

_________________
What the hell's going on? Can someone tell me please?
Why I'm switching faster than the channels on TV.
I'm black, then I'm white. No, something isn't right.
My enemy's invisible, I don't know how to fight.


2017-10-02 14:01

Joined: 2014-09-27 09:48
Posts: 100
 Re: Mining MAME's game data
Mames file loader is both strict and lenient at the same time. When you load for example king of dragons us, it will start by searching kodu.zip(or. 7z, or an uncompressed kodu folder in the rom folder) , as that is the game's assigned short name. If it can't find all the required files it will then search kod.zip as that is the parent shortname.

In an ideal setup, with kodu being a clone set, the zip should only contain files that are not used in the parent set, which I think in its case is only the 68k program roms. Mame will load the program there, and pull the graphics and sound from the parent zip. However mame will load it however it can find it.

On a related note, the file names inside don't actually matter. Mame loads by checksum first, so it will find the files it needs. If you don't have the right file, then it will search by the assigned filenames, and load that and give you a checksum warning. You can use this to play with rom hacks or to experiment with graphics changes etc.

The clrmamepro tool uses the rom definition pulled from mame and ensures that your file structure matches the definition exactly.


2017-10-02 15:25
User avatar

Joined: 2014-09-27 09:27
Posts: 1222
 Re: Mining MAME's game data
Caedhros wrote:
The clrmamepro tool uses the rom definition pulled from mame and ensures that your file structure matches the definition exactly.


Yeah that's... messed up. To me, it doesn't matter if the rom tool checks filenames, but it definitely matters if the emulator itself does, because it's the emulator that's defining the format. The tool is just a optional aide to mass verify since emulators can only load-time verify (generally).

And higan and mame should reject containers with alien files in them, it's the only way to prevent garbage from worming its way into distributed archives. I can seriously put a hundred text files or adverts in a container it still works? Ehhh why.

_________________
GB/GBA Buglist for Higan 103r26


2017-10-03 08:47
User avatar

Joined: 2014-09-25 13:57
Posts: 2144
Location: Australia
 Re: Mining MAME's game data
Because it seems likely that somebody will want to add more data to a game folder (box art, cart art, manual scans, PCB scans, provenance, ...) and it's impractical to try and envision and standardize all that stuff up front.

_________________
Maintainer of the unofficial git repository for higan.

The ending of the words is ALMSIVI.


2017-10-03 08:57
User avatar

Joined: 2014-09-27 09:22
Posts: 5157
Location: A chair.
 Re: Mining MAME's game data
Screwtape wrote:
Because it seems likely that somebody will want to add more data to a game folder (box art, cart art, manual scans, PCB scans, provenance, ...) and it's impractical to try and envision and standardize all that stuff up front.

Or a revision to the standard will occur.
Quick example: Should a non-MSU-aware emulator reject anything with msu.rom?

_________________
Just in case you thought something could EVER be straightforward, and needed someone to dash your hopes across the rocky shoals of harsh reality.

; write !!!


2017-10-03 09:00
User avatar

Joined: 2014-09-27 09:27
Posts: 1222
 Re: Mining MAME's game data
Screwtape wrote:
Because it seems likely that somebody will want to add more data to a game folder (box art, cart art, manual scans, PCB scans, provenance, ...) and it's impractical to try and envision and standardize all that stuff up front.


Store it elsewhere? Create a different extension that relaxes container restrictions (like .sfcpkg).

Either one sounds better than just allowing anything in containers so long as the emulator finds what it wants. Almost sounds similar to how copier headers persisted. If you run the game despite it, they circulate with them.

_________________
GB/GBA Buglist for Higan 103r26


2017-10-03 12:17

Joined: 2014-09-27 09:48
Posts: 100
 Re: Mining MAME's game data
In mame's case, being flexible with what is in the container is by design. Because of the way that parent and clone sets can share files, excluding files would get messy. A clone set can contain all the required files and not need the parent zip at all, or it can be just the different files for it and load shared files from the parent zip, or even put all files for parents and clones into a single zip named for the parent set.

Clrmamepro is often ran after a mame version update just to make sure an older rom collection is suitable for the new version, and will remove unnecessary files based on which rom collection you prefer (split, merged, etc)


2017-10-03 13:23
User avatar

Joined: 2014-09-25 13:52
Posts: 8294
 Re: Mining MAME's game data
FitzRoy wrote:
Either one sounds better than just allowing anything in containers so long as the emulator finds what it wants. Almost sounds similar to how copier headers persisted. If you run the game despite it, they circulate with them.


If only there were a format that contained only the ROM data that you couldn't add anything else to, that had to be in a fixed order so there was only one SHA256 per game ...

But look on the bright side, at least everyone stopped doing file_id.diz :)

_________________
What the hell's going on? Can someone tell me please?
Why I'm switching faster than the channels on TV.
I'm black, then I'm white. No, something isn't right.
My enemy's invisible, I don't know how to fight.


2017-10-03 14:26
Previous  1, 2, 3  Next