Re: Write your own lib : the 3D case

[Nirina Ratoandromanana <nmcratoandromanana@yahoo.fr>]

Hi Bert Peers,
I agree with you when you said that the language like C & C++ does not
affect the game feel and speed; or when I began to learn Unix and other
OS with the same principle, one told me to run application that uses
the same library else your OS still recurses to the swap disk
memory.But for a game, there are multiple ways to do a thing and
putting all in one single library will not be very orthodox.Maybe with
the newest powerfull Pc' s, this will be off topic.

NMC <nmcratoandromanana@yahoo.fr>

--- Bert Peers <rat@larian.com> a écrit:
> (Sorry about the delays but my ISP is broken, all I
> can do is spool email about once a week...)
> 
> Ok, can't resist, here's a few cents on the To Lib
> or
> Not To Lib discussion :)  It's long and I'm not sure
> if it
> goes anywhere, read at your own risk ;)
> 
> 
> I was surprised to note that obviously experienced
> people like Steve and Jorrit vote for a single
> library, unifiying
> whatever exists now, based on the argument that
> everything offers
> the same functionality, and consequently any
> implementation
> of that functionality/interface is a duplicated
> effort.  I mean, if
> anybody, exactly these guys should know that as soon
> as a
> project is started at the scale of a 2D, 3D or even
> GUI lib,
> design tradeoffs have to be made.
> 
> Every programmer knows there's not just one way to
> store elements; depending on what you want to do,
> there's
> lists, arrays, bintrees, k-d's, etc.  The same goes
> for 3D; the
> problem starts with the storage of mesh files and/or
> the world :
> connected faces, BSP, octree, ... for meshes, BSP,
> PVS,
> octree, ... for the world.  While a good container
> lib would
> probably offer more or less every container type,
> not forcing
> the user into using one or another, a 3D library
> usually makes
> its choice, and from then on every algorithm is
> fixed for that
> particular datastorage.  To some extent I see CS
> trying to
> offer the same choice by splitting up rendering
> applications into
> outdoor and indoor for instance; but there are still
> too many
> decisions to make that will influence how everything
> works,
> from collision detection and physics up to the
> possibility to
> have inverse kinematics, and if so, how to do it
> (just to name
> something).
> 
> Basically, I agree with someone who posted that the
> use of a
> particular lib gives a game a particular feel.  All
> those design
> issues made in building the library are visible in
> the way the
> games using that lib look and feel.  For instance,
> for an
> experienced player it is obvious that Half Life is a
> Quake
> engine clone, whereas Klingon: Honour Guard is an
> Unreal
> engine clone.  From the way collision detection
> works for
> instance, you immediately "feel" Quake when you bump
> into a
> wall or an enemy or do your first strafe jump.  As a
> trivial
> example, the fact that a player standing on a
> rotating brush
> doesn't get a rotating viewdirection in Quake is a
> dead giveaway
> for any game that doesn't fix that after licensing. 
> The same goes
> for the look of it : Unreal computes and renders it
> lightmaps in
> a different way than Quake, and again you can see
> this by the
> way the world looks.  And if nothing else, the
> different particle
> systems and procedural textures of  Unreal are again
> a giveaway.
> So yes, what library you use affects how your game
> looks and feels;
> there's always only so much you can parameterize.
> 
> The argument that games don't have a C/C++ look and
> feel
> is a moot one.  C and C++ are languages, they're
> only a medium
> in which you can express your own algorithm; they do
> not place
> any restrictions on what you can write.  CS and
> thelikes on the
> other hand *are* the algorithm; they're not a way to
> express your
> collision detection, they *are* the CD. 
> Consequently, every
> tradeoff made in getting the necessary algorithms
> running is reflected
> in every part of the game using that algorithm,
> unless you rewrite it.
> 
> I think it will actually get worse in the future,
> when it comes to
> the proliferation of libraries.  It should, too. I
> agree here with
> Carmack's comments on "The Golden Era of the
> Triangle" :
> up to now hardware was pretty restricted in what it
> could do,
> and consequently every game looks more or less the
> same.
> Am I contradicting what I said two paragraphs back ?
>  No,
> there still were differences : lightmaps, CD,
> kinematics,
> particle systems, etc.  But the basic architecture
> of any FPS
> or racing game always looked the same : restricted
> polygon
> counts basically mean every game takes place in a
> glorified
> empty box.  With cards that'll do millions of polys
> per second
> there'll be a choice again -- or if you want, a new
> category of
> design tradeoffs to be made in building a lib : use
> the extra
> polys for detailed architectured, like Quake 3 ? 
> Use them for
> highly tesselated NPCs, like Messiah ?  Again, I can
> see how
> CS could be extended to facilitate making either
> choice, but
> imho it gives viability to the idea of having
> multiple 3D libs
> each doing their particular thing (which is also
> what's happening
> in the commercial world : Quake3, Unreal, LithTech2,
> etc)
> 
> My point ?  Well, naturally I agree that there is
> only one good
> way to read a joystick, mouse, keyboard, play sound,
> etc.
> But when it comes to anything of some complexity,
> there will
> always be design issues that can be solved in
> multiple ways --
> even if the final functionality/interface/API offers
> the same
> capabilities.
> 
> Looking forward to your reactions !  See you next
> week :)
> 
> Bert
> --
> 
> -=<Short Controlled Bursts>=-
> 
> 
> 
> 

___________________________________________________________
Do You Yahoo!?
Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr