Re: [Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Am Sat, 6 Jan 2007 20:54:16 +0100 schrieb Jan Reucker <slo...@gm...>:

Some additional thoughts:

> - define a unified API for the raw loaders, maybe using
>   some kind of piImage object to store the raw image data and some
>   additional information (width, height, pixel format)

This approach would be similar to ssgTexture. There's one class
for all texture formats. The ctor can be called with any file
type and hands it over to a non-class loader mechanism, which in
turn calls one of many non-class loaders to get the raw pixel
data and some additional info.

On the other hand we could define a piImage base class and a set
of derived classes, one for each file type. Then we'd need a
non-class loader function that uses one of the derived classes
to load the image and then returns a piImage* base pointer to the
caller. To the user, this is similar to ssgLoad().

Any pro's and con's? While the first one seems to be closer to
the existing code in SSG, the second might be more C++ish. And
it might be easier to handle a loader failure: you can simply
return a NULL pointer instead of a valid piImage*, while in
the first case you have to deal with a failed constructor so you
must provide some kind of "default image" like ssgTexture does.
Of course you have the same problem internally when one of
the piImage subclasses fails (e.g. because of a corrupted image
file), but it's hidden from the user.

Kind regards,
Jan R.


-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de