[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: COM (or similar) in games
Bert Peers wrote:
> Jorrit Tyberghein 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
> 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 ?...
The COM stuff is really very very small. In CS all sources which implement
the COM layers are only 73K (including comments). And this 73K serves for
the native COM support functions, the dynamic emulation layer for COM and
the static emulation layer for COM. Any given port will only use one of these
three systems at the same time (the rest will not be included because it is in
Also the run-time overhead is really very small. Actually COM is nothing more
than a set of guidelines enforced by a lot of C macro definitions.
Jorrit.Tyberghein@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM
The chieftain had been turned into a pumpkin although, in accordance with
the rules of universal humour, he still had his hat on.
-- (Terry Pratchett, Lords and Ladies)