On Mon, Sep 10, 2001 at 07:41:56PM -0400, Zephaniah E. Hull wrote:
> > 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.
I'm sure we can figure it out. It's easy since we've done this before.
> > 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?
The reason why I say no is that we definitely want them to be a library in
the future and we don't want a bunch of libraries. Provided the code is
not too incestuous (Cvar, Cmd, and console are the same codebase really,
just that there happen to be three (four actually, but Cbuf can be
considered to be seperate if we need it to be..), then the components will
all be there and, like SDL, apps will just use the parts they need..
> > 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.
Reasonable, but I agree that it is important that we do it. Especially if
we intend to relegate the code to maintenance only after we've made it
feature complete. It's not reasonable to expect code added to one will
get added to the other unless that's a natural side-effect of doing it the
first time in code that is only passively maintained.
> > 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.
Only a couple issues actually. Namely that QW and NQ have a different
concept of the current player and the sound code needs to know it.
Teaching NQ the QW way is how we did it before, and it worked like a charm
once we discovered the off-by-one error in the code. IIRC, you did it the
last time, so that's going to simplify things a bit.
> > 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.
At this early stage, it's not. That might change, but for the time being
it most certainly is not at all wise.
> > 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.
Fine, now give me a name for "baselib" that doesn't suck? =)
--
Joseph Carter <[EMAIL PROTECTED]> Free software developer
Tagline, you're it!
PGP signature
