I cut this email short last night and did not go into much detail on my
specific plans for src/base.  The current candidates for things to move
into src/base are: Cmd, Cbuf, Cvar, mathlib, strlib, zone, most of what's
currently in common.c, and a rewrite of what's in console.c.

Like the rest of the original engine, these bits of code have a somewhat
incestuous relationship.  Once liberated from the rest of the engine, they
will still have much need of the other parts of base and that too should
change.  By the time we're done fiddling with it, I hope the dependency
structure will look something like this:

Zone - nothing
mathlib - nothing
strlib - Zone
Cvar - Zone
Cbuf - Zone
Cmd - Cbuf, Cvar
console - Cbuf
common - Zone for sure, more maybe


Zone becomes more or less the constant.  If there is any memory to be
futzed with, it should be done via the memory functions.  I'd like to
split zone into Zone, Hunk, and Cache.  Cache and Hunk will either wind up
in the same file or the former will depend on the latter, simply because
of how the two work at opposing ends of the same memory space.  The three
will definitely emit a header, probably TW_memory.h which includes all
three.

Mathlib's header will probably end up TW_math.h.

Strlib will probably get smarter.  Much to Elric's relief, the standard
string functions will become the strl type, and functions such as strdup
will start having versions which allocate memory in the Zone, etc.  Header
will probably be TW_string.h

Cvar will lose its ties to Cmd.  This will allow Cvar to be used for other
things than consoles.  Cvar is very useful for config files and not half
bad when set from a dialog box either.  This means that Cvars will no
longer add commands for set and will not know how to write their own
configuration anymore.  TW_cvar.h.

Cbuf will lose all its Cmd stuff and will feature a stub Cbuf parser which
is essentially just going to spit things out to printf.  TW_cbuf.h

Cmd will gain the missing functions from Cbuf and Cvar, and will provide
the glue to handle the scripts and disk files, etc, we have come to expect
to just work.  TW_cmd.h.

Console will see a pretty significant rewrite.  It will depend on Cbuf,
but have no concept of things like Cmd and Cvar.  It'll depend entirely on
Cbuf to figure that stuff out.  It also will not understand how to draw
itself really.  It will stub its input and output functions with versions
that use stdin/stdout and provide no way to do things like scrollback or
editing other than simply backspace.  Engines and tools will replace these
stub functions with more full-featured ones which may use Cvars and other
things if they need to.  TW_console.h.


Common requires more than just detachment from the engine.  Currently it
contains doubly linked lists, custom atoi and atof, a set of high-level
(for networking) functions, a few filename functions, the command line
parser, the registration check, a couple utility functions, the Quake VFS,
functions for QW's info strings, and a CRC function which is not part of
the rest of the CRC code.

The QW-specific stuff has no basis for being in src/base.  The CRC stuff
is the same way.  The MSG network functions could be merged, but shouldn't
be.  The command line parser could move to its own file (and serve with a
rewrite in the process to improve its functionality significantly..)  The
filesystem belongs in its own file, and the rest I'm not sure about yet.


That's the direction I'm thinking, at least.

-- 
Joseph Carter <[EMAIL PROTECTED]>            Free software developer

2.3.1 has been released. Folks new to this game should remember that
2.3.* releases are development kernels, with no guarantees that they
will not cause your system to do horrible things like corrupt its
disks, catch fire, or start running Mindcraft benchmarks.
        -- Slashdot

Attachment: msg00839/pgp00000.pgp
Description: PGP signature

Reply via email to