Open YoshiRulz opened 1 year ago
Note that these issues only apply if a match isn't found in the gamedb anyways (so bad dumps, hacks, homebrew, or systems where the gamedb is not available).
gamedb should be optional (#2939) and that still leaves polyglots unaccounted for
see also #969, #2889
Detection can be a list of
IFileTypeDetector
s (something likeFunc<byte[], VSystemID>
) run on the rom in order (for small roms, can run in parallel with one copy of the rom per thread). We have a bit of this already for disc images and ZX Spectrum / Apple II. edit:DiscIdentifier
uses file extensions too -- The ones which fail faster (e.g. magic bytes) should be run first. Not sure what should happen if multiple match, maybe we'll need to manually deprioritise an implementor that's prone to false positives. I don't think the current system has anything like this as it uses file extensions—obviously mutually-exclusive. We could allow the implementators to return a list of multiple file types (something likeFunc<byte[], VSystemID[]>
) for [polyglots](https://en.wikipedia.org/wiki/Polyglot(computing)). Rather than system ID, we could use MIME types. On my Manjaro machine, I'm seeing most given unique types byfile
/mimetype
:application/x-atari-2600-rom
,application/x-fds-disk
,application/x-gba-rom
,application/x-n64-rom
,application/x-pc-engine-rom
, etc., notably home PCs seem to be a problem. I'm not suggesting we delegate file type detection tofile
(libmagic
) though, especially because it will be a pain to bundle it on Windows. IANA is the authority for MIME types.also need to make
MAMEMachineDB.IsMAMEMachine
override opt-in