RE: [GD-General] DLLs for game objects

[Brian H. <ho...@py...>]

On Tue, 25 Mar 2003 19:12:44 -0800, Tom Hubina wrote:
>At 05:40 PM 3/25/2003, you wrote:
>I think that pretty much the same could be said for C#, and I=
 happen
>to like the syntax better ;) Objective-C, Java, and C# are all=
 good
>dynamic languages that have their own individual problems.

<insert religious reasons why I hate C#>

>C++ is definitely a problem with DLLs ... but even straight C=
 has
>problems when you're passing around dynamically allocated=
 memory
>between DLL and EXE, or multiple DLLs. 

There will ALWAYS be problems when you have undisciplined or=
 sloppy 
programmers.  The important thing is finding the right balance 
between the two.  Laying down a real concrete policy up front is=
 the 
first step to avoiding any problems.

In fact, if you don't have a concrete policy on all memory 
management, you're probably pretty much asking for a world of=
 pain no 
matter what language or operating system you're running on.

>I don't think your Quake example applicable to this discussion=
 given
>the very limited interactions you describe between components=
 that

That's my point -- because Quake defined very limited=
 interactions, 
it's completely feasible.  If your interactions are encapsulated=
 into 
a pair of import and export callback tables, you greatly minimize=
 the 
chance of things exploding.

Since the returned values from the DLLs should be opaque pointers=
 or, 
at the worst, pointers to common headers, then the ONLY place=
 you'd 
have to really worry about things is freeing the actual object 
returned from the DLL.  That's it, and I think that's completely=
 
manageable.

>This works as long as each monster is entirely self-contained.=
 You
>run into issues when monsters inherit from other monster files,=
 or
>if you have "sub monsters" ... ie ... a dog monster with a bunch=
 of
>flee monsters attached to it.

This is definitely true.  Sub-classing with a DLL mechanism could=
 be 
tricky.

>If a monster is 100% self-contained, without dependances on=
 other
>dynamically loaded entities (and nothing depends on it) ...=
 then
>something like this could be possible without too much=
 headache.

My instinct is that this is pretty much a given in order to be 
workable.

>You're trying to replicate the dynamic language features of=
 Obj-C,
>Java, and C# in C. While you can do much of this, it's a heck of=
 a
>lot of work and I doubt you'll be able to get is as clean and=
 fast
>as what you can do with one of the other languages.

Possibly.  Except A.) I don't really like Java and C# that much,=
 and 
their run-times are exorbitantly expensive and B.) Obj-C is=
 really 
only usable on OS X.  So you can hack something using DLLs, and I=
 
think it's still workable.

>If you're stuck with C only, then I think something like this=
 sounds
>like something to really look into for dealing with dynamic=
 objects,
>especially if your goal is to be able to change things around at=
 run
>time.

Right.  I'm not saying it's perfect, but I do think it's an 
interesting approach.  You would have to establish some pretty 
serious ground rules up front, but it's very manageable and I=
 think 
it would probably be pretty effective for a limited subset of 
functionality.

Brian