Re: COM (or similar) in games

[Pierre Phaneuf <pp@ludusdesign.com>]

Bert Peers wrote:

> > > I ask that, because I was very interested in Mozilla's XPCOM, but it
> > > dependent on the NSPR (Netscape Portable Runtime), which I deemed too
> > > heavy to bring in a game... I was underway to make my own "XPCOM-Lite"
> > > for my gaming endeavors, but that might help me out... :-)
> > You might also want to take a look at what one of my CS members is doing.
> > He has taken the Crystal Space COM code and is now busy converting it to a
> > more general and full-featured COM library for Linux.
> 
> Hm, here's a question (not criticism !), will the end result not be too
> heavyweight?
> I mean, normally an SDK is the bottom layer of your project : unless
> it's a full
> framework, you just take your code and plug an SDK into it to get good
> rendering support (in this case).  However when it uses COM, and COM is
> not provided by the OS, there'll have to be a layer which overlooks
> everything.  Wouldn't that turn CS into a really big thing to deal with
> if you want to use it into your code ?...
> 
> Ending up with XPCom again so to speak.

Normally, what COM does doesn't require much resource to do *during* the
life of objects. The problem I had with XPCOM is that it needed NSPR and
other stuff (I think it also needed a Berkeley DB library), which goes
for a huge library to link in, considering NSPR isn't quite standard on
Linux (or on anything else) and that we'd have to ship it along... If I
remember, all it was using it for was memory management and hash tables!

A COM system done the right way will (should) not incur runtime speed
overhead more than C++ virtual methods would, for example.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
.