Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|03265||Interface||Minor||Always||Jun 15, 2009, 20:50||Jul 20, 2017, 03:49|
|Tester||Heihachi_73||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||Resolution||No change required||OS||Windows XP/Vista/7 32-bit|
|Version||0.132||Fixed in Version||Build||Normal|
|Summary||03265: Games with wrong CRCs don't load at all using MAME's minimal UI|
Any game which fails loading by CRC, also fails when attempting to run from MAME's internal menu. The 'bad' games still run from the command line as normal. Came across this initially when testing out a new aristmk4.c game by simply swapping the ROMs instead of going through downloading the source, adding it and recompiling. Game booted perfectly and went into its error mode (as with eforest), but didn't even attempt to load at all through the interface.
This is most likely related to Bug 03264, as the 'missing ROM' message comes up in the same manner, even though ROMs are physically there (file names match).
|Steps To Reproduce||Hack a game, run it perfectly in MAME from cmd, then watch it fail when you try to load it in MAME's menu instead, even though it's still running right behind the menu!|
|Additional Information||Tekken 2 screenshot as proof (using pre-122u2 wave ROM which fails audit).|
|Affected Sets / Systems|
t2fail.png (81,461 bytes) Jun 15, 2009, 20:50
|There are no relationsihp linked to this issue.|
Jun 15, 2009, 22:11
|I'm pretty sure this is by design. It's meant to be a *simple* frontend, if anything is wrong / missing it won't work.|
Jun 15, 2009, 22:24
|I agree. Nevertheless, I'll leave it for Aaron to give an official + or - on this.|
Jul 20, 2017, 03:49
Yeah, I think this can be closed as being by design. There are a couple of of aspects to consider.
Firstly, on the design side, allowing the system to run with bad ROM images is liable to cause bad behaviour leading to false bug reports. Thus, running with bad ROM images is considered an "advanced" operation, requiring the user to use the command line. This makes running with bad ROMs less of a "casual" operation.
Secondly, the internal UI relies on the audit class to check the status of a ROM. There isn't a huge amount of detain provided back in the result. The internal UI code just checks whether the result is "good" or "best available" and launches the system if it is. Changing the audit class API to distinguish between "missing files", "files present but bad checksum", "files present but wrong size", etc. would complicate all uses of it.