<div class="gmail_quote">On Thu, Feb 3, 2011 at 7:44 AM, John Willis <span dir="ltr"><<a href="mailto:John.Willis@distant-earth.com">John.Willis@distant-earth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<snip protracted debate> ;)<br>
<br>
I hate to say it but I have to fall on the side of keeping code 'in tree' if<br>
said code is manageable and making the judgement call when it becomes<br>
unmanageable and is better served with libraries. I am not devote on either<br>
side mind you.<br></blockquote><div><br>I too fall on the side of making it part of core. As has been pointed out, we don't need all the functionality of libpng, and I prefer keeping the number of external libraries needed to be installed to a minimum. Everytime a library is added, it's just that much more future developers will have to worry about having installed in order to get ScummVM to compile.<br>
<br>In fact, there's no reason why we couldn't completely drop libpng support for encoding savegame thumbnails, and still support loading original interpreter savegames. Since it's all about how thumbnails get encoded for new savegames, and particularly since the thumbnail is stored at the very end of the savegame file anyway, there's no reason why the thumbnail code couldn't be converted over, and savegame listing still be able to decode either a PNG thumbnail or a ScummVM thumbnail.<br>
</div></div><br>Paul.<br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>