wt - a 3D game engine

Copyright (C) 1994 by Chris Laurel

Please see the LICENSE file for further details.  You may not distribute
this project without this file (README) and the LICENSE file included.

---------------------------------------------------------------------------

This is still a preliminary version of my 3D game engine, wt.

* In the proud tradition of cp, mv, rm, as, and cc, now there is 'wt'
  wt (never capitalized) stands for "what's that?"

* This is not by any means a complete game.  It is just a demo of my
  graphics engine.  I'd never name a game wt.

* wt is portable software.  See the section on porting at the end of this
  README for information on what to change in order to port to another
  platform.

* Features:
	* Easy to edit world file.  Just haul out your favorite text editor
	  and modify 'castle.world'  Or create your own .world file from
	  scratch.  Whee.  Just don't get carried away because the world
	  file format will be changing before the next release.
	* No BSP trees were killed to make this program.  Sorry . . . it's
	  late.  BSP trees are elegant and fast *if* your environment is
	  static.  I eventually want walls in wt that move and change shape.
	  However, if I can't kill a bug having to do with walls perpendicular
	  to the view plane, I may have to resort to a BSP tree for determining
	  wall visibility (or if my current algorithm is too slow for worlds
	  with a large number of walls.)
	* Variable texture map size.  Texture maps for walls can be any
	  width you like, but the height must be either 64 or 128.  Floor
	  textures must be either 64x64 or 128x128.  The main reason why
	  arbitrary powers of two aren't supported has to do with the fact that
          Intels x86 chips don't have enough registers for my innermost loops.
	* Texture scaling for walls.  The walls have an x scale factor and
	  a y scale factor.  It might be more properly called 'frequency,'
	  since the smaller the parameter, the bigger the texture map will
	  appear.  Supporting the scaling factors requires a couple of extra
	  multiplies in the wall drawing function.


* Running the demo (this applies to the Linux version only):
	
	* For xwt, just type 'xwt castle.world'  The keys are:
	    forward - up arrow
	    backward - down arrow
	    turn left - left arrow
	    turn right - right arrow
	    strafe - slash
	    run - shift
	    jump - space

	* To run wt, you need to be root (or make it setuid root first.)
	    It sucks to have to run a binary you grabbed off the net as
            root, but as far as I know, that's the way it has to be with
	    svgalib base programs.

	    As root, type 'wt castle.world'  The keys:

	    forward - e
	    backward - x
	    turn left - s
	    turn right - d
	    strafe left - a
	    strafe right - f
	    jump - space


* Responses

	* I received a lot of e-mail from people about the binary-only
	  version 0.01 of wt.  Thanks for all the interest, and I apologize
	  to anyone to whom I did not respond.  I've been frying my brain
	  on wt.

	* While wt does look similar in many respects to DOOM, it is not
	  based on any DOOM source code, and I have no connection with Id
	  software other than being a customer.

	* The most frequently asked question was about the texture file
	  format.  As you can now tell by looking at texture.[ch], it
	  is my own format.  There's no reason for this beyond the fact
	  that I wanted something for a quick prototyping of the engine,
	  and I didn't have any graphic file format specs sitting around.
	  I'm open to suggestions about texture file format.

	* I will add mouse support for the X11 and svgalib versions.  I also
	  want to support the Linux keyboard better by setting it to
	  RAW mode.

	* Your X server needs to support the MIT shared memory extension
	  in order for wt to run.  Also, it only currently supports an
	  8-bit pseudo color visual.  I just haven't had a chance to perfect
	  the X code.

	* I will eventually design a world editor.  It will run under X and
	  be based on Tcl/Tk.

	* Pitch and roll will not be supported.  It's a fundamental constraint
	  of the engine design.

	* Weird things will happen when you jump above the tops of buildings
	  or though the ceiling.  You cannot see the tops of buildings--this
	  is another design limitation.

	* Resizing the view window . . . this does need to be supported.  The
	  reason why it is not currently supported again has to do with the
	  limited register set of the x86 chips.  I wanted to keep all my
          variables in registers in the innermost loop, but they would not
	  all fit.  So, I made the view width an immediate constant . . . if
	  I can coax gcc to let me use the ebp register, I'll use that to
	  hold the width.  Or I could just deal with the (probably minor)
	  speed degradation I'd get by reading it from memory.


* Room for improvement

	* Better texture file format.  There's some unnecessary information
	  in the texture files now which is left over from a previous 3D
	  project.

	* Optimizations.  There are some obvious ones that I have not gotten
	  around to implementing yet.  In particular, the multiplies in
	  calc_wall_heights can be avoided.  I think that the floors code
	  can be sped up also.  If you know of any improvements to the
	  assembly loops in slice.c, *tell me*.  I'm not an Intel assembly
	  language guru or anything.

	* Code cleanup.  The core of wt is still in development, so some of
	  the code surrounding the renderer is hacky test-the-engine stuff.
	  Once wt starts developing into a real game, much of the code
	  will be reorganized.  wt.c will change completely.


* 'Port away!'

	* wt now supports both big and little endian machines.  The only
	  endianness dependent part of the code was in texture.c.  If you
	  have a big endian machine (pretty much anything but an Intel system)
	  you may need to edit the makefile and add -DBIG_ENDIAN to CFLAGS.
	  However, my system already has an endian #define, so you may
	  not need to do anything.

	* There are three types of #define's used to block off non-portable
	  sections of the code.  ARCH_i86 surrounds the couple assembly
	  routines in the wt source.  I also surround these with an
	  #ifdef __GNUC__ because the inline assembly code syntax in
	  gcc is different than for other x86 compilers I've seen.  (Anyone
          considering doing an DOS or Windows port take note:  the GNU
	  assembler uses AT&T syntax, which has the reverse operand order
	  of Intel syntax.)  Finally, there is a #define to identify
	  the graphics system.

	* Substitute C routines exist for assembly language functions.
	  On a RISC system with a good compiler, I figure you shouldn't need
	  to recode them in assembly language.  The C functions *should* work.
	  I have not tested them in a while, but they were used extensively
	  before I rewrote them in assembly.

	* Before attempting to compile on a non-UNIX system, #define PROFILE
	  to be zero in render.c.

	* If you've got a non-Intel system with X11 (or an Intel system
          with X11 which does not have gcc), then you should be able to
	  compile wt successfully by just not defining ARCH_i86 in the
	  Makefile.

	* If you're not running X11, then you'll need to write your own
	  graphics and input routines and add a #define for your graphics
	  system.  Check out linuxvga.c and x11graphics.c for sample
	  graphics implementations.  All you need is an initialization
	  function, a cleanup function, and something to blast a framebuffer
	  the screen--memcpy, CopyBits or whatever . . .

	* The input system hooks are in input.c.  For sample input routines,
	  look in linux-console.c and x11input.c.  Mac and Windows people:
	  x11input.c should give you a good idea about how to tie an
	  event handler into wt.

	* Send me your ports and I'll include them in the next wt distribution!
	  This goes for other improvements to wt, too.  Although I love
	  hearing ideas, I'm *not* building a game yet.  I'm just interested
	  in getting the engine working cleanly and quickly on as many
	  platforms as possible.

	* I'm especially interested in reports about how fast wt will run
	  on different platforms (wtStones?)  If you do a port, talk to me
	  about speed, especially if you have a PowerMac or Alpha system.
	  If you port it to a 286, I'm interested but I might laugh.

	
* Future directions:

	* I'd like to see wt become a multi-platform client for an
	  Internet wide MUD type game.  Or a perhaps a net-wide arcade
	  game like Xpilot.  I've got a lot of other more innovative ideas
	  but I'd better get the engine done before I start spouting about
	  them.

* CREDITS

	Dan Egnor (egnor@ugcs.caltech.edu) - submitted the first set of
	     endian fixes.
	Dave Thomas (dave@thomases.demon.co.uk) - wrote up an Imakefile

* Me:

	send any comments, ideas, bug reports, etc. to:

	Chris Laurel
	home: claurel@mr.net
	work: chrisl@county.lmt.mn.org
	snailmail: 5700 W Lake St, #208
                   St. Louis Park, MN  55416
