On Sun, Sep 09, 2001 at 09:21:29PM -0700, Joseph Carter wrote:
> I want to make several changes to the tree's layout which were not done
> originally because of a number of reasons which either do not any longer
> or will not soon matter anymore. I do _NOT_ want to do this before
> release since that would simply hold up the release several weeks and we
> are all itching to call this thing stable.
>
>
> The current CVS archive looks like this:
>
> twilight
> |-- debian
> |-- doc
> | `-- olddoc
> |-- gamecode
> | `-- progs
> |-- include
> |-- nq
> |-- qw
> |-- qw-server
> `-- tools
>
> There are a number of strengths to this system. First of all, it's very
> simple. There is no real need to try and navigate the tree. If something
> is not where you expect it, there aren't many other places it could be,
> and that's a good thing. Also, it's pretty simple to add to the current
> system. The gamecode directory is perhaps inappropriately named, but at
> this stage it could change to "gamedata" with no ill effects (not even the
> loss of old revision information at this point) to accomodate data which
> we expect to ship with the engine. The docs and tools directories are
> aptly placed. Generally, it's the right track I think.
>
> Here are the steps I think we should follow in order to improve on the
> strengths of our current codebase and resolve the weaknesses:
>
> 1. Move twilight/qw-server into twilight/qw.
> Having the two in the same directory could be done today if we wanted
> to, that much need not wait for release. Putting a server into the
> client ala NQ would have to wait though.
As long as we can do this without adding #ifdefs, or making the mess
worse.
>
> 2. Create twilight/baselib. FIXME: better name?
> A place to put mathlib, strlib, console, cvar, cmd, bspfile, common,
> and all of the other things which were classically used by both the
> engine and the tools. The code here should be built into a static
> library for the engine to link, but we should not discount making it a
> dynamic library in the future.
The question is should some of these be split into their own directory
or not?
>
> 3. Create twilight/renderer.
> Here we'll place all of the shared stuff necessary for the client's
> rendering. Starting with all of the gl_* files, more or less. They
> should lose their gl_ prefix probably when they move. I'm not sold yet
> on the idea that that vid_sdl belongs in here, but I'm not really sure
> where to put it really.
This will be, non-trivial, I still believe that while this is probably a
good idea it will require changing important parts of beth QW and NQ to
do it right, definitely something to wait on.
>
> 4. Create twilight/sound.
> Currently, there is not much to Project Twilight in the form of sound.
> Only a handfull of files. But if we add support for more kinds of
> music such as mp3, Ogg Vorbis, etc, I believe it will make more sense
> to give these things a place of their own.
Not as many issues as the renderer.
>
>
> These directories should be as free of outside dependencies as possible.
> Clearly most of them will depend on "baselib" and just about all of them
> will depend on SDL for certain. Headers for each module should move to
> that module. That'll mean more include paths in the engine, but it also
> means that the modules themselves will be more bite-sized. The exception
> to this is of course baselib, whose headers should live in the shared
> include directory we have now, possibly a subdirectory of that even
> waiting for the day that these headers will actually be installed on the
> system.
Moving everything into a subdirectory for includes would probably be a
very good thing, but I am unconvinced that installing them on the system
is even desirable.
>
>
> The result should look like this:
>
> twilight
> |-- baselib (or whatever)
> |-- debian
> |-- doc
> | `-- olddoc
> |-- gamecode
> | `-- progs
> |-- include
> | `-- Twilight
> |-- nq
> |-- qw
> |-- renderer
> |-- sound
> `-- tools
>
>
> The last thing I want to do, and probably not until after our second
> release, is move the twilight directory to twilight-classic so we can move
> on, break compatibility, and do cool things. Obviously that's way off in
> the distance, but I thought I'd mention it since I have already made the
> Debian package scripts work that way.
That sounds good.
Zephaniah E. Hull.
>
>
> Comments? Suggestions? Thwacks for really lame design choices?
>
> --
> Joseph Carter <[EMAIL PROTECTED]> Free software developer
>
> <elmo> unclean: err, the admin team do not control the archive, that's the
> ftp cabal
> <elmo> get your cabals right, damn it :-P
>
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Why blow away at a partition when you can chip away at it? I now
present a script I just wrote that writes random bits of, well random
bits, into random places in your favorite partition or file. For best
(meaning most spectacular) results, use while the database or
filesystem is in active use.
Disclaimer: This code is untested, and it may or may not trash your
filesystem and/or database. While at least a half-assed effort has
been made to ensure that it works as designed, there is no guarantee
that its use will result in a loss of important data. I am not liable
for the lack of either direct or incidental damages.
-- Logan Shaw on ASR.
PGP signature
