[Scummvm-devel] cost of palette changes

[Max Horn]

Am 29.06.2010 um 09:12 schrieb Robert Špalek:

[...]

> done.  if you don't like some of my changes, feel free to tell me and I'd be happy to fix it. 
> 
> I have tested ScummVM with disabled zlib and it works fine except for loading and saving games.  the latter doesn't work, because the usage of compression is hard-coded into backends/saves/default/default-saves.cpp's methods openFor{Loading,Saving}(), which unconditionally use Common::wrapCompressed{Read,Write}Stream() without fallback.  as a result of that, ScummVM cannot load or save games when zlib is not linked in.
> 
> shall I add a test there and use raw uncompressed streams when zlib is not available?  this should only make things better, because on such installations loading/saving could never have worked in the first place.

Huh? It definitely used to work for many years.  mmon::wrapCompressed{Read,Write}Stream returns the original stream if zlib is not available, so saving should work just fine -- at least it definitely used to do so. Loading uncompressed saves should work, too; of course it cannot possible load compressed saves, no surprise there :).

So if this fails now, it is a regression and should be fixed. Weird one, though... 

>  the only problem I see is when someone copies an uncompressed savegame to a different installation, where it is attempted to be loaded with decompression.  if we wanna address compatibility of savegames with different compression modes, then we have a little problem, because we would have to depend on reliable testing whether a given input stream is compressed or not.

You mean like the test wrapCompressedReadStream already performs? :)

Bye,
Max