#9149 closed patch
SCUMM: autodetection for diskimage contents
| Reported by: | SF/tobigun | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
At the moment, ScummVM checks MD5 hashes only for the C64 .d64 or Apple .dsk disk-image containers but not for its contents. This is inconvenient as ScummVM is also able to handle the unpacked LFL game data. So those LFLs are not detected at the moment. In addition ScummVM might not recognize the game correctly if the disk directory was changed or if a savegame was saved on the disk (I remember that some people used floppy hole punchers to make the floppies writeable but I don't know if saving a savegame destroyed the game date).
The patch just calculates MD5 hashes for the 00.LFL files even if just a disk-image is present, so there is no need to add two MD5 hashes for each version. There were five MD5 hashes for the C64 versions before (two English, two German and one Italian). I already added the hashes for my two German versions.
It would be cleaner if the SearchMan.addDirectory() and SearchMan.remove() calls could be removed somehow, but File::open() which is called by ScummDiskImage requires the path of the two disk images to be registered in the SearchManager.
Maybe you like this patch. If not, maybe someone can use this as a base for a better approach.
Ticket imported from: #2971742. Ticket imported from: patches/1254.
Attachments (1)
Change History (6)
by , 15 years ago
| Attachment: | autodetect_diskimg.patch added |
|---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Summary: | Scumm: autodetection for diskimage contents → SCUMM: autodetection for diskimage contents |
|---|
comment:3 by , 15 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:4 by , 15 years ago
Excellent! I added NES bundle handling and committed the patch, properly updating md5scumm.txt file
comment:5 by , 6 years ago
| Component: | → Engine: SCUMM |
|---|
I really like the idea of this patch, as described. Sounds cool and like the "right thing" to do. That said, I haven't yet had a chance to look at the implementation, sorry :-).