Compiling Doom Legacy 1.4x SDL

In order to compile Doom Legacy 1.4x SDL you'll need to have the following libraries installed on your system.
Make sure you install the developer packages of the libraries, which include both the runtime libraries (DLLs) and the stuff required during compilation (header files and import libraries).

NOTE: Most Linux distributions offer these libraries in the form of precompiled packages.

LibraryVersionUbuntu/Debian packageDescription
SDL 1.2.10+ libsdl1.2-dev Simple DirectMedia Layer. A multiplatform multimedia library.
SDL_mixer 1.2.7+ libsdl-mixer1.2-dev A multichannel mixer library based on SDL.
OpenGL 1.3+ (several) The standard cross-platform graphics library, usually comes with the OS.

You will require the following programs during the build process:

Finally, download the Doom Legacy source. You can either get the source package or, for the latest code snapshot, checkout the legacy_one/trunk/ directory from the Subversion repository:

svn co https://doomlegacy.svn.sourceforge.net/svnroot/doomlegacy/legacy_one/trunk some_local_dir

From now on, your local copy of this directory will be referred to as TRUNK.

Compiling Legacy

  1. Open a shell window. Go to the TRUNK.
  2. Run make to build the executable.
    Add HAVE_MIXER=1 for SDL_mixer music.
    Add DEBUG=1 for debugging information.

Coding rules and practices


Know bugs/issues

 - splats on opengl/glide have serious z-problems and are not clipped 
   to the seg 
 - the splats should be in segs and not in linedefs, so we can clip it 
   and render only when needed (actualy there is overdraw in opengl/3dfx)
 - the sky in opengl/3dfx is not well mapped and we have big problem with 
   large sky like in tnt map01
 - when clientprediction2 is enabled (see doomdef.h) the spirit mobjs
   have some serious z problems when exiting/entering moving platforms
 - monsters/sprites have feet(head) in ground, caused by z-buffer,
   solution : trace all view using back-to-front rendering and use
   clipping like in software for spite (lot of work here)
   also debug the clipwall in harware, this will also fix the water
   and transparent wall problems
 - there is no splats on floors and ceiling, fab have begon but 
   haven't finish
 - sprite that have transparent region (torch, lost soul...) are full 
   transparent in 3dfx/opengl

Explanation of the code

 3.1 The memory model (original) (z_zone.c) (by BP)
 --------------------

 Doom allocate a heap of 6 megs at begining and provide a Z_Malloc function
 to allocate in this heap. 
 
   Z_Malloc( int size,int tag,void* user )

    size is the size in byte
    tag can be : PU_STATIC   allocated static (like malloc do)
                             call Z_Free to free it
                 PU_LEVEL    same as static but the zone is "tagged" with the 
                             tag PU_LEVEL, when calling 
                             Z_FreeTag (PU_LEVEL, PU_LEVEL) all zone tagged 
                             with PU_LEVEL are freed (at the end of the level)
                 PU_CACHE    this one _can_ be freed automatiquely by one other
                             call to Z_Malloc. the *user point to a pointer 
                             to this zone so when freed automatiquely the 
                             pointer is set to NULL so eatch time you use it
                             you must check if the pointer is not NULL and 
                             reload it.

 (...)

 3.2 Hardware Texture model (by BP)
 --------------------------

 Eatch texture/patch/flats/pic in legacy are converted to hardware texture at 
 runtime (the GlideMipmap_s structure (hw_data.h)). I will call hardware 
 texture a gr_texture so there is no confusion.

 To remind you :
  - Texture are set of patch and are associate to linedefs (walls) can be 
    upper, lower or middle texture. It can have hole on it.
  - patch are sprites (the doom patch are run of vertical lines)
  - flats are used for floors and ceiling of sectors and have size of 64x64
    it can't have hole on it
  - pic are new legacy format for picture, it can only handle plain texture 
    like flats it is now used for hud in full screen for the main picture 
    of legacy and for coronas (the format was extended to handle 32 bit color
    or intensity + alpha, not all are implemented at this time)

 Since patch, flat and pic are basic structure represented by only one lump in
 the wad, the wad loader allocate for eatch lump a GlideMipmap_s (cache3Dfx) 
 and init data field to NULL. Since the data structure is allocated in 
 PU_3DFXCACHE (like PU_CACHE) the data will be initilised when needed 
 (hw_cache.c).

 The GlideMipmap_s structures for textures are initialized on 
 HWR_PrepLevelCache (hw_cache.c) it is called in P_SetupLevel (load level)
 the number of textures is computed with TEXTURE1, TEXTURE2 lumps since this
 can be changed in runtime in legacy (load a wad while runing) it must be 
 reallocated. Well, at this time it is realloceted at eatch level start. We 
 can do better, since numtextures change only when a wad is loaded.

 The 3dfx driver use glide3, it load gr_texture in gr_texture memory of the 
 card in fifo order when there is no more place it remove the first gr_texture,
 the downloaded field of GlideMipmap_s go to false and when needed it is 
 reloaded in gr_texture memory. In OpenGl, since OpenGl keep texture in there 
 own memory and handle gr_texture memory of the card we no more need to 
 redownload it but if we not free time to time gr_texture memory in opengl, 
 it will get alot of memory, so the gr_texture memory is cleared at eatch 
 new level (same time of texture reallocation). Opengl and 3dfx link the 
 loaded gr_texture with the nextmipmap field of GlideMipmap_s so before clear 
 textures of the heap we MUST free gr_texture memory of OpenGl or 3dfx !

 Legacy can also draw patch with a differant colormap (thanks to Hurdler).
 When needed it create the same gr_texture but just with a differant colormap. 
 This one is linked with the original in the GlideMipmap_s with the 
 nextcolormap field.

 So when a polygone with a gr_texture must be drawn, first we check if the 
 gr_textures is not allready loaded in hadware memory (downloaded field) if 
 not then we check if gr_texture data is there (not grabbed by z_malloc 
 function) if not we must recompute it eatch type of gr_texture (texture, 
 patch, flat, pic have there own methode) the we can send the gr_texture 
 to 3dfx or OpenGl.