Every now and then we get reports on problems with transferring savegames from platform which haz zLib support to platform which does not or has a build which has it disabled for some reason.
Instead of stating that save is in invalid format we should (a) in scumm engine show that savegame "GZip compressed (uncompress it manually)". And SaveFileManager should report it and appropriate message should be shown for all other engines.
If there will be some standard code, then, perhaps some standard wrapper function should be added to OSystem, or typical code snippet added to Engines HOWTO on our Wiki.
Logged In: YES
user_id=12935
Originator: NO
I think that just saying "uncompress it" might not be enough for many users. So, we should definitely add a section to the README (and/or FAQ) about the issue. Then when the user tries to load such a savegame, display a message stating that compressed savegames aren't supported by this build, and that one should consult the README/FAQ for further instructions.
But really the best "fix" for this situation would be if if *all* our ports supported compressed savegames. So, I wonder, which ports do not support zlib compressed savegames, and why? And is there anything we can do to fix them?
Logged In: YES
user_id=12935
Originator: NO
Side note: A regular gzip compressed file can be recongized by it's 0x1F8B header. So detectiong them should be easy enough.
But I still think it would be best if *all* our ports supported gzip compressed savegames. Unfortunately, currently all those with custom save managers may not support them ... :-/. I guess in retrospect, implementing them using the gzread/gzwrite API wasn't so clever after all..
One idea would be to rewrite the savegame compression code: Instead of leaving this up to backends to implement, add the compression code at a higher level. This can be done by inserting a "meta" savefilemanager, which wraps around the savefile manager provided by the backend. This way, we get uniform compression on all systems with minimal effort (other than linking in zlib).
Alas, that may not be entierly trivial, as the gzread APIs seem to require a FILE descriptor...