Russell F Mellinger ;011;icsg1;
rfm4792 at cs.rit.edu
Sat Mar 22 05:22:56 EST 2003
Not a big deal, but the X-Box quake2 "port" is named Quake2X, I
Could cause some confusion.
Also, a very small, petty gripe: would somebody s/Russell Mellinger/Rusty
Mellinger/g in the readme? I've never really liked "Russell"... :)
On Tue, 4 Mar 2003, Brian Hook wrote:
> After talking to Ryan a bit and looking over my big fat list of
> things I'd like to do, it seems that the smart thing is to fork the
> code base instead of trying to overhaul the existing one. He's
> offered to host it, I just need to get it into a rev 0.01 state,
> which will be done after I get all the major file reshuffling done.
> Quake2 i.o. is really intended to be a conservative, stable and
> robust "Quake2 that runs on other platforms, especially Linux". Easy
> integration of third party patches such as Q2MAX and Q2ACE are higher
> priorities than they are with me.
> What I'm trying to do is basically make a Quake 2.5. I'd like to
> position these two forks as the "stable, clean, compatible,
> mergeable" one and the "new, improved, revamped" one.
> My goal is still to retain backwards compatibility, but I'm also
> trying to achieve some higher level goals, which I've outlined before
> but which I'll review here:
> - a "learning code base", which means that the code should be
> consistent and reasonably well documented
> - a portable code base
> - a clean code base. Rarely used code will be removed, and code
> paths that can be unified will be.
> - backwards compatibility with existing assets
> - encourage a mod community on all platforms. This is probably an
> uphill battle, but if it's pushed in the Lua community + Quake
> community I think it has a chance to succeed.
> I've discussed a couple of the steps required to get this going, but
> here's a more fleshed out list of what I have done and will do.
> - try to make a free reference PK2/ZIP file so that people can start
> playing without owning Q2. Ideally you can just download and run the
> game without any problems and no licensing restrictions. This is
> going to be time consuming and tedious, but I think in the end it
> will be worthwhile.
> - rename/cleanup all game and core function and variable names to
> make everything consistent
> - retrofit const and static correctness
> - move q_shared.* into qcommon/
> - integrate Lua 5 as the scripting language of choice, convert
> existing game and mods to Lua
> - integrate PhysicsFS so that we can use ZIP files instead of PK2
> - 64-bit clean and possibly get a hammer build going
> - refactoring qcommon into multiple files
> - more comments
> - move image support into qcommon and out of the refs
> - add support for JPG
> - possibly add support for Ogg Vorbis
> - cleaner hardware acceleration paths, similar to the work done from
> Q2 to Q3
> - integration of POSH, the Portable Open Source Harness
> (www.poshlib.org). This will allow removal of all the hardcoded
> _WIN32, __linux__ etc. checks, and will provided portable sized types
> that will likely be mapped into a set of qu32_t, qi32_t, qu16_t, etc.
> - remove IPX code
> - remove Glide, SST_GAMMA, Rendition and PowerVR references
> - remove the majority of cross-platform specific files and try to
> migrate towards SDL as a unifying abstraction. There will
> undoubtedly be problems with this, but they will hopefully be
> addressed by fixing the core SDL concerns instead of forking
> per-platform implementation issues.
> - add Quake3 style client side presentation mods (cgame/) in Lua.
> This is a pretty major architectural upgrade, but I think it can be
> structured so as not to break compatibility (since Q2 has no cgame
> equiv, by default everything would continue to work)
More information about the quake2