[Scummvm-devel] Moving and merging image-related code

Filippos Karapetis bluegr at gmail.com
Wed Feb 2 20:59:07 CET 2011


Actually, the problem with libpng is that it's a required library. i.e. if
we sit back and
think which are the bare-bones necessary libraries for compiling ScummVM,
it's
just libsdl... and nothing else. libmad, libogg, libflac and libtheora are
all optional.
If they're not included, a feature is missing. But libpng is the only
exception here: it
is required in order to play Broken Sword 2.5.

The usage of libpng in this case lies in the same category as libjpeg in
mohawk,
which makes extensive usage of JPEGs. But with mohawk we rolled our own JPEG
reader, whereas with sword25 we added libpng. Isn't that a bit
contradicting? And
since the PNG reader is working, what is the problem with it? Yes, it won't
be as
optimized as libpng, but that's not its point. We don't need all of the
features that
libpng provides, as ScummVM isn't an image viewing program. E.g. we don't
need
to read the text blocks off a PNG image, or its embedded ICC profile, or its
histogram. The point is to have a bare-bones PNG reader code, useful for
games,
not an image viewer application. So again, I ask: why should we keep PNG as
a
required library for features that we don't need?

Regards
Filippos

On Wed, Feb 2, 2011 at 9:49 PM, Willem Jan Palenstijn <wjp at usecode.org>wrote:

> On Wed, Feb 02, 2011 at 09:13:01PM +0200, Filippos Karapetis wrote:
> > The discussion boils to "do we want to have our own code for handling
> file
> > formats, or use external libraries?"
>
> I don't think that's what the discussion boils down to at all, and see no
> reason why we should treat everything the same. I think we should ask this
> question on a case-by-case basis, based on things like code size,
> maintainability, portability, performance.
>
> At this point there seems to be no concrete gain to dumping libpng, since
> the
> platforms where we use it for sword25 seem to have no issues with libpng?
>
> Unless it's an issue on the PSP where we also seem to use libpng?
>
>
> -Willem Jan
>
>
>
> > On Wed, Feb 2, 2011 at 8:54 PM, Johannes Schickel <lordhoto at scummvm.org
> >wrote:
> >
> > >  On 02/02/2011 07:04 PM, Filippos Karapetis wrote:
> > >
> > >
> > >  > png.*
> > >> As I expressed on IRC, I disagreed with having our own PNG decoder and
> > >> I would much rather see libpng used. The dependency on libpng is not
> > >> something that would be ridiculous to depend on and we will most
> > >> likely never equal the speed of libpng.
> > >
> > >
> > >  Why? We don't need all of the functionality of libpng, and it's not
> like
> > > we absolutely
> > > need top speed when loading an image. We have our own code for all the
> > > other
> > > image formats, why is it so wrong in having our own code for PNG as
> well?
> > > One
> > > less dependency is a good thing in my eyes, especially if it allows us
> to
> > > port the
> > > game in other platforms and not worry about libpng availability there.
> So,
> > > I personally
> > > don't understand why libpng is better for our needs.
> > >
> > >
> > >
> > > Uhm, don't we already use libpng for PNG loading in Sword2.5 and the
> PSP
> > > backend? I rather thought this was about moving the decoders to its own
> > > subdirectories (+ unifying the API) instead of duplicating the code and
> not
> > > about how to implement the loader?
> > >
> > > Ahh I see Md5 implemented a custom PNG loader... well I am not too
> happy
> > > about that. I do not think libpng is a library which is hard to port
> (you
> > > can proof me wrong here though), also why should we spend time writing
> a
> > > good (i.e. consider speed, memory consumption, fail safenes, etc.) PNG
> > > loader/(encoder?) implementation, when we can just use libpng? That
> seems
> > > wasted time we could rather put into improving our other code IMHO.
> > > Personally I am not sure why we do not use libjpeg for JPG loading...
> > >
> > > Also we should consider the target systems of the engines we use those
> > > image loaders for, just take Sword2.5, on which devices are we likely
> to get
> > > it to run and which device of these will have any problem with a libpng
> > > depandancy?
> > >
> > > All this seems premature optimization to me, if we have a stable image
> > > decoding API we can exchange the implementation when we have any
> problems
> > > later on anyway, so why do we now want to implement every standard
> image
> > > format loader out there ourselves? Just to not depend on a library
> which is
> > > (probably) pretty easy to use on most of our target systems? That
> reasoning
> > > seems strange to me....
> > >
> > > Since you mention loading speed: Didn't we have some problems with the
> JPG
> > > loader being slow and thus we needed to optimize it (or still do? I
> remember
> > > something about that and if anyone would remember the details I would
> be
> > > most pleased if he / she could clarify that here.
> > >
> > > // Johannes
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > > Finally, a world-class log management solution at an even better
> > > price-free!
> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > > February 28th, so secure your free ArcSight Logger TODAY!
> > > http://p.sf.net/sfu/arcsight-sfd2d
> > > _______________________________________________
> > > Scummvm-devel mailing list
> > > Scummvm-devel at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/scummvm-devel
> > >
> > >
> >
> >
> > --
> > "Experience is the name every one gives to their mistakes" - Oscar Wilde
>
> >
> ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better
> price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Scummvm-devel mailing list
> > Scummvm-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>


-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110202/89565f4b/attachment.html>


More information about the Scummvm-devel mailing list