<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<link rel="stylesheet" href="legacy.css" type="text/css"/>
<meta name="keywords" content="Doom, Legacy, Doom2, fps, classic, game, download, news"/>
<meta name="description" content="Doom Legacy is your premiere source port engine for id Software's classic DOOM games and more!"/>
<title>Compiling Doom Legacy</title>
<!-- $Id:$ -->
<h2>Compiling Doom Legacy 1.4x SDL</h2>
<p>In order to compile Doom Legacy 1.4x SDL you'll need to have the following
libraries installed on your system.<br/>
Make sure you install the <b>developer</b> packages of the
libraries, which include both the runtime libraries (DLLs) and
the stuff required during compilation (header files and import libraries).</p>
<p>NOTE: Most Linux distributions offer these libraries in the form of
<td><a href="http://www.libsdl.org/download-1.2.php">SDL</a></td> <td>1.2.10+</td>
<td>Simple DirectMedia Layer. A multiplatform multimedia library.</td>
<td>A multichannel mixer library based on SDL.</td>
<td>OpenGL</td> <td>1.3+</td> <td>(several)</td>
<td>The standard cross-platform graphics library, usually comes with
You will require the following programs during the build process:
<li><a href="http://gcc.gnu.org/">GCC</a> 3.3+, the Gnu Compiler Collection which, among other things, is
a free C/C++ compiler.<br/>
Linux systems most likely already have it installed.<br/>
Windows users should install <a href="http://www.mingw.org/">MinGW</a>, a
GCC port, and <a href="http://www.mingw.org/node/18">MSYS</a>, a
collection of POSIX utilities for Win32.</li>
Finally, download the
<a href="http://sourceforge.net/projects/doomlegacy/">Doom Legacy source</a>.
You can either get the source package or, for the latest code
snapshot, checkout the <b>legacy_one/trunk/</b> directory from the
<a href="http://subversion.apache.org/">Subversion</a> repository:
<div class="code">svn co https://doomlegacy.svn.sourceforge.net/svnroot/doomlegacy/legacy_one/trunk some_local_dir</div>
From now on, your local copy of this directory will be referred to as <b>TRUNK</b>.
<li>Open a shell window. Go to the <b>TRUNK</b>.</li>
<li>Run <b>make</b> to build the executable.<br/>
Add <b>HAVE_MIXER=1</b> for SDL_mixer music.<br/>
Add <b>DEBUG=1</b> for debugging information.
<h2>Coding rules and practices</h2>
<li>There is one subdirectory in the repository for each platform
(SDL, X11, Win32 etc.). Ideally these subdirectories should contain all
<li>Do not commit tests or buggy code. Every revision should at least
compile and link. If you absolutely feel you need to commit
experimental code that does not fully work yet, use #ifdefs with a
descriptive name to disable it.</li>
<li>Fix any and all warnings the compiler gives. They are there for
<li>Keep the list of major bugs in ??? up-to-date.</li>
<li>Doom Legacy is a Doom source port. Do not make noticeable changes
to the gameplay without adding an user-controlled option (consvar
for example) to disable them.</li>
<li>Use the developer mailing list to keep other devs informed of
your work. If you are not sure about whether a feature/change is a
good idea or what is the best way to implement it, discuss it on the mailing list.
Keep a log of your work in the _log directory.
This will help other devs to keep up with you and makes it much
simpler to update the what's new section of the docs
when making a release.
Use hard tabs when indenting code (i.e. spaces, not tab
characters). Use either a 2 or 4 space tab size.
Document all code, variables and functions must have names that
are descriptive and help to understand the code (so no names like
a2, ex, asdf2721...). Exception: variables that are entirely local
in scope and have an obvious purpose, like for loop indices (i, j, k, s, t...) or
coordinates (x, y, z, w...).
Try not to have extern declarations and function prototypes in a .c
file, they belong in the headers. Use static-scope variables and functions
whenever you can to make it clear what their role is. Global
variables are usually a bad idea.
Do not overuse #ifdef. Especially avoid platform-dependent #ifdefs in
the main code. Likewise, __BIG_ENDIAN__ and __LITTLE_ENDIAN__
conditionals only belong in m_swap.
- 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
- sprite that have transparent region (torch, lost soul...) are full
transparent in 3dfx/opengl
<h2>Explanation of the code</h2>
3.1 The memory model (z_zone.c) (by BP) (revised WDJ)
DoomLegacy allocates memory at begining and provides allocations of it via
There are several compile-time options for the memory block allocation.
PLAIN_MALLOC: Substitute malloc for zone memory allocation.
This ignores memory tags, and it cannot recover PU_LEVEL, PU_CACHE memory.
TAGGED_MALLOC: Uses malloc, and uses memory tags.
ZONE_ZALLOC: The zone memory system, with preallocated memory.
The memory allocation size is set by #define, and command line switches.
GROW_ZONE: An option that grows the zone memory allocation when needed.
AGGRESSIVE_PURGE: Aggressive purge of PU_CACHE, primarily as a
memory allocation test.
Z_Malloc( int size, int tag, void* user )
size: is the size in bytes
PU_STATIC: Allocated static (like malloc does).
Call Z_Free to free it.
PU_SOUND, PU_MUSIC: Static while playing. Specific to music uses.
PU_LOCK_SB: Static and protected against changing tag or releasing.
Must change with PU_UNLOCK_CACHE to unlock it.
Used to protect status bar textures.
PU_HWRPATCHINFO: Hardware renderer texture cache only.
PU_HWRPATCHCOLMIPMAP: Hardware renderer texture cache only.
PU_LUMP: Generic allocation for lump reading.
At end of level, will be converted to PU_CACHE.
PU_IN_USE: Protected against other allocations while it is in use. The user
is expected to FREE it or change it to PU_CACHE when they are done.
At end of level, will be converted to PU_CACHE.
PU_LEVEL: Static until level is over, where a call to Z_FreeTag will
release all PU_LEVEL allocations, and their user ptrs set NULL.
PU_LEVELSPEC: A PU_LEVEL for thinkers.
PU_HWRPLANE: A PU_LEVEL for hardware renderer planes.
PU_PRIVCACHE: PU_CACHE allocation that is kept longer, until PU_CACHE is gone.
Used by expensive combined patch textures.
PU_HWRCACHE: PU_CACHE for hardware renderer graphics.
PU_CACHE: Automatic free, when memory is needed by another Z_Malloc
allocation. When Z_Malloc reuses it for another allocation,
the user ptr will be set to NULL.
When the user accesses a PU_CACHE allocation, where other allocation
calls could have occurred, the user ptr must be checked for NULL,
and the item reloaded when necessary.
Change this allocation to a more protected tag when accessing
it around any code that does Z_Malloc allocation.
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
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
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.