<div class="gmail_quote">On Thu, Feb 3, 2011 at 2:19 PM, Matthew Hoops <span dir="ltr"><<a href="mailto:clone2727@gmail.com">clone2727@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Feb 2, 2011 at 9:43 PM, Paul Gilbert <<a href="mailto:paulfgilbert@gmail.com">paulfgilbert@gmail.com</a>> wrote:<br>
> In fact, there's no reason why we couldn't completely drop libpng support<br>
> for encoding savegame thumbnails, and still support loading original<br>
> interpreter savegames. Since it's all about how thumbnails get encoded for<br>
> new savegames, and particularly since the thumbnail is stored at the very<br>
> end of the savegame file anyway, there's no reason why the thumbnail code<br>
> couldn't be converted over, and savegame listing still be able to decode<br>
> either a PNG thumbnail or a ScummVM thumbnail.<br>
</div>Yes, there is a reason to keep encoding support: We'd break<br>
compatibility with the saved games. How would the original interpreter<br>
be able to load new saved games? (Unless there's a chance the original<br>
is robust enough to know not to load the PNG if it's not found, in<br>
which case I take it back ;))<br>
<br>
-Matt<br>
</blockquote></div><br>I'm not really sure that compatibility of new savegames back to the original interpreter is all that important, but even then, I'm confident that it would be fine. Back when we were converting the original source code to a ScummVM module, for a while we had the savegame list being loaded without thumbnails. The engine is quite happy to simply display a black box if no thumbnail is available/found.<br>
<br>Paul.<br>