diff --git a/CMakeLists.txt b/CMakeLists.txt index f426119c2..4de1d047f 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -327,10 +327,6 @@ add_subdirectory( wadsrc_bm ) add_subdirectory( wadsrc_lights ) add_subdirectory( src ) -if( NOT WIN32 AND NOT APPLE ) - add_subdirectory( output_sdl ) -endif() - if( NOT CMAKE_CROSSCOMPILING ) export(TARGETS ${CROSS_EXPORTS} FILE "${CMAKE_BINARY_DIR}/ImportExecutables.cmake" ) endif() diff --git a/docs/BUILDLIC.TXT b/docs/BUILDLIC.TXT deleted file mode 100644 index a0cec1251..000000000 --- a/docs/BUILDLIC.TXT +++ /dev/null @@ -1,71 +0,0 @@ -BUILD SOURCE CODE LICENSE TERMS: 06/20/2000 - -[1] I give you permission to make modifications to my Build source and - distribute it, BUT: - -[2] Any derivative works based on my Build source may be distributed ONLY - through the INTERNET. - -[3] Distribution of any derivative works MUST be done completely FREE of - charge - no commercial exploitation whatsoever. - -[4] Anything you distribute which uses a part of my Build Engine source - code MUST include: - - [A] The following message somewhere in the archive: - - // "Build Engine & Tools" Copyright (c) 1993-1997 Ken Silverman - // Ken Silverman's official web site: "http://www.advsys.net/ken" - // See the included license file "BUILDLIC.TXT" for license info. - - [B] This text file "BUILDLIC.TXT" along with it. - - [C] Any source files that you modify must include this message as well: - - // This file has been modified from Ken Silverman's original release - -[5] The use of the Build Engine for commercial purposes will require an - appropriate license arrangement with me. Contact information is - on my web site. - -[6] I take no responsibility for damage to your system. - -[7] Technical support: Before contacting me with questions, please read - and do ALL of the following! - - [A] Look though ALL of my text files. There are 7 of them (including this - one). I like to think that I wrote them for a reason. You will find - many of your answers in the history section of BUILD.TXT and - BUILD2.TXT (they're located inside SRC.ZIP). - - [B] If that doesn't satisfy you, then try going to: - - "http://www.advsys.net/ken/buildsrc" - - where I will maintain a Build Source Code FAQ (or perhaps I might - just provide a link to a good FAQ). - - [C] I am willing to respond to questions, but ONLY if they come at a rate - that I can handle. - - PLEASE TRY TO AVOID ASKING DUPLICATE QUESTIONS! - - As my line of defense, I will post my current policy about - answering Build source questions (right below the E-mail address - on my web site.) You can check there to see if I'm getting - overloaded with questions or not. - - If I'm too busy, it might say something like this: - - I'm too busy to answer Build source questions right now. - Sorry, but don't expect a reply from me any time soon. - - If I'm open for Build source questions, please state your question - clearly and don't include any unsolicited attachments unless - they're really small (like less than 50k). Assume that I have - a 28.8k modem. Also, don't leave out important details just - to make your question appear shorter - making me guess what - you're asking doesn't save me time! - ----------------------------------------------------------------------------- --Ken S. (official web site: http://www.advsys.net/ken) diff --git a/docs/README.asm b/docs/README.asm deleted file mode 100644 index 89629769a..000000000 --- a/docs/README.asm +++ /dev/null @@ -1,283 +0,0 @@ - -README - DOOM assembly code - -Okay, I add the DOS assembly module for the historically -inclined here (may rec.games.programmer suffer). If anyone -feels the urge to port these to GNU GCC; either inline or -as separate modules including Makefile support, be my guest. - -Module tmap.S includes the inner loops for texture mapping, -the interesting one being the floor/ceiling span rendering. - -There was another module in the source dump, fpfunc.S, that -had both texture mapping and fixed point functions. It -contained implementations both for i386 and M68k. For -brevity, I include only the i386 fixed point stuff below. - -//==================================================== -// tmap.S as of January 10th, 1997 - -//================ -// -// R_DrawColumn -// -//================ - - .data -loopcount .long 0 -pixelcount .long 0 - - .text - - .align 16 -.globl _R_DrawColumn -_R_DrawColumn: - - pushad - - movl ebp,[_dc_yl] - movl ebx,ebp - movl edi,[_ylookup+ebx*4] - movl ebx,[_dc_x] - addl edi,[_columnofs + ebx*4] - - movl eax,[_dc_yh] - incl eax - subl eax,ebp // pixel count - movl [pixelcount],eax // save for final pixel - js done // nothing to scale - shrl eax,1 // double pixel count - movl [loopcount],eax - - movl ecx,[_dc_iscale] - - movl eax,[_centery] - subl eax,ebp - imull ecx - movl ebp,[_dc_texturemid] - subl ebp,eax - shll ebp,9 // 7 significant bits, 25 frac - - movl esi,[_dc_source] - - - movl ebx,[_dc_iscale] - shll ebx,9 - movl eax,OFFSET patch1+2 // convice tasm to modify code... - movl [eax],ebx - movl eax,OFFSET patch2+2 // convice tasm to modify code... - movl [eax],ebx - -// eax aligned colormap -// ebx aligned colormap -// ecx,edx scratch -// esi virtual source -// edi moving destination pointer -// ebp frac - - movl ecx,ebp // begin calculating first pixel - addl ebp,ebx // advance frac pointer - shrl ecx,25 // finish calculation for first pixel - movl edx,ebp // begin calculating second pixel - addl ebp,ebx // advance frac pointer - shrl edx,25 // finish calculation for second pixel - movl eax,[_dc_colormap] - movl ebx,eax - movb al,[esi+ecx] // get first pixel - movb bl,[esi+edx] // get second pixel - movb al,[eax] // color translate first pixel - movb bl,[ebx] // color translate second pixel - - testl [pixelcount],0fffffffeh - jnz doubleloop // at least two pixels to map - jmp checklast - - .align 16 -doubleloop: - movl ecx,ebp // begin calculating third pixel -patch1: - addl ebp,12345678h // advance frac pointer - movb [edi],al // write first pixel - shrl ecx,25 // finish calculation for third pixel - movl edx,ebp // begin calculating fourth pixel -patch2: - addl ebp,12345678h // advance frac pointer - movl [edi+SCREENWIDTH],bl // write second pixel - shrl edx,25 // finish calculation for fourth pixel - movb al,[esi+ecx] // get third pixel - addl edi,SCREENWIDTH*2 // advance to third pixel destination - movb bl,[esi+edx] // get fourth pixel - decl [loopcount] // done with loop? - movb al,[eax] // color translate third pixel - movb bl,[ebx] // color translate fourth pixel - jnz doubleloop - -// check for final pixel -checklast: - testl [pixelcount],1 - jz done - movb [edi],al // write final pixel - -done: - popad - ret - - - -//================ -// -// R_DrawSpan -// -// Horizontal texture mapping -// -//================ - - - .align 16 -.globl _R_DrawSpan -_R_DrawSpan: - pushad - -// -// find loop count -// - movl eax,[_ds_x2] - incl eax - subl eax,[_ds_x1] // pixel count - movl [pixelcount],eax // save for final pixel - js hdone // nothing to scale - shrl eax,1 // double pixel count - movl [loopcount],eax - -// -// build composite position -// - movl ebp,[_ds_xfrac] - shll ebp,10 - andl ebp,0ffff0000h - movl eax,[_ds_yfrac] - shrl eax,6 - andl eax,0ffffh - orl ebp,eax - - movl esi,[_ds_source] - -// -// calculate screen dest -// - movl edi,[_ds_y] - movl edi,[_ylookup+edi*4] - movl eax,[_ds_x1] - addl edi,[_columnofs+eax*4] - -// -// build composite step -// - movl ebx,[_ds_xstep] - shll ebx,10 - andl ebx,0ffff0000h - movl eax,[_ds_ystep] - shrl eax,6 - andl eax,0ffffh - orl ebx,eax - - movl eax,OFFSET hpatch1+2 // convice tasm to modify code... - movl [eax],ebx - movl eax,OFFSET hpatch2+2 // convice tasm to modify code... - movl [eax],ebx - -// eax aligned colormap -// ebx aligned colormap -// ecx,edx scratch -// esi virtual source -// edi moving destination pointer -// ebp frac - - shldl ecx,ebp,22 // begin calculating third pixel (y units) - shldl ecx,ebp,6 // begin calculating third pixel (x units) - addl ebp,ebx // advance frac pointer - andl ecx,4095 // finish calculation for third pixel - shldl edx,ebp,22 // begin calculating fourth pixel (y units) - shldl edx,ebp,6 // begin calculating fourth pixel (x units) - addl ebp,ebx // advance frac pointer - andl edx,4095 // finish calculation for fourth pixel - movl eax,[_ds_colormap] - movl ebx,eax - movb al,[esi+ecx] // get first pixel - movb bl,[esi+edx] // get second pixel - movb al,[eax] // color translate first pixel - movb bl,[ebx] // color translate second pixel - - testl [pixelcount],0fffffffeh - jnz hdoubleloop // at least two pixels to map - jmp hchecklast - - - .align 16 -hdoubleloop: - shldl ecx,ebp,22 // begin calculating third pixel (y units) - shldl ecx,ebp,6 // begin calculating third pixel (x units) -hpatch1: - addl ebp,12345678h // advance frac pointer - movb [edi],al // write first pixel - andl ecx,4095 // finish calculation for third pixel - shldl edx,ebp,22 // begin calculating fourth pixel (y units) - shldl edx,ebp,6 // begin calculating fourth pixel (x units) -hpatch2: - addl ebp,12345678h // advance frac pointer - movb [edi+1],bl // write second pixel - andl edx,4095 // finish calculation for fourth pixel - movb al,[esi+ecx] // get third pixel - addl edi,2 // advance to third pixel destination - movb bl,[esi+edx] // get fourth pixel - decl [loopcount] // done with loop? - movb al,[eax] // color translate third pixel - movb bl,[ebx] // color translate fourth pixel - jnz hdoubleloop - -// check for final pixel -hchecklast: - testl [pixelcount],1 - jz hdone - movb [edi],al // write final pixel - -hdone: - popad - ret - - - - -//==================================================== -// fpfunc.S as of January 10th, 1997 (parts) - -#ifdef i386 - -.text - .align 4 -.globl _FixedMul -_FixedMul: - pushl %ebp - movl %esp,%ebp - movl 8(%ebp),%eax - imull 12(%ebp) - shrdl $16,%edx,%eax - popl %ebp - ret - - - .align 4 -.globl _FixedDiv2 -_FixedDiv2: - pushl %ebp - movl %esp,%ebp - movl 8(%ebp),%eax - cdq - shldl $16,%eax,%edx - sall $16,%eax - idivl 12(%ebp) - popl %ebp - ret - -#endif - diff --git a/docs/README.gl b/docs/README.gl deleted file mode 100644 index df443a9fb..000000000 --- a/docs/README.gl +++ /dev/null @@ -1,149 +0,0 @@ - -README: glDOOM - -I never got around to do anything with respect to -a Linux glDOOM port except for assembling a Linux3Dfx -HOWTO (which, at that time, was a prerequisite -to get permission to publicly distribute the -already finished LinuxGlide port by Daryll Strauss). - -Linux q2test (and soon LinuxQuake2) demonstrate that -Mesa with the MesaVoodoo driver is quite up to the -requirements for a glDOOM port. If anybody wants to -get into Linux glDOOM, please drop me a line. - -There is a Win32 GLDOOM port in the works, by Jim Dose. -Quoting a recent posting by him: - -"I haven't had as much time lately to really work on -the conversion. I currently have the renderer drawing -the walls and floors as texture spans as the are in -the software renderer. There's lighting on the walls, -but not the floors, and sprites are being drawn, but -not with the right texture. I figure that this is one -nights work to get the game looking "normal". I haven't -tested the game on less than a p200, so I'm not sure -how it will perform under the average machine, but I -don't expect it to be blindingly fast because of the -number of spans that have to be drawn each frame. -Rendering as polys is definitely the way to go. - -The reason I chose to do spans first was because it -left the base renderer intact and I could concentrate -on ironing out any Windows compatibility problems. -Actually, the first version I had running was simply -a blit of the 320x200 game screen through Open GL. -Surprisingly, this actually was very playable, but -certainly wasn't taking any advantage of 3D acceleration. -Once the game was running, I started converting all -the span routines over." - -Comment: for merging Linuxdoom with Win32, this is -probably the best source for getting the Win32 -environment done - before more significant changes -occur. - -"One problem with drawing spans is that the engine -doesn't calculate the texture coordinates with -fractional accuracy, so the bilinear filtering works -vertically, but not horizontally on the walls. I may -try to fix this, but since I plan to use polys for -the final version, it's not really high priority. -Also, spans don't really allow for looking up and -down." - -Comment: true looking up/down vs. Heretic-style -y-shearing seems to require either a strange kind -of transofrmation matrix (he probably does not use -the OpenGL transformation at all), or rendering -all the spans as textured rectangular slices -instead of using glDrawBitmap. No, polys are the -way to go. - -"When I tackle the conversion to polys, one big problem -I'll encounter is drawing floors. Since the world is -stored in a 2D bsp tree, there is no information on -the shape of the floors. In fact the floors can be -concave and may include holes (typically, most renderers -break concave polys down into a collection of convex -polys or triangles). In software, the floors are actually -drawn using an algorithm that's similar to a flood fill -(except that a list of open spans is kept instead of a -buffer of pixels). This makes drawing the floors as -polys fairly difficult." - -A polygon based approach will require significant changes -to the data structures used in the refresh module. I -recommend either separating a libref_soft.so first (a -Quake2 like approach), and creating libref_gl afterwards, -or abandoning the software rendering entirely. - -John Carmack wrote once upon a time: -"... the U64 DOOM engine is much more what I would consider -The Right Thing now -- it turns the subsector boundaries -into polygons for the floors and ceilings ahead of time, -then for rendering it walks the BSP front to back, doing -visibility determination of subsectors by the one dimensional -occlusion buffer and clipping sprites into subsectors, then -it goes backwards through the visible subsectors, drawing -floors, ceilings, walls, then sorted internal sprite fragments. -It's a ton simpler and a ton faster, although it does suffer -some overdraw when a high subsector overlooks a low one (but -that is more than made up for by the simplicity of everything -else)." - -Well, IMO compiling a separate list of floor/ceiling polygons -after having read the WAD file, and thus introducing this as -a completely separate data structure to the current code base -might be the easiest thing to do. Jim Dose writes: - -"One method I may use to draw the floors as polys was suggested -by Billy Zelsnack of Rebel Boat Rocker when we were working -at 3D Realms together a few years ago. Basically, Billy was -designing an engine that dealt with the world in a 2D portal -format similar to the one that Build used, except that it had -true looking up and down (no shearing). Since floors were -basically implicit and could be concave, Billy drew them as -if the walls extended downwards to infinity, but fixed the -texture coordinates to appear that they were on the plane of -the floor. The effect was that you could look up and down and -there were no gaps or overdraw. It's a fairly clever method -and allows you to store the world in a simpler data format. -Had perspective texture mapping been fast enough back then, -both Build and Doom could have done this in software." - -Perhaps the above is sufficient to get you started. -Other Issues: - -1. Occlusion -DOOM uses a per-column lookup (top/bottom index) to do HLHSR. -This works fine with span based rendering (well, getting -horizontal spans of floors/ceilings into the picture is a -separate story). It isn't really mindboggling with polygon -based rendering. GLDOOM should abandon that. - -2. Precalculated Visibility -DOOM has the data used by Quake's PVS - in REJECT. -During Quake development, lots of replacements for the -occlusion buffer were tried, and PVS turned out to be best. -I suggest usind the REJECT as PVS. - -There have been special effects using a utility named RMB. -REJECT is a lump meant for enemy AI LoS calculation - a -nonstandard REJECT will not work as a PVS, and introduce -rendering errors. I suggest looking for a PVS lump in the -WAD, and using REJECT if none is found. That way, it might -be feasible to eat the cake and keep it. - -3. Mipmaps -DOOM does not have mipmapping. As we have 8bit palettized -textures, OpenGL mipmapping might not give the desired -results. Plus, composing textures from patches at runtime -would require runtime mipmapping. Precalculated mipmaps -in the WAD? - -4. Sprites -Partly transparent textures and sprites impose another -problem related to mipmapping. Without alpha channel, -this could give strange results. Precalculated, valid -sprite mipmaps (w/o alpha)? diff --git a/docs/commands.txt b/docs/commands.txt deleted file mode 100644 index 4dfd483f3..000000000 --- a/docs/commands.txt +++ /dev/null @@ -1,1742 +0,0 @@ -This document lists all commands and cvars supported by the current version -of ZDoom (1.22) and a short description of each. There are a total of 130 -commands and 141 cvars. -=========================================================================== - -There are five types of cvars: - -boolean: This is a number that can be either "0" or "1". "0" indicates no/ - false, and "1" indicates yes/true. - - color: This is a series of three hexadecimal numbers representing the - amounts of red, green, and blue (in that order) in a color. For - example, pure redwould be represented as "ffff 0000 0000". The - setcolor command can be used to set one of these cvars using a - color name instead of numbers. (See the description of the - setcolor command below.) - - number: This is an ordinary number. - - integer: This is an ordinary that doesn't take fractional values. - - string: This is a series of text characters enclosed in quotes. - - -Some commands also take parameters. Any parameters that are required are -enclosed in < >, and those that are optional are enclosed in [ ]. - - -ACTION COMMANDS -=============== -NOTE: As in Quake, all action commands come in pairs. When prefixed by a -'+', they activate the corresponding action, and when prefixed by a '-', -they deactivate that action. - - -+attack, -attack - While active, causes the player to fire his active weapon. - -+back, -back - While active, causes the player to move backward. -See also: +forward - -+forward, -forward - While active, causes the player to move forward. -See also: +back - -+jump, -jump - Causes the player to jump. When underwater, the player will swim upward - instead. -See also: +moveup - -+klook, -klook - While active, causes +forward and +back to act like +lookup and +lookdown - instead. -See also: +mlook, +lookup, +lookdown, +forward, +back - -+left, -left - While active, normally causes the player to turn to the left. However, as - long as +strafe is active, this will cause the player to move to the left - instead. -See also: +right, +strafe, +moveleft - -+lookdown, -lookdown - While active, causes the player to look down. -See also: +lookup, +klook - -+lookup, -lookup - While active, causes the player to look up. -See also: +lookdown, +klook - -+mlook, -mlook - While active, causes movement along the mouse's vertical axis to tilt the - player's view up or down instead of moving the player forward or backward. -See also: +klook, freelook, invertmouse, lookspring - -+movedown, -movedown - Moves the player down if swimming or flying. -See also: +moveup - -+moveleft, -moveleft - While active, causes the player to move to the left. -See also: +moveright, +left, +strafe - -+moveright, -moveright - While active, causes the player to move to the right. -See also: +moveleft, +right, +strafe - -+moveup, -moveup - Moves the player up if swimming or flying. -See also: +movedown - -+right, -right - While active, normally causes the player to turn to the right. However, as - long as +strafe is active, this will cause the player to move to the right - instead. -See alse: +left, +strafe, +moveright - -+showscores, -showscores - While this action is active and you are playing a deathmatch game, a list - of the frags made by all players will be displayed on the screen. In - deathmatch games, this list will also automatically be display when you - are dead. - -+speed, -speed - While active, all player movements occur at a rate faster than normal. -See also: cl_run - -+strafe, -strafe - While active, causes all +left and +right commands to act like +moveleft - and +moveright instead. -See also: +left, +right, +moveleft, +moveright - -+use, -use - While active, causes the player to attempt to use any usable items in - front of him/her (such as a door). - - -OTHER COMMANDS AND CVARS -======================== -addbot [name] -(command) - Spawns a bot. If a name is given, the corresponding bot in bots.cfg will be - spawned. Otherwise, a bot will be picked at random from bots.cfg. -See also: listbots, removebots - -alias -(command) - If specified with no parameters, will display a list of all current - aliases. If only is specified, it will be removed from the - list of aliases. If is also specified, it will be added - to the list of aliases as . For example, to create a new - command to kill the monsters on the level, you can use the command: - - alias massacre kill monsters - - Then, you can use the newly created massacre command to kill all the - monsters on the level. - -alwaysapplydmflags -(cvar: boolean) -default: 0 - Normally, some dmflags are only used in deathmatch. If alwaysapplydmflags - is 1, then they will also be used in single-player and co-op games. -See also: dmflags - -am_backcolor -(cvar: color) -default: "6c 54 40" (a light tan) - The color of the automap background. Changes to this cvar take effect the - next time the automap is activated. -See also: all the am_* cvars - -am_cdwallcolor -(cvar: color) -default: "4c 38 20" (a dark tan) - The color of two-sided lines that have a different ceiling height on each - side. Changes to this cvar take effect the next time the automap is - activated. -See also: all the am_* cvars - -am_fdwallcolor -(cvar: color) -default: "88 70 58" (a lighter tan) - The color of two-sided lines that have a different floor height on each - side. Changes to this cvar take effect the next time the automap is - activated. -See also: all the am_* cvars - -am_gridcolor -(cvar: color) -default: "8b 5a 2b" (tan4) - The color of the automap grid. Changes to this cvar take effect the next - time the automap is activated. -See also: all the am_* cvars - -am_interlevelcolor -(cvar: color) -default: "ff 00 00" (red) - The color of inter-level teleporters. These are teleporters that teleport - you to a different map. Changes to this cvar take effect the next time the - automap is activated. -See also: all the am_* cvars - -am_intralevelcolor -(cvar: color) -default: "00 00 ff" (blue) - The color of intra-level teleporters. These are teleporters that teleport - you to a different location on the same map. Changes to this cvar take - effect the next time the automap is activated. -See also: all the am_* cvars - -am_lockedcolor -(cvar: color) -default: "00 00 98" (a blue) - The color of lines that open locked doors. Changes to this cvar take - effetc the next time the automap is activated. -See also: all the am_* cvars - -am_notseencolor -(cvar: color) -default: "6c 6c 6c" (somewhat dark gray) - The color of lines on the automap that haven't yet been seen. Visible with - a computer area map. Changes to this cvar take effect the next time the - automap is activated. -See also: all the am_* cvars - -am_overlay -(cvar: boolean) -default: 0 - Normally, the togglemap command switches the automap between fully off and - fully on. Setting this cvar to "1" will cause togglemap to draw the - automap on top of the player's view before it draws the automap - fullscreen. (Bad description, I know. Just try it) -See also: am_rotate, togglemap - -am_ovotherwallscolor -(cvar: color) -default: "00 88 44" (a dark blueish-green) - The color of passable lines on the automap when the map is overlayed. - Changes to this cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -ov_telecolor -(cvar: color) -default: "ff ff 00" (a bright green) - The color of teleports on the overlayed automap. Changes to this cvar take - effect the next time the automap is activated. -See also: all the am_* cvars - -am_ovthingcolor -(cvar: color) -default: "e8 88 00" (an orange) - The color of things visible with the automap cheat when the map is - overlayed. Changes to this cvar take effect the next time the automap is - activated. -See also: all the am_* cvars - -am_ovunseencolor -(cvar: color) -default: "00 22 6e" (a dark greenish-blue) - The color of unseen lines on the automap when the map is overlayed. - Changes to this cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -am_ovwallcolor -(cvar: color) -default: "00 ff 00" (a bright green) - The color of impassable walls when the automap is overlayed. Changes to - this cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -am_ovyourcolor -(cvar: color) -default: "fc e8 d8" (a very light orange--almost white) - The color of the arrow representing the player in single player games when - the map is overlayed. Changes to this cvar take effect the next time the - automap is activated. -See also: all the am_* cvars - -am_rotate -(cvar: boolean) -default: 0 - Normally, the automap is always drawn such that north is at the top of the - screen. Setting this cvar to "1" causes the automap to be drawn so that - lines toward the top of the screen are always directly in front of the - player's view. Changes to this cvar take effect immediately, unlike most - of the other am_* cvars. This can be particularly useful when the automap - is overlayed. -See also: am_overlay - -am_showmonsters -(cvar: boolean) -default: 1 - When true, the fullscreen automap will display a count of the number of - monsters that have been killed in the current level and the total number - of monsters in the level. -See also: am_showtime, am_showsecrets - -am_showsecrets -(cvar: boolean) -default: 1 - When true, the fullscreen automap will display a count of the number of - secrets that have been found in the current level and the total number of - secrets in the level. -See also: am_showmonsters, am_showtime - -am_showtime -(cvar: boolean) -default: 1 - When true, the fullscreen automap will display the total amount of time - you have been in a level (excluding time that has been paused). -See also: am_showmonsters, am_showsecrets - -am_thingcolor -(cvar: color) -default: "fcfc fcfc fcfc" (almost white) - The color of things revealed with the map cheat. Changes to this cvar take - effect the next time the automap is activated. -See also: all the am_* cvars - -am_tswallcolor -(cvar: color) -default: "8888 8888 8888" (gray) - The color of two-sided lines that don't have any difference in floor or - ceiling heights on either side. Only seen using map cheat. Changes to this - cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -am_usecustomcolors -(cvar: boolean) -default: 1 - When true, the automap uses the colors specified by the am_* cvars, - otherwise it uses the standard DOOM automap colors. Changes to this cvar - take effect the next time the automap is activated. -See also: all the am_* cvars - -am_wallcolor -(cvar: color) -default: "2c2c 1818 0808" (a dark brown) - The color of one-sided and secret walls in the automap. Changes to this - cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -am_xhaircolor -(cvar: color) -default: "8080 8080 8080" (gray) - The color of the "crosshair" dot in the center of the automap. Changes to - this cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -am_yourcolor -(cvar: color) -default: "fcfc e8e8 d8d8" (a very light orange--almost white) - The color of the arrow representing the player in single player games. - Changes to this cvar take effect the next time the automap is activated. -See also: all the am_* cvars - -autoaim -(cvar: number) -default: 5000 - This represents the vertical distance from an object that the player's - sight must be before that object is aimed at. Setting this cvar to "0" - disables autoaiming, while large values such as "5000" will reproduce the - original DOOM behavior of always autoaiming. -See also: color, name - -autoexec -(cvar: string) -default: "/autoexec.cfg" - This is a file that will be automatically executed by ZDoom each time it - starts. This file is executed immediately after the config file is loaded. - It should contain a series of console commands. C++ style comments are - also supported. Comments begin with // and anything after them until the - end of the line will be ignored. - - represents the directory that ZDoom is in and will naturally - vary depending on where you put it. - -bind [key [command string]] -(command) - If no parameters are specified, the entire list of bound keys will be - printed to the console. If only [key] is specified, the binding for that - specific key will be printed. If both [key] and [command string] are - specified, [command string] will be bound to [key]. -See also: doublebind, unbind, unbindall, undoublebind - -binddefaults -(command) - Binds all keys to their default commands. This will not unbind any keys - that do not have any default bindings, so if you want to properly restore - the default controls, you need to use unbindall first. -See also: unbindall, bind - -bot_allowspy -(cvar: boolean) -default: 0 - Allows you to see through the eyes of bots during botmatch games. - -bot_next_color -(cvar: number) -default: 11 - Theoretically, a number representing the color of the next bot to be - spawned. In practice, it doesn't do anything. - -bot_observer -(cvar: boolean) -default: 0 - When set to 1, the player will experience minimal interaction with the - world, and bots will ignore him. - -bumpgamma -(command) - Increases the current gamma level by 0.1. If the new gamma level would be - greater than 3.0, it wraps the gamma around to 1.0 -See also: gamma - -centerview -(command) - Causes the player to look straight ahead. -See also: +lookup, +lookdown - -changemap -(command) - Exits the current level and continues the game on the specified map. - Unlike the map and idclev commands, this command *will* work properly - during network games and is recorded in demos. Unfortunately, it has - occasionally resulted in some problems. It should, however, be safe - enough to use most of the time. -See also: idclev, map - -changemus -(command) - Changes the currently playing music. should be the name of a music - lump or file on disk (which need not have been specified with the -file - parameter). -See also: dir, idmus - -chase -(command) - Turns the chasecom on and off. This command also works while watching - demos, so you can bind it to a key and watch demos in the third person. -See also: chase_dist, chase_height, chasedemo - -chase_dist -(cvar: number) -default: 90 - This is how far away from the player the chasecam likes to be, but it will - get closer as necessary to avoid going inside walls. -See also: chase, chase_height - -chase_height -(cvar: number) -default: -8 - This is the base height above the top of the player's head that the - chasecam will be positioned at. Looking up and down will move the camera - in the opposite direction so that the player stays at approximately the - same height on the screen. Large values of this cvar (either positive or - negative) will produce strange output. -See also: chase, chase_dist - -chasedemo -(cvar: boolean) -default: 0 - If this cvar is true, then demos will automatically start with the - chasecam active. -See also: chase - -chatmacro0 -chatmacro1 -chatmacro2 -chatmacro3 -chatmacro4 -chatmacro5 -chatmacro6 -chatmacro7 -chatmacro8 -chatmacro9 -(cvar: string) - These are all strings programmable to the function keys during a netgame. - To use these, enter chat mode with the messagemode command, and then hold - down Alt and press one of the number keys. The string stored in the - corresponding chatmacro cvar will be sent as if you had typed it yourself. - -cl_bloodtype -(cvar: number) -default: 0 - Controls how blood is drawn. Supported values are: - 0: Blood is drawn as sprites - 1: Blood is drawn as both sprites and particles - 2: Blood is drawn as particles - -cl_pufftype -(cvar: number) -default: 0 - Controls how bullet puffs are drawn. Supported values are: - 0: Puffs are drawn as sprites. - 1: Puffs are drawn as particles. - -cl_rockettrails -(cvar: boolean) -default: 1 - Controls whether or not rockets leave trails of smoke behind them. - -cl_run -(cvar: boolean) -default: 0 - When non-zero, the game will always treat movement commands as if +speed - is active. -See also: +speed - -clear -(command) - Clears the console of all text. - -cmdlist -(command) - Lists all commands currently supported by ZDoom. -See also: cvarlist - -color -(cvar: color) -default: "4040 cfcf 0000" (Mostly green) - This is the color of your player's suit. -See also: gender, name, skin, team - -con_midtime -(cvar: number) -default: 3 - This is the number of seconds that messages in the middle of the screen - will be displayed before they dispapper. -See also: con_notifytime - -con_notifytime -(cvar: number) -default: 3 - This is the number of seconds that new messages will stay at the top of - the screen before they start scrolling away. -See also: con_midtime - -con_scaletext -(cvar: boolean) -default: 0 - If this cvar is true, then message text will be scaled to larger sizes - depending on the screen resolution so that it will stay approximately the - same size it would be on a 320x200 screen. - -configver -(cvar: number) -default: "116" - This cvar is used to keep track of which version of ZDoom was used to write - the current config file and adjust for differences that may have been - introduced between versions. Changing it has no effect, since it will - always be changed to reflect the current game version before the config - file is saved. - -crosshair -(cvar: number) -default: 0 - If this cvar is non-zero, it draws a crosshair. If this cvar is negative, - the crosshair is translucent, otherwise it is opaque. The specific - crosshair drawn depends on the value of this cvar. - -cvarlist -(command) - Lists the values of all currently defined cvars. Each cvar can also be - prefaced by multiple flags. These are: - - A Cvar gets saved in the config file. - U Cvar contains user info. - S Cvar contains server info. - - Cvar can only be changed from the command line. - L Changes to cvar's contents don't take effect until the next game. - C Cvar has an internal callback. - * Cvar was created by the user and is meaningless to the game. - -See also: cmdlist, get, set - -deathmatch -(cvar: boolean) -default: 0 - When true, deathmatch rules are used for the game. - -def_patch -(cvar: string) -default: "" - This is the name of a DeHackEd patch file to automatically apply each time - the game is run. It will only be used if the following conditions are met: - - a) def_patch is not "", and the file exists. - b) No loaded WAD files contain a DEHACKED lump. - c) No patch is specified with the -deh command line parameter. - -developer -(cvar: boolean) -default: 0 - When true, prints various debugging messages to the console. - -dimamount -(cvar: number) -default: 1 - This is the amount of dimcolor to mix with the background when a menu is - displayed. The available values are: - 0: Do not dim the background. - 1: Mix 25% of dimcolor with the background. - 2: Mix 50% of dimcolor with the background. - 3: Mix 75% of dimcolor with the background. -See also: dimcolor - -dimcolor -(cvar: color) -default: "ffff d7d7 0000" (gold) - This is the color to mix with the background when a menu is displayed. -See also: dimamount, setcolor - -dir [[path/][pattern]] -(command) - This command lists the contents of a directory. It supports wildcards (but - will not recurse into multiple directories). If [path] is not specified, - it will display the contents of the directory the game was run from. - -deathmatch -(cvar: boolean) -default: 0 - When set to true, the game is treated as a deathmatch. When the game is - started with -altdeath or -deathmatch, this cvar is automatically set to 1. - -dmflags -(cvar: number) -default: 0 - This cvar controls the behavior of several aspects of gameplay. To - determine what value to store in this cvar, select the desired features - from the table below and add their values together. If a feature is - marked with (DM), then that feature will only be active during a - deathmatch game. - - Value Description - ------ ----------------------------------------------------------------- - 1 Do not spawn health items (DM) - 2 Do not spawn powerups (DM) - 4 Leave weapons around after pickup (DM) - 8 Falling too far hurts - 16 Players cannot hurt teammates (friendly fire avoidance) - 64 Stay on the same map when someone exits (DM) - 128 Spawn players as far as possible from other players (DM) - 256 Automatically respawn dead players (DM) - 512 Do not spawn armor (DM) - 1024 Kill anyone who tries to exit the level (DM) - 2048 Don't use any ammo when firing - 4096 Don't spawn monsters - 8192 Monsters respawn sometime after their death - 16384 Powerups other than invulnerability and invisibilty respawn - 32768 Monsters are fast - 65536 Don't allow jumping - 131072 Don't allow freelook - 262144 Invulnerability and invisibility respawn - -See also: menu_gameplay, teamplay - -doublebind [key [command string]] -(command) - If no parameters are specified, the entire list of doublebound keys will be - printed to the console. If only [key] is specified, the doublebinding for - that specific key will be printed. If both [key] and [command string] are - specified, [command string] will be doublebound to [key]. (Doublebindings - are commands that are executed when a key is pressed twice quickly--such as - double cliking a mouse button.) -See also: bind, unbind, unbindall, undoublebind - -dumpheap -(command) - Prints detailed information about the heap. Probably not very useful to - the average user. -See also: mem - -echo -(command) - Prints to the console. - -endgame -(command) - Ends the current single player game and drops the console down to cover the - screen. -See also: menu_endgame - -error -(command) - Simulates an error by killing the current game and falling back to the - fullscreen console with the specified message. - -exec