Re: The Author list for LGP

[Pierre Phaneuf <pp@ludusdesign.com>]

Johnny Taporg wrote:

> Re: Input
>   Usually, by choosing a graphics lib, your choice of
>   input lib is made for you.  This is fine, though,
>   because it's not like there are a lot of ways to
>   do input handling.

Most of the time, any input lib could be used with any graphics lib
(except for X, of course, which (theoretically) should be handing you
the input).

> Re: Licensing
>   I've seen lots of commercial developers ask about
>   the LGPL.  The misconception: if you make a game
>   that uses an LGPLed lib, you have to release the
>   source (or, you can't charge money for the game).
>   The truth is, as long as the game is dynamically
>   linked, only the source for the LGPL lib (+mods)
>   needs to be released.  The game itself can stay
>   as commercial and proprietary as it wants to.

Game library developers should also have a look at the Mozilla Public
License, which is much less restrictive than the LGPL, but keeps the
open source spirit much better than the Berkeley license or others.
Also, it was developed by enough Netscape lawyers to fill a stadium, so
it should be pretty solid.

>   Some C++ (namespaces, exceptions, templates, STL,
>   RTTI) has been standardized recently, so you need

Wow, C++ RTTI mentioned with (what seems) a straight face! ;-)

> Re: Assembly
>   Use NASM.  But if you code assembly at all, only
>   do it for the innermost, most repetetive loops.
>   Otherwise, it's probably not worth it.  It's been
>   years since I've used any assembly myself.

How about GNU as, apart from having to use AT&T syntax? I do assembly
just as badly with both syntaxes, so, as far as I'm concerned... :-)

> Re: Sound
>   I'm curious as to what's out there.  If someone
>   did a full overview of the options, the way I did
>   for graphics, that'd be cool.

One tendency I've seen is to put the sound device access in a separate
process or thread. As far as I'm concerned, that's useless and can only
add lag to the sound effects (as can be demonstrated with Doom on
Linux), due to the IPC required between the processes.

Remtris 3 has non-blocking sound processing done each time a frame
starts, and Quake is done in a similar way (we got the idea there), and
it do not slows the game down or induce any problems with the sound
quality.

> Re: Who's Who
>   What notable figures are active in the linux game
>   development community?  What do they do, and where
>   can you find them?  Carmack?  Dave Taylor?  Maybe
>   Jorrit (I've seen lot's of people say that they're
>   going to write a cool, free 3d engine - CrystalSpace
>   is the only one thusfar that I've seen succeed).

You have Zoid, certainly! And soon, I hope the Ludus Design people will
become "notable figures"... :-)

> Re: Net
>   BSD sockets.  Anything else we need to know?  Dan,
>   maybe you can comment here - all of the network
>   programming I've done has been unix-based client-
>   server stuff, never games.

It probably needs a layer on top of this. Based on a rant by John
Carmack in his .plan, I had the idea of doing an unified event system,
that has most everything as event emitters or sinks. For example, the
timer is an emitter, and sound and video processing are sinks for it.
Anyway. Too much vapor for the moment, I'll shut up.

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