<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><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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>Actually, come to think of it, I don't think the current savegames are compatible with the original in any case. The first field of a savegame is, in the original, an Md5 (I think) of the executable itself, to ensure that different versions of the interpreter don't try to use each other's savegames. The ScumMVM engine also has it's own unique identifier for this field. So unless we changed this to hard-code the original interpreter's equivalent Md5 string, the savegames won't be cross-compatible.<br>
<br>Even then, there's a slight complication - there have been two major releases of the game - the original release, and the release with English voice pack support. I can't be sure, but I think the two versions had slightly different executables, and thus Md5 checksums. If that's the case, even if we try to hardcode for one of the Md5's, it would still only result in savegames that could be read by one version of the interpreter, and not the other.<br>
<br>Paul.<br>