[quake2] Q2X

Russell F Mellinger ;011;icsg1; rfm4792 at cs.rit.edu
Sat Mar 22 05:22:56 EST 2003


Brian:
Not a big deal, but the X-Box quake2 "port" is named Quake2X, I
believe...
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"... :)

-Rusty Mellinger

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
> files
>
> - 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.
> types
>
> - 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)
>
> Brian
>
>
>
>



More information about the quake2 mailing list