Remove outdated and redundant files from the docs folder, and added the GZDoom license file.

This commit is contained in:
nashmuhandes 2016-04-27 22:36:19 +08:00
parent 05aae38031
commit 0ab4a4a349
11 changed files with 32 additions and 29530 deletions

View file

@ -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)

32
docs/GZDoom License.md Normal file
View file

@ -0,0 +1,32 @@
GZDoom License
==============
Copyright 2004-2009 Christoph Oelckers
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
4. When not used as part of GZDoom or a GZDoom derivative, this code will be
covered by the terms of the GNU Lesser General Public License as published
by the Free Software Foundation; either version 2.1 of the License, or (at
your option) any later version.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

View file

@ -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

View file

@ -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)?

File diff suppressed because it is too large Load diff

View file

@ -1,162 +0,0 @@
DT
{
font-weight: bold;
}
DD
{
margin-bottom: 1em;
margin-left: 1.5em;
margin-right: 1.5em;
}
TH
{
text-align: left;
font-weight: bold;
padding-right: 2em;
vertical-align: top;
}
TD
{
text-align: left;
}
/* Command Descriptions */
DIV.c
{
border-right: 2px solid;
padding-right: 0.4em;
border-top: 1px solid;
margin-top: 1em;
padding-left: 0.4em;
font-weight: bold;
padding-bottom: 0.2em;
border-left: 1px solid;
padding-top: 0.2em;
border-bottom: 1px solid;
background-color: rgb(152,251,152);
margin-bottom: 0px;
}
DIV.b
{
border-right: 2px solid;
padding-right: 1.2em;
border-top: 1px;
padding-left: 1.2em;
padding-bottom: 0.5em;
border-left: 1px solid;
padding-top: 0.5em;
border-bottom: 2px solid;
background-color: rgb(240,255,240);
margin-top: 0px;
}
/* Variable Descriptions */
DIV.v, DIV.vf
{
border-right: 2px solid;
padding-right: 0.4em;
border-top: 1px solid;
margin-top: 1em;
padding-left: 0.4em;
font-weight: bold;
padding-bottom: 0.2em;
border-left: 1px solid;
padding-top: 0.2em;
border-bottom: 1px solid;
background-color: rgb(175,238,238);
}
DIV.vf
{
background-color: rgb(175,200,238);
}
DIV.t, DIV.tf
{
border-right: 2px solid;
padding-right: 1.2em;
border-top: 1px;
padding-left: 0.9em;
padding-bottom: 0.2em;
border-left: 1px solid;
padding-top: 0.2em;
border-bottom: 1px solid;
background-color: rgb(224,255,255);
}
DIV.tf
{
background-color: rgb(224,238,255);
}
DIV.d, DIV.df
{
border-right: 2px solid;
padding-right: 1.2em;
border-top: 2px;
padding-left: 1.2em;
padding-bottom: 0.5em;
border-left: 1px solid;
padding-top: 0.5em;
border-bottom: 2px solid;
background-color: rgb(240,255,255);
}
DIV.df
{
background-color: rgb(240,248,255);
}
P
{
margin-top: 1em;
margin-bottom: 0em;
}
A
{
color: Blue;
text-decoration: none;
}
A:hover
{
text-decoration: underline;
}
H1, H2
{
font-weight: bold;
left: -0.8em;
font-family: Verdana, Arial, Helvetica, Sans-Serif;
position: relative;
}
H3, H4
{
font-weight: bold;
font-family: Verdana, Arial, Helvetica, Sans-Serif;
left: 0em;
}
BODY
{
margin: 2em 2em 2em 2em;
background-color: white;
}
PRE
{
border: ridge 2px;
background-color: rgb(210,210,210);
padding: 1em 1em 1em 1em;
}
DIV.index
{
padding-right: 0.8em;
padding-left: 0.8em;
left: 0px;
float: left;
padding-bottom: 1em;
overflow: auto;
clip: rect(auto,auto,auto,auto);
padding-top: 0.5em;
position: absolute;
top: 0px;
background-color: #ffffcc;
border-right: solid 1px #808080;
border-bottom: solid 1px #808080;
}
DIV.main
{
margin-left: 11em;
height: 50%;
}

File diff suppressed because it is too large Load diff

View file

@ -1,112 +0,0 @@
LIMITED USE SOFTWARE LICENSE AGREEMENT
This Limited Use Software License Agreement (the "Agreement")
is a legal agreement between you, the end-user, and Id Software, Inc.
("ID"). By downloading or purchasing the software material, which
includes source code (the "Source Code"), artwork data, music and
software tools (collectively, the "Software"), you are agreeing to
be bound by the terms of this Agreement. If you do not agree to the
terms of this Agreement, promptly destroy the Software you may have
downloaded or copied.
ID SOFTWARE LICENSE
1. Grant of License. ID grants to you the right to use the
Software. You have no ownership or proprietary rights in or to the
Software, or the Trademark. For purposes of this section, "use" means
loading the Software into RAM, as well as installation on a hard disk
or other storage device. The Software, together with any archive copy
thereof, shall be destroyed when no longer used in accordance with
this Agreement, or when the right to use the Software is terminated.
You agree that the Software will not be shipped, transferred or
exported into any country in violation of the U.S. Export
Administration Act (or any other law governing such matters) and that
you will not utilize, in any other manner, the Software in violation
of any applicable law.
2. Permitted Uses. For educational purposes only, you, the
end-user, may use portions of the Source Code, such as particular
routines, to develop your own software, but may not duplicate the
Source Code, except as noted in paragraph 4. The limited right
referenced in the preceding sentence is hereinafter referred to as
"Educational Use." By so exercising the Educational Use right you
shall not obtain any ownership, copyright, proprietary or other
interest in or to the Source Code, or any portion of the Source
Code. You may dispose of your own software in your sole discretion.
With the exception of the Educational Use right, you may not
otherwise use the Software, or an portion of the Software, which
includes the Source Code, for commercial gain.
3. Prohibited Uses: Under no circumstances shall you, the
end-user, be permitted, allowed or authorized to commercially exploit
the Software. Neither you nor anyone at your direction shall do any
of the following acts with regard to the Software, or any portion
thereof:
Rent;
Sell;
Lease;
Offer on a pay-per-play basis;
Distribute for money or any other consideration; or
In any other manner and through any medium whatsoever
commercially exploit or use for any commercial purpose.
Notwithstanding the foregoing prohibitions, you may commercially
exploit the software you develop by exercising the Educational Use
right, referenced in paragraph 2. hereinabove.
4. Copyright. The Software and all copyrights related thereto
(including all characters and other images generated by the Software
or depicted in the Software) are owned by ID and is protected by
United States copyright laws and international treaty provisions.
Id shall retain exclusive ownership and copyright in and to the
Software and all portions of the Software and you shall have no
ownership or other proprietary interest in such materials. You must
treat the Software like any other copyrighted material. You may not
otherwise reproduce, copy or disclose to others, in whole or in any
part, the Software. You may not copy the written materials
accompanying the Software. You agree to use your best efforts to
see that any user of the Software licensed hereunder complies with
this Agreement.
5. NO WARRANTIES. ID DISCLAIMS ALL WARRANTIES, BOTH EXPRESS
IMPLIED, INCLUDING BUT NOT LIMITED TO, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT
TO THE SOFTWARE. THIS LIMITED WARRANTY GIVES YOU SPECIFIC LEGAL
RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY FROM JURISDICTION TO
JURISDICTION. ID DOES NOT WARRANT THAT THE OPERATION OF THE SOFTWARE
WILL BE UNINTERRUPTED, ERROR FREE OR MEET YOUR SPECIFIC REQUIREMENTS.
THE WARRANTY SET FORTH ABOVE IS IN LIEU OF ALL OTHER EXPRESS
WARRANTIES WHETHER ORAL OR WRITTEN. THE AGENTS, EMPLOYEES,
DISTRIBUTORS, AND DEALERS OF ID ARE NOT AUTHORIZED TO MAKE
MODIFICATIONS TO THIS WARRANTY, OR ADDITIONAL WARRANTIES ON BEHALF
OF ID.
Exclusive Remedies. The Software is being offered to you
free of any charge. You agree that you have no remedy against ID, its
affiliates, contractors, suppliers, and agents for loss or damage
caused by any defect or failure in the Software regardless of the form
of action, whether in contract, tort, includinegligence, strict
liability or otherwise, with regard to the Software. This Agreement
shall be construed in accordance with and governed by the laws of the
State of Texas. Copyright and other proprietary matters will be
governed by United States laws and international treaties. IN ANY
CASE, ID SHALL NOT BE LIABLE FOR LOSS OF DATA, LOSS OF PROFITS, LOST
SAVINGS, SPECIAL, INCIDENTAL, CONSEQUENTIAL, INDIRECT OR OTHER
SIMILAR DAMAGES ARISING FROM BREACH OF WARRANTY, BREACH OF CONTRACT,
NEGLIGENCE, OR OTHER LEGAL THEORY EVEN IF ID OR ITS AGENT HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY
OTHER PARTY. Some jurisdictions do not allow the exclusion or
limitation of incidental or consequential damages, so the above
limitation or exclusion may not apply to you.

View file

@ -1,534 +0,0 @@
ZDoom Release History
More detailed info can be found in the file docs/rh-log.txt included with
the source code.
1.22 (12 December 1999)
=======================
* Scroll_Texture_Both and TranslucentLine specials can now be used from ACS.
* Fixed compiler-dependent cvar ordering during netgame arbitration.
* Fixed certain polyobject movement combinations that would not stop even
though they were supposed to.
* Did some cleanup for Alpha processors.
1.21 (26 November 1999)
=======================
* Fixed problems with thinkers removing themselves and causing other thinkers
to not get a chance to think.
* Added hud_scale cvar.
1.20 (25 November 1999)
=======================
* Fixed saving, reloading, and then resaving games when travelling between
levels in a hub.
* Fixed saving of ACS scripts scheduled to occur on a future level.
1.19 (24 November 1999)
=======================
* DeHackEd patches that set an actor's death sound to 0 without removing
the A_Scream call no longer crash.
* Fixed sync problems when playing with bullet puffs as particles vs as
sprites.
* Fixed friction when walking on the bottom of swimmable water.
* Added Jeffrey Cuenco's fixes to get -host and -join to work properly.
* Fixed BOOM generalized locked doors so that the open/close type will
actually close.
* Added pointer tracking and cleanup. This should fix the occasional
crashes when saving games and various other anomalies.
1.18b (15 September 1999)
=========================
* Fixed crash when saving games with more than 1024 objects.
* Fixed crash when loading a game without starting a new one first.
* Reduced the size and frequency of pregame network packets, under the
assumption that problems people were having using 1.18 on the Internet
are a result of limited modem bandwidth.
1.18a (12 September 1999)
=========================
* Fixed liquid warping temporarily stopping when changing levels.
* +/-mlook commands do not generate unknown command messages.
* Fixed support for maps with >10 deathmatch starts. Thanks to Roman
Hatsiev.
* Fixed support for the special "maps" EndGame? in MAPINFO lumps.
* Teleport destination (no gravity) now works as intended.
* Hopefully fixed savegame problems.
* Bots are restored from savegames.
* Fixed keyboard turning speed when -dup is used.
* Network commands get executed only once when -dup is used.
* In sectors with damaging floors and swimmable deep water, the damage
will also be applied while the player is swimming and not just when
the player is on the ground.
1.18 (5 September 1999)
=======================
* Replaced the older Cajun 0.71 with Cajun 0.97.
* Fixed handling of status bar faces with skins that provide them.
* Added swimmable water.
* Messages printed to the middle of the screen also print to the console.
* Skill and other server cvars get saved in savegames again.
* Added liquid texture warping.
* Bad MAPINFO lumps generate error messages instead of hanging.
* Realized that it's impossible to guarantee that all object pointers will
be valid without some effort, so FArchive saves DObject objects as NULL
objects now instead of aborting with an error.
* Added the ACS built-in functions localambientsound, activatorsound, and
setlinemonsterblocking.
* Added a thing that does nothing but count toward the number of secrets.
* Added a fly mode.
* Finally implemented the +moveup and +movedown commands.
118test10-source only (14 August 1999)
======================================
* Reimplemented hub travel.
* Optimized R_MapPlane slightly.
* Added fov command.
* Added vertical sub-pixel accuracy to the renderer.
* Added searches for an IWAD in the current directory, $DOOMWADDIR, and
$HOME.
118test9 (9 August 1999)
========================
* Fixed the "wild" bot spinning problem.
* Commands like changemap that could make network games go out of sync
should work properly now. The reason they would do that is closely related
to the reason that the bots would start spinning.
* Finished the serializer. Now savegames work. Hubs don't, because I haven't
written the player travelling code yet.
* Various other code cleanup.
118test8 (20 July 1999)
=======================
* Fixed a crash problem with the "burn" screen wipe.
* Fixed a crash problem with playing non-assigned sound sequences.
* Fixed a crash problem related to trying to shutdown the music subsystem
twice.
* If you try to add more coop bots than there are coop starts, the extra
bot leaves quietly instead of ending the game.
* Weapondrop is now a "server" cvar, which it should have been in the
first place.
* Changed the nodetable file format to be more compact.
* Bots can now be recorded in demos.
* Bots work in multiplayer games. Still buggy. Spawning bots can cause
consistancy failures, and they can start spinning wildly.
118test7 (12 July 1999)
=======================
* Fixed handling of maps with scrolling walls.
* Single player works again. In test6, all games were considered either coop
or deathmatch.
* Disabled the bot thinking code in single player games, so you don't suffer
a performance hitwhen not using bots.
* Added some performance counters accessible through the stat command.
118test6 (10 July 1999)
=======================
* Rewrote the wu line drawer to look better (especially in overlay mode).
* Stretched skies now get stretched horizontally as well as vertically.
* Did an initial integration of the Cajun Bot 0.71 code.
118test5 (6 July 1999)
======================
* Fixed a potential infinite loop that was introduced in 118test1.
* Delayed the initial execution of cvar callbacks.
* Added Heretic's anti-aliased Wu line drawer to the automap.
118test4 (3 July 1999)
======================
* Fixed the "Bad DCanvas::CopyRect" problem introduced in test3.
* Fixed sound sequences that should not be cut off when stopped (such as
the standard doors).
118test3 (2 July 1999)
======================
* Removed unnecessary display mode switches.
* Created a DCanvas class to encapsulate most 2D rendering.
118test2 (1 July 1999)
======================
* Fixed vertical aim clipping (BFG works again).
* Fixed monster wandering.
* Maps with mapthings of type 0 no longer generate warning messages.
* Crushers that do no damage no longer act as if they inflict pain to
actors.
* The alias command lists aliases again.
* Aliases are saved to the config file again.
118test1 (30 June 1999)
=======================
* Tweaked the optimized renderer for fifth-generation processors.
* Added the following specials:
- Line_AlignFloor
- Line_AlignCeiling
- Sector_SetRotation
- Sector_SetCeilingPanning
- Sector_SetFloorPanning
- Secter_SetCeilingScale
- Sector_SetFloorScale
* Added an additional parameter to the Transfer_Heights special.
* Switched to the OpenPTC library for display.
* Converted lots of code to an object-oriented C++ architecture.
1.17c (5 May 1999)
==================
* Fixed game saving crashes on maps with wind/current effects.
* In deep water sectors, the underwater light and fog colors can now be
set independently of the area above water.
* Added nojump, allowjump, nofreelook, and allowfreelook keywords for
use in MAPINFO lumps.
* The random number seed now changes each time you run the program.
1.17b (15 March 1999)
=====================
1.17b contains some minor bug fixes over 1.17 and 1.17a. It also loads
faster because the sprite dimensions are not cached until they are
actually needed. There are also some other internal changes in
preparation for supporting Heretic and Hexen, but those don't affect
the user yet.
1.17a (21 February 1999)
========================
1.17a is mostly minor bug fixes and was released because Herian 2 needed
some of those fixes. There are a few new features, however:
* If you have a skins directory in the same directory as zdoom.exe,
every wad file in it will be automatically loaded when the game starts.
This way, you don't have to load your skins by hand to use them.
* New formatting options for text printed using ACS.
* A code pointer to make monsters fire a railgun.
1.17 (17 February 1999)
=======================
* I'm releasing both DOS and Win32 versions simultaneously. (The DOS version
does not support MIDI/MUS music or a joystick.)
Bug fixes:
* Multiplayer games with monsters do not crash.
* Player corpses do not levitate and then fall down when a player respawns
in multiplayer games.
* Using togglemap outside of a game will not crash.
* Monsters stop attacking their target once it's dead.
* EV_StopPlat() does not get stuck in an infinite loop if there are moving
platforms.
* Partially invisible players are drawn the proper colors (instead of
green) if r_drawfuzz is 0.
* If you are invisible, so are your muzzle flashes.
* Trying to execute a non-existant script will not crash.
* Using a ChangeCamera special from an open script will not crash.
* The FloorAndCeiling_RaiseByValue and FloorAndCeiling_LowerByValues now
behave like Hexen's.
* Using -loadgame from the command line works.
* Fixed a memory leak during generation of the translucency tables.
* In high resolutions, weapon sprites meet the bottom of the screen.
* Sounds will not cut out mysteriously when there is no reason for them to
do so.
* Sounds will also not be stopped immediately when a thing is removed, so
explosion sounds will play to their full length.
* Things can make more than one sound at once.
* The deathmatch scoreboard is aligned properly at high resolutions.
* Spynext and spyprev work properly instead of leaving the status bar
"lagging behind" the player being viewed.
* The light-amp does not disable colored lighting.
* The sky gets inverted when using the invulnerability powerup.
* Implemented better z-checking code (from Heretic/Hexen).
* Pain elementals will spawn one lost soul at a time instead of two inside
of each other.
* Bex patches that use thing mnemonics really do work now, and unknown bit
messages aren't generated for regular DeHackEd patches.
* Linedef type 134 for regular DOOM/BOOM maps requires a red key for
activation (it was being improperly translated to require a blue one).
* Monsters can activate secret lines when they cross them. (See DOOM2/MAP08).
* The player extreme death sound is used.
* When a player leaves a network game, their body is removed instead of
being left empty.
* 0-length sounds are treated as empty sounds instead of sounds 4 gigs long.
* Skins that replaced player sounds with sounds in the IWAD work.
* Muzzle flashes do not light up foggy areas, and fullbright sprites stay
shrouded in fog.
* Alphanumeric keys no longer automatically repeat on the console.
* Wads such as gothicdm2 that used new flats in addition to the ones in the
IWAD with the regular doom.exe work.
New features:
* Significant speed improvements on modern processors.
* Armor and keys are shown on the fullscreen HUD.
* Colored text.
* A playdemo console command.
* A chasecam.
* A particle sytsem.
* An optional railgun to show off the particle system. (Start the game with
-deh railgun.bex if you want to use it.)
New features interesting for wad authors:
* Polyobjects.
* Sound sequences.
* WAVE files can be used as sound lumps without converting them to DMX's
format first.
* A sky can be specified to not be stretched even if it is shorter than 200
pixels.
* Sparks.
* Particle fountains.
* Parallax skies.
* Some new DeHackEd thing flags from Hexen (bobbing, reflective, etc.).
1.16 (22 December 1998)
=======================
Bug fixes:
* No more limit on size of savegames or demos.
* Screen resolutions above 320x200 are now the proper brightness (they were
too bright before.)
* Improved the brightness of the console font.
* Bullet puffs can show up on the floor and ceiling and not just walls.
* Missile weapons can trigger gun activation lines.
* Barrels now bounce around as much as they did in original DOOM. (They were
too "inert" in 1.14.)
* If a demo is being recorded, quitting the game normally will save the demo
to disk. (Previously, you had to use the stop command to do this.)
New features for players:
* Proper support for BOOM maps.
* Mouse wheel support and weapnext/weapprev commands.
* Doublebindings.
* Better analog joystick support.
* 180 degree turn command for keyboarders.
* Damage done by a rocket to its shooter is configurable and defaults to the
original Doom behavior.
* User-configurable gender. (Even though I don't have any new player sounds,
at least the obituaries are gender-aware. :-)
* Teamplay mode.
* New cvar to disable manual aiming of the BFG to prevent someone from
shooting it at the floor and quickly triggering tracer damage before.
* Maps no longer need to have as many deathmatch starts as there are players
in a deathmatch game.
* Support for Doom Legacy skins.
* Rewrote the MIDI/MUS code so that it has a working volume control.
* Many more console commands and cvars.
New features for editors:
* Proper support for BOOM maps.
* Obituaries are configurable with a .bex patch.
* Moster paths
* Colored lighting
* Fog can be applied to only part of a level instead of all of it.
* Per-sector gravity settings.
* Support for up to 256 ambient sounds (as opposed to the limit of 64 in
earlier versions).
* Sector damage adjustable from between 0-255 points of damage.
* Changable camera views.
* The following editing features that were introduced in Hexen are also
available in ZDoom:
- Most line specials take arguments that modify their behavior.
- ACS scripting.
- Hubs.
- Earthquakes.
- Dormant monsters.
- Trigger events to happen on monster deaths.
- "Waggling" floors.
- Pillar builders.
- Push activation lines (walking into a wall can trigger an event).
- Thing spawning (e.g. for traps/gifts).
1.14a (27 July 1998)
====================
Bugs fixed are:
* No more crashing about freeing a pointer without ZONEID when changing
levels.
* Skies wider than 256 pixels are drawn correctly.
* Monsters' heights are once again the same as they were in id's original
DOOM, so certain areas work properly again.
* Monsters shouldn't teleport into each other anymore.
* Improved support for international keyboards.
* The skill level chosen for a new game is no longer ignored if the new
game is started while a demo is playing.
Cosmetic changes:
* No more "sv_gravity changed to...", "skill changed to...", etc. messages
in single player games.
* Activating the player setup menu automatically stops any playing demos,
since it doesn't work properly while they play.
* Barrels don't go flying away when exploding anymore.
* Added def_patch cvar to automatically load a DeHackEd patch each time the
game is started.
* ZDoom save games now use the name zdoomsv?.dsg instead of doomsav?.dsg.
This version also includes some preliminary BOOM support as I started
integrating some of the BOOM source code with ZDoom:
* Medusa fix.
* Openings limit removed.
* Removed limit on switches and animations.
* Added support for BOOM-like ANIMATED and SWITCHES lumps in PWADs.
* Added support for BOOM-style scrollers (including conveyors).
* Added partial deep-water support.
1.14 (14 July 1998)
===================
Bugs fixed:
* The bunny scroller at the end of E3M8 no longer crashes the game.
* The IDKFA cheat gives the proper amount of armor again.
* Demo recording works again.
* Telefragging works again.
* Picking up the invulnerability sphere displays the correct colors now.
* DeHackEd patches containing text replacements no longer crash the game.
* Printing a string containing "%s" to the console and then changing the
video mode will no longer crash the game.
* Chat mode finally works again.
* If MIDAS can't initialize, you can still play the game but without sound.
* Pistol and chaingun sounds no longer cut out when there are lots of
zombie men shooting their pistols at you.
* Mouse input should no longer be so jerky under Windows NT.
* The crosshair is finally accurate for aiming.
* Autoaim is properly remembered each time you start ZDoom.
* Switches in the Ultimate Doom that aren't also in the shareware Doom
properly change their appearance when switched.
New features:
* Players can choose their own colors and names.
(Player setup menu is included).
* 8-player support (untested but should work).
* Miscellaneous internal code changes have been borrowed from the BOOM
source. (This does *not* mean that ZDoom supports BOOM levels yet.)
* Cheats, chat messages, and gamestate changes are now recorded in demos.
* Single-player demos recorded with ZDoom are generally smaller than
before.
* Quake 2-style deathmatch flags.
* Cheats (optionally) work in multiplayer games.
* Mode X is now supported under Win95, so all the machines that couldn't
run ZDoom in 320x200 before should be able to now.
* Fewer conditions result in error messages that quit the game. (If you
have Heretic, try this: Start ZDoom with -file heretic and go to the
console and type "MAP E1M1".)
* Keys can repeat in the console.
* The console and chat mode now use the localized keymap set with the
Keyboard control panel.
* Messages at the top of the screen now break along between words instead
of in the middle of them.
* Added -config command line parameter.
* Added -fastdemo command line parameter.
* Added new screen shot command. (bound to "Print Screen" key by default)
* Added Quake-like +showscores command. (bound to "\" key by default)
* Aliases are now saved in the config file.
* Added support for multiple pitched sounds like in very old version of
Doom. (Use the snd_pitched cvar to turn it on and off.)
1.13 (26 May 1998)
==================
* Fixed some major bugs (that crashed the game) and other lesser bugs that were
just annoying.
* 3-D collisions for walking under and standing on other things.
* The status bar can be scaled to the full width of the screen.
* The screen mode can be selected from a menu inside the game.
* ZDoom can run in a window on the desktop.
* Better DeHackEd support. Only a few text replacements are not supported.
Everything else works (including monster infighting which I haven't seen
in any other port).
* New features for level designers (see editing.txt for details):
Specification of next and secret maps on a per-map basis.
Specify sky texture on a per-map basis.
Use any lump in a wad as music for a map.
Give maps a custom name without using a DeHackEd patch.
Maps can be named anything (not just E?M? or MAP??).
Place any messages of any length between any two maps.
Hexen-style fog (of any color).
Ambient sounds--either point like Quake or global like Heretic and Hexen.
Automatic use of DeHackEd patches in PWADs.
No more tutti-frutti for short textures of certain heights.
zdoom.wcf file for use with WadAuthor.
* Rocket jumping. (One very important note about this: You need to be *in the
air* when your rocket explodes for rocket jumping to work. This is different
from Quake, and I will probably rewrite it for the next release.)
* Dynamic palette flashes.
* Supports stretching skies for freelook.
* Larger freelook range.
* Added tab-completion to the console.
* zdoom.cfg is now the name of the default configuration file since Doom
Legacy decided to start using config.cfg.
* French language support. (Set language cvar to "french".)
* Player obituaries.
* Unlimited ammo cheat (use g_unlimitedammo cvar).
1.12 (7 April 1998)
===================
* Some visual enhancements were made such as centering the menus and
drawing borders around the status bar in higher resolutions.
* Console commands can now be specified on the command line.
* Removed some of DOOM's limits such as VisPlanes, VisSprites, and 2S
HOM.
* Rewrote some of the inner loops in assembly. (There was some assembly
in 1.11, but it never got used.)
* New cvars relating to mouse movement. (invertmouse, m_pitch, m_yaw,
etc.)
* Mouse movement doesn't get sluggish in high resolutions.
* Automap colors are customizable.
* Automap overlay and rotation are available.
* Eight crosshairs.
* Shoot up/down.
* Alt-Tab and Pause work properly on all machines now.
* The +jump command now works.
* 25% and 75% translucency levels in addition to 50%. The translucency
tables now get saved to disk, too, so they only need to be calculated
once instead of every time the game is run.
* The console font is now editable.
* Near complete support for DeHackEd patches. (Only monster infighting
and changing a few minor text strings are not supported.)
* Sky height and position is now fixed for high resolutions. (It still
wraps if you look up, but at least now if you look straight ahead, it
never will.)
* Weapon sprite is always drawn at the correct location. (It was being
drawn too low in some resolutions like 400x300.)
* New options menu, which includes a key configuration screen.
* "Stealth" monsters.
* New full-screen HUD.
* And a few other things not worth mentioning separately.
1.11 (6 March 1998) Initial Release
===================================
* Works under both Windows 95 and NT 4.0, although it works best under
Win95.
* Limited support for the Pause key. It works with some keyboards on
some machines.
* Supports any resolution compatible with your DirectDraw drivers.
* Look up/down ala Heretic.
* Translucency for selected objects.
* Has a console with most of the functionality of Quake's. The only
significant missing feature is Tab-completion.
* Notarget cheat.
* Command to kill all monsters in a level or yourself.
* Can play MUS, MIDI, and MOD music.
* Selected sounds are played in surround sound.
* Doors that need keys to open are highlighted on the automap.
* Automap now shows various statistics in addition to the level name.
* True keybindings. Bind any key to any command or sequence of
commands.
* Intermission screen can now display your stats using absolute values
rather than percentages.
* A new more general demo format.

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff