[isugamedev-devel] Re: Re[3] image library

[Chad A. <ae...@ae...>]

> I'd prefer a c API that wraps the C++ one, does it really matter?  the C
> api would be the one to avoid IMHO, so why build around it?  besides,
> dllexport will export C++, so it isn't a big deal.  if you need image
> plugins, I would write C wrappers that allow you to search for the C
> symbols for the load method.  Otherwise, why not C++?

As I've said before, it is a big deal because there is no standard C++ ABI
(except for the ia64 one, which isn't even really relevant yet).  "What does
that mean?"  It means if I create a DLL in VC++, it won't work in gcc or Borland
C++ or any other compiler with a different way of representing objects.  "So? 
Everybody uses VC++ anyway."  True, but what if VS .NET has a different ABI (I
haven't tested this, but it's a possibility.  gcc 3.0 and 2.9x have different
the vtable layouts) and people start upgrading?  Programs that are using the DLL
will just start crashing.  Also, VC++ has different allocators for debug and
release builds.  If a release build does something like ...

Object* object = CreateObject();  // object factory implemented in debug DLL
delete object;

... you're almost assured a crash.

I guess my point is, Microsoft enforces two ABIs in Windows:  C and COM.  We
should comply with at least one of them.  (preferably C, as it's simpler)

The way Audiere keeps a solid internal design *and* a nice external C++ API is
on the inside having things like:

ADR_CONTEXT ADR_CALL AdrCreateContext() {
  return (ADR_CALL)(new InternalContext);
}

...

ADR_STREAM ADR_CALL AdrOpenStream(ADR_CONTEXT c, const char* filename) {
  Context* context = (ADR_CONTEXT)c;
  return (ADR_STREAM)(context->openStream(filename));
}

and on the outside:

inline Context* CreateContext() {
  ADR_CONTEXT c = AdrCreateContext();
  return (c ? new Context(c) : 0);
};

class Context {
private:
  Context(ADR_CONTEXT c) : m_c(c) { }
public:
  ~Context() { AdrDestroyContext(m_c); }
  Stream* openStream(const char* filename) {
    ADR_STREAM s = AdrOpenStream(m_c, filename);
    return (s ? new Stream(s) : 0);
  }
}

> PNG is good.  JPG is bad (lossy) but good at compression (nice) I'd avoid
> it so that the game looks good, but if you want to make a tiny little
> demo it might be good to have.  PCX is good.

JPEG isn't bad.  It just has a different usage domain.  Photographic PNGs are
HUGE, and high-quality JPEGs are very useful for prerendered backgrounds and
such.

> a separate SF project for it?  I'm ok with that.  are we sure there isn't
> ANYTHING else out there?  The strong points of my lib is the C++ I
> think...

You'd really think there would be other libs, but the only major one I've seen
is openil (devil), and it doesn't impress me at all.  I spent a lot of time
looking on SourceForge and freshmeat, and haven't found much.  I guess there's
FreeImage, but it's too...  Win32...  (there is a Linux port, but it doesn't use
autoconf/automake and thus requires makefile tweaking...  ewww)

I guess there are a lot of image libraries, but none that satisfy all of the
requirements I have.

> I think I do simple conversions already which can be migrated from the
> Image class to a util lib.  simple as in 24 to 32bit and vice versa.

Sounds good to me.

Just a little related note:

libpng is a pain in the ass because if you just want to load any PNG image into
an RGBA buffer, you have to explicitly handle each bit depth and every possible
transparency setting (transparent palette entries, palette entries with alpha,
separate alpha buffers, etc.).  libmg can load PNGs too, but handles that for
you.  You specify the format you want your image data in, and that's what it
delivers.