[Gtkradiant] Draft for implementing multiple game support V1.0

[Hydra]

Okey doke, do you want to do a spot of copying and pasting stuff from my
draft
into the road map in the FAQ then ?

VFS:
 points noted.

Build Module:
 ok, i realise that build modules must be detachable, that's a good term for
it, it'd be
 daft for radiant to be using your computer's memory while your compiling.
 I had thought of that, but forgot to mention it.
 The idea of a universal build program is still useful, I think the first
detatchable
 build plugin should be the universal one, and then you can create more game
 specific versions from that.  Game specific build programs would have all
the
 niceties like check boxes for map compiler specific functions, whereas a
universal
 plugin would just let you define sets of command lines to run in order.
  e.g.
    A "Quake 3 - FullVis" config for a universal build compiler would just
run these
    commands one after the other:

      "D:/Games/Quake3/Tools/GTKR11/q3map # $"
      "D:/Games/Quake3/Tools/GTKR11/q3map # -vis $ "
      "D:/Games/Quake3/Tools/GTKR11/q3map # -light $"

 By doing that we can re-use some of the code that the BSP menu currently
uses.

Game configuration code:
  I'll get right on it.

Okey doke, thanks for the feedback,

Now that I've been working on the Radiant codebase for a few days and spoken
to
people in IRC I have a much better understanding of the development cycle
and
do's and don't when it comes to all this kinda thing.

Looking forward to your reply!

Hydra / Dom

----- Original Message -----
From: "Timothee Besset" <timo@qeradiant.com>
To: <gtkradiant@zerowing.idsoftware.com>
Sent: Thursday, October 04, 2001 2:45 PM
Subject: Re: [Gtkradiant] Draft for implementing multiple game support V1.0


> I have read through the document. It is good material for new developers,
> we could use it (or a lighter version of it) as a roadmap. But first some
> introductory remarks:
>
> - Any change to GtkRadiant must be motivated at it's basis by a
> functionality change or improvement. Changing something just because it
> will be cleaner is not a good enough reason. Each task should begin by a
> clear listing of it's objectives and constraints. Then description of a
> solution and a conclusion showing that our initial objectives and
> constraints are met. (NOTE: "design by contract")
>
> - Radiant evolves step by step. Changes must be self contained and
> isolated, so that the editor functionality is maintained through the
> developement. Of course it is not always possible, and we can expect a
> great deal of b0rkage when isolating the module code into a .lib for
> instance.
>
> This is for two reasons: allow several developers to work at once, and
> allow ongoing testing while the changes are made.
>
> Now some remarks about the changes themselves:
>
> - VFS:
>
> I think there are some details about the "major" / "minor" stuff in module
> APIs that are not very clear. The "major" name (i.e. "VFS" or "shader")
> refers to an API, that is function tables, structs and pure virtual
> classes. Those are used to abstract a given functionality.
>
> Then we have a "minor" which gives a "type" to the above functionality.
> The best example is probably image module, where the same API is used to
> load various file formats.
>
> Writing several "minor" for a given "major" (or API) doesn't mean we can
> use all of them at the same time in the editor. Right now we can have
> several "minor" for the image API. But we use a single "minor" for the
> VFS. Dealing with a single minor for some APIs is an important design
> choice.
>
> In the case of VFS, we are using a single API and we should continue to do
> so: it's no only a matter of ready various filesystems (the OS, .pk3's,
> .pak's and .wad's), it's a matter of having a search order configured. We
> probably need the "VFSSTDIO" functionality in several VFS implementations,
> but it's way easier to use it as a .lib inside the vfs modules.
>
> - Build module:
>
> The main interest I see in the build module is the ability to close the
> editor (or if it crashes..) and not loose the compilation. That's what
> Q3Build does, and it should be extended to add the watching capabilities +
> portability. G_Dewan had started some work towards this some time ago.
>
> Moving q3map in a module that's dependent on the editor (i.e. same
> process) is a BAD thing. Robert Duffy tried to do that for Q2, and all
> qeradiant users will agree that it was bad.
>
> - Game configuration files:
>
> The basic idea is to move the g_RequiredModules table to a file. This
> mostly relies on me writing a seperate .lib for module code, which I
> should get started with fairly soon. Meanwhile it's not a problem to have
> a bunch of #define and to start working on multiple games support that
> way.
>
> - Items stored in game configuration file:
>
> Each module can store his configuration chunk in those files. The code
> doesn't have to know about them, it just needs to know to which module to
> send the nodes.
>
> Ok I think that's about all I've written down so far.
>
> TTimo