[Scummvm-devel] cost of palette changes

[Robert Špalek]

On Mon, Jun 28, 2010 at 11:40 PM, Robert Špalek <rspalek at gmail.com> wrote:

> On Mon, Jun 28, 2010 at 3:51 PM, Robert Špalek <rspalek at gmail.com> wrote:
>
>> On Mon, Jun 28, 2010 at 2:37 PM, Max Horn <max at quendi.de> wrote:
>>
>>> True, but somebody *g* could rewrite it to support uncompressed archives
>>> when zlib is not available.
>>>
>>> I will look at it.  it should be very simple, (in theory) essentially
>> moving the #ifdef's from the top level into inside of the functions.
>>
>> 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.
 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.

-- 
Robert Špalek <rspalek at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20100629/9a2e5440/attachment.html>