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

[Kevin M. <ke...@vr...>]

so a c interface on top of a c++ code base is a problem?

Can we put a COM interface on top of a C++ interface?

I'd rather support an XPCOM interface than a C one...


it would be nice to post binaries that work for everyone no matter what...  
i still think it is important to have a nice interface (opject oriented).

can you think of a compromise?

kevin

On Wed, 16 Jan 2002, Chad Austin wrote:

> > 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.
> 
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> 

-- 
@--@---@---@----@-----@------@------@-----@----@---@---@--@
Kevin Meinert                                  __  _   __  
http://www.vrac.iastate.edu/~kevn         \  ||  \| \ /  ` 
Virtual Reality Applications Center        \ ||.-'|--\\    
Howe Hall, Iowa State University, Ames Iowa \||  \|   \`__,
-----------------------------------------------------------