=====================================================================
Changes since Eternity Engine v3.31 Delta Pre-Release Alpha 2
=====================================================================
=====================================================================
01/19/05

Fixed up various things in d_main.c, including an inappropriate use 
of AddDefaultExtension in the GFS code that probably could have 
caused a crash, or at the least, would have malfunctioned in the form
of returning a bad GFS file name.

=====================================================================
01/17/05

Changed Eternity to use a minor revision version system instead of
public beta releases. From now on, I'll just be incrementing the
subversion until I think the next number should go up (and it should
have done this a long time ago, but whatever :P). Perhaps this will
relax those who think that beta copies of Eternity are too unstable
to use, which hasn't been true since the horrors of v3.31 beta 1.
Eternity has been increasingly more stable since that point, and has
not crashed on me (while not in development) since then.

=====================================================================
01/14/05

Finished the unified font engine in the new module v_font.c -- This
combines code that was previously duplicated in v_misc, mn_engin,
hu_over, and mn_htic to provide a single, uniform interface for
drawing fonts. A few special cases had to be mainlined, but this only
improves the flexibility of the system. The "big" font can now be
enabled for DOOM gamemodes simply by providing the proper FONTB*
lumps.  I'd like to provide a default FONTB for DOOM in eternity.wad,
but I'm a bit short on graphics for it at the time being.

I also intend to add support for fonts that are stored inside of a
single graphic and copied to the screen with rect blit operations.
This will require addition of masked block drawing functions in
v_block.c, more than likely, and so I haven't even begun to tackle it
yet. I find myself wishing I could use SDL's blitting like I do in
RayCaster, but alas, that won't work here for various reasons.

SargeBaldy noticed that the vpo_threshold console variable wasn't
working. As usual, I forgot to actually add the command to the
console command chains with C_AddCommand.  I kinda wish there was a
way to automate that, because I forget it almost every time I add a
variable or command.

=====================================================================
01/11/05

Added the graphical hud for DOOM, which is actually a part of the
status bar and reuses its health, armor, and ammo number widgets. I
had to add a couple of semi-hacks into the status bar code to get it
to allow this, but it was very easy and didn't dirty up the code at
all. The most work was spent getting it to draw numbers outside the
normal status bar background area and to disable the blitting of 
parts of the status bar background behind the numbers, and of course
to get it to draw the widgets in the proper locations at all times.
They wanted to jump back and forth on me at first due to some small
errors in the code.

=====================================================================
Changes since Eternity Engine v3.31 Delta Pre-Release Alpha 1
=====================================================================
=====================================================================
11/16/04

I got sick over the weekend, so the second alpha release I had hoped
for got delayed a bit longer. Today I've done a little work in the
config file code, reformatting a bit of it, adding the vpo threshold
variable, and adding a new variable that lets you disable the appli-
cation of gamma correction to screenshots, a feature that Lee added
but not everyone likes. It will be nice to be able to take normal
screenshots without changing your local gamma setting.

=====================================================================
11/11/04

Big day for bug fixes:

1. 3DMidTex thing clipping is now repaired. The solution? Drop offs
must be COMPLETELY ignored when a thing is standing on (or under??)
3DMidTex lines, otherwise proper clipping is impossible. This is done
by setting the tmtouch3dsides flag in P_LineOpening and then when it
is set in PIT_CheckThing, setting tmdropoffz equal to tmfloorz,
effectively stating that there is no dropoff to be considered. This
prevents the engine from even considering allowing the thing to jump
off in the normal fashion, and allows our own code segment that looks
strictly for floorz differences of 24 units to catch all things on 
3DMidTex lines. It took both SoM and I working together to come up
with this final fool-proof solution.

2. I noticed a while back that P_CheckPosition seemed to be broken
when I saw some Maulotaurs respawning inside each other in Heretic 
while in Nightmare mode. I saw this again recently with some imps in
DOOM II MAP01 and so I knew there was a problem. I fired up a test
map and spawned a demon, killed it, and stood on top of it, and sure
enough, whammo, I'm stuck inside it as soon as it comes back. 

I debugged the program and stepped through the P_CheckPosition call,
and what should I find except that the code is working perfectly as
it is written -- it's just written incorrectly, and the problem has
been there since, guess what -- BOOM. I tested this in WinMBF to be
certain (finding an unrelated bug in it in the process) and sure 
enough, standing on a dead thing in Nightmare mode nets you getting
stuck inside it. SargeBaldy also complained that Archviles were
sometimes getting stuck to things they respawned, or the things were
getting stuck to other things in their vicinity. I knew these were
clearly related.

I wonder how no one has noticed this bug in all this time, as it is
apparently in every BOOM-descendant source port. I checked prboom and
its code does not compensate for this error, which turns out to be a
result of Lee's fix to allow non-solid things to move through solid
things inside the PIT_CheckThing function. P_CheckPosition doesn't 
take account of whether or not a thing is moving, and thus treats 
Nightmare and Archvile respawns the same as walking. This isn't 
appropriate, since the non-moving things being considered WILL be
solid when respawned. I have currently repaired this problem by 
setting and unsetting the SOLID flag on the target objects around the
calls to P_CheckPosition when demo_version is >= 331. Demo compatibi-
lity for DOOM demos was already fortunately intact due to a check 
inside PIT_CheckThing.

This is not an ideal fix to this, however. A better fix would be a
way to tell P_CheckPosition about whether a thing is moving or if it
is a non-solid being considered for respawn, but since the actual 
check on the SOLID flag is done in PIT_CheckThing, an iterator func-
tion called by P_BlockThingsIterator, the information cannot be 
easily passed down to it except through an ugly global variable, and
I do not want to introduce any more of those to the clipping code,
which is already a labyrinthine nightmare.

=====================================================================
11/09/04

SoM made improvements to moving 3DMidTex lines to allow more flexible
tagging and therefore more complex structures possible. This lets his
3D elevators in Lava Factory have independently movable guard rails.

=====================================================================
10/28/04

Removed my earlier -workdir hack and replaced it with new Win32-
specific code in i_fnames.c -- this code utilizes the 
GetModuleFileName and PathRemoveFileSpec API functions to get at the
real fully-qualified name of the Eternity process's EXE file. Unless
these API functions are also broken under Windows XP, which I find
unlikely, this should much more naturally resolve the issue of files
not being found when the frontend starts Eternity on that platform.

D_DoomExeDir currently calls WIN_GetExeDir only when compiling under
Visual C++.  I can add support for other compilers if it is also an
issue for them (I am unaware if this problem affects the MinGW 
build).

=====================================================================
10/08/04

Fixed Cyb's outstanding crash issue -- it was caused by a zero-length
sound lump. They are not technically valid, but there's no reason
they cannot be accepted as meaning silence by simply playing no
sound, which is what the code now does. prboom already fixed this at
some point, apparently, as it did not crash when playing Cyb's map.

BTW, I am aware that zdoom once had a problem with such lumps, but it
was not the same as my problem. That problem was caused by an attempt
to allocate a huge amount of memory, whereas my problem was actually
an out-of-bounds index into a lookup table caused by the computed
padded size of the sound being a negative number.

=====================================================================
10/04/04

Added support for percentage values in the EDF translucency field for
thing types. Percentages must be base 10 integer numbers between 0
and 100, with the last digit followed immediately by a % character.
All non-percentage values are still interpreted as numbers on a 
scale from 0 to 65536. Note the percentage is phrased in terms of
the percentage of the foreground graphic that is used, as opposed to
background. This is the same as other engine translucency metrics,
so 100% is, in this case, not translucent at all, and 0% is 
invisible.

=====================================================================
09/29/04

Added the ability to customize the visplane overflow threshold used
by the SMMU VPO detector HUD widget. As discussed in several places,
this detector cannot be exact due to optimizations made in BOOM's
visplane splitting algorithm (DOOM generated many more visplanes than
it needed to draw a scene, which only exacerbated the effects of the
static limit placed on them).

Finally got around to removing the weird hack that Dave Taylor put
into ST_Responder which allowed the automap to notify the status bar
when the game was changing into or out of automap mode. The code to
do that did NOT belong in ST_Responder, and the notification messages
were being sent in via hacked event_t structures that contained 
values which were assumed to not alias any valid input. This made an
unnecessary AND-op and branch in ST_Responder on every single input
event, which is gross considering the nature of the hack. Created a
function called ST_AutomapEvent which the automap code now calls
instead of ST_Responder.

=====================================================================
09/26/04

Added the ability to reskin monsters with a new sprite via the EDF
field "skinsprite." Monsters with a valid skinsprite will use that
sprite value instead of any value which is in the frames they enter
(with the exception of the S_GIBS frame, because enemy skins are
cleared when a thing is crushed, and restored by an Archvile if it
resurrects such a monster).

Now you can have monsters which act the same but look different with
a minimized EDF thingtype definition which simply inherits from the
original type and sets the skinsprite.

=====================================================================
09/14/04

Eliminated all unused state enumeration values, converting the enum
to use assigned values for the states that are needed. This makes
maintaining EDF much easier.

=====================================================================
09/13/04

Fixed ANOTHER bug in the Heretic Imp's crashstate logic. If an imp
hit a raised floor after calling the ImpXDeath1 pointer, it would
enter its crashstate without ever calling the ImpXDeath2 pointer.
This would cause it to keep the NOGRAVITY flag and hang in midair
forever. This bug was in Heretic.

Split the code in R_FlushColumns to create R_ResetColumnBuffer, which
is now called from the main rendering loop instead of R_FlushColumns.
This moves some redundant variable-clearing code out of the column
drawing line of execution (the most critical line in the engine).
Although the column quad cache rendered us a higher FPS, the code as
is has a lot of room for futher optimization.

=====================================================================
09/12/04

Optimized the flex tran code in r_draw.c by calculating and caching
pointers to the tran lookups when the first column is cached, rather
than when every single column is flushed. All the columns in cache
must share the same flex tran lookups, or they'll be flushed, so it
remains constant during that time.

Split up R_GetBuffer into several different functions which are
called from the different R_DrawColumn versions. This allows maximum
use of known information to minimize the number of branches. These
functions are candidates for future inlining, as they are very small
now.

=====================================================================
09/11/04

Fixed a bug in the column flushing code where it used the wrong
tranmap for BOOM-style translucent columns.

Unrolled a loop on a constant value in R_FlushQuadColumn and then
reordered the function calls made within it to be in closest screen
order, hopefully reducing possible CPU cache misses.

=====================================================================
Changes since Eternity Engine v3.31 beta 7
=====================================================================
=====================================================================
08/22/04

EE v3.31 'Delta' pre-release alpha will launch today. I'll let it
stay up for a few days, wait to see if any problems are reported, and
then I'll upload the final EE v3.31 release to /idgames. This is 
mostly to avoid the curse I suffer of uploading something only to 
find I left out one file, or a single line of the EDF is wrong, etc.
I'm otherwise fairly confident that EE v3.31 is stable and has very
few bugs.

=====================================================================
08/21/04

Added the ability to specify an alternative working directory over
the command line using the parameter "-workdir". This is made necess-
ary by bugs and compatibility problems in Windows XP which are break-
ing the frontend.

Not only does Windows XP's crt0 deliberately strip the absolute file
path off of the exe name in argv[0] -- the CreateProcess API function
on that system also fails to properly set the working directory. So,
it is literally impossible for Eternity to figure out the appropriate
place to get its files from when started by the frontend.

I'll have to release a new frontend version that implicitly uses the
-workdir command line parameter instead of only trying to set it via
CreateProcess. It'll probably follow shortly after 3.31 Delta release
since the change is very minor.

I fixed the bug with explosions tangent to 3DMidTex lines by using
SoM's suggestion of checking against mo->secfloorz instead of
mo->floorz. The secfloorz field, which SoM added, always has the
sector's floor height, whereas floorz may be modified by 3DMidTex
lines.

=====================================================================
08/20/04

Absolute final preparations are being made for the pre-release
alpha of Eternity Engine v3.31 'Delta' -- Delta is the name I
decided upon for two reasons: first, it comes after Gamma, but 
second, it also stands for change in math, and Eternity is really
changing and beginning to come into its own now.

I completed beta versions of the MapInfo and ExtraData documentation
today and during the past few days. It feels so good to have this
stuff documented and completely ready for use by editors at long 
last.

=====================================================================
08/16/04

I was play-testing Heretic a bit more and found that the imps had
a couple of oddities with the crashstate:

1. If an imp died above a floor but drifted into another sector where
   its z coordinate was EXACTLY equal to the floor, such that it 
   never moves even 1 unit in the z direction, it could miss going 
   into its crashstate. P_XYMovement must also check if a thing 
   should enter its crashstate. This is done when the thing is no 
   longer moving on the x or y axes and is at the floor z. This
   error happened by the yellow key area of Heretic E1M1. The imps
   there often spawn on the floor.
   
2. Under just the right circumstances, a dead imp falling down stairs
   or off a short ledge could enter the crashstate twice. I believe
   this happened in Heretic too, but I've fixed it by making the
   ImpDeath and ImpXDeath2 pointers set the MIF_CRASHED flag so that
   the movement functions won't cause a re-entry into the crashstate
   when a dead imp is sliding. So now you shouldn't get two sets of
   imp chunks from one imp, no matter what ;)

I added the NOSPLASH flag to a few Heretic objects that really
shouldn't splash, like PodGoo. Way too many sounds going on when pods
blow up over water :P
   
Somehow I managed to get stuck into an Iron Lich today when he
tornadoed me on a lift. Not good, but the situation in which it
happened was so esoteric and extreme that I'm not worried about it.
If anybody can find a commonly creatable circumstance where you can
get stuck into things with z clipping turned on, then we can worry.
Until then, no. I doubt it'll ever happen again unless the exact
circumstances are recreated.

=====================================================================
08/15/04

A while ago I got a bug report via email saying that dog jumping was
broken, but I dismissed it at the time. Well, today I tested it my-
self, and sure enough, dogs never jumped down.

I found a code segment in P_TryMove which SoM added for 3DMidTex 
lines. Unfortunately, it broke dog jumping (and possibly some other
stuff too). I had to comment it out for now, and I think the only ill
side-effect is that monsters walking on 3DMidTex lines can hang a
little bit too far off the lines, which just looks a little odd. If
this cannot be fixed without breaking other stuff, we'll just leave
it be. Things already hang off normal ledges a lot, even with Lee's 
falling physics, so I don't think it's a big deal.

There's another bug with explosions that take place on the top
surface of 3DMidTex lines -- they trigger terrain hits no matter how
far above the real floor they are. Unless there's a reliable way to
distinguish when a thing is and is not above 3DMidTex lines, I
don't know how we're going to fix that.

=====================================================================
08/14/04

Finally applied SoM's patch to fix the spectre fuzz problem. The code
wasn't caching the proper colormap to use when flushing fuzz columns,
so it could get munged up.

=====================================================================
08/12/04

Repaired some minor but annoying sound bugs related to external
cameras. Fraggle's sound code adjustments didn't always use the
camera as the point of reference for sound, so sometimes sounds could
pop back and forth between the player and the camera. This was only
really noticeable with the chainsaw.

Also, it seems like S_AdjustSoundParams could have dereferenced a
NULL listener. I'm not sure how this hasn't caused problems in the
past, but I added a check for it anyways.

=====================================================================
08/08/04

I fired up BOOMEDIT.WAD today to do some final rounds of regression
testing (because I DO need to release really soon). Guess what should
appear but a gaggle of previously undetected bugs!

1. Deep water ceilings clip off the bottoms of sprites, even when the
   242 ceiling is even with the floor. This looked like a bug at
   first, but technically it isn't. 242 flat sprite clipping is and
   MUST be more rigorous than the normal interaction of sprites and
   flats. Normally a thing can extend into a floor practically as far
   as it wishes and it will be displayed. In order to have proper
   behavior with 242 effects however, the sprite must be clipped
   exactly. There is no easy way to detect the case where a thing is
   on a floor exactly even with the 242 ceiling within the sprite
   rendering code, and so I cannot change this. Even zdoom has the
   same behavior here.
   
2. BoomPushPoint and BoomPullPoint were broken, causing the point-
   source effects to work only intermittently and only at close
   range to the objects. Believe it or not, this was an EDF error.
   When I wrote InfoConv, a hacky little program that turned the
   info.c data into the initial Eternity EDFs, I assumed that all
   the mobjinfo entries had integral radius and height values. Alas,
   the radii and height of the BoomPushPoint and BoomPullPoint 
   objects were only 8 for some reason, and not 8*FRACUNIT -- this 
   means they should be 0.0001220703125, not 0.0 -- the change broke
   the visibility test on these objects done in the pushing thinker
   code.

3. The chasecam can still act iffy on some deep water boundaries. I
   dunno if I can make it any better or not. Now is not a good time
   for it, that's for sure. It will have to wait, possibly forever.
   (Can you tell I don't care about it very much? :P )
   
4. BOOM Extended sector damage types were broken because of a really
   stupid error I made in the (possibly temporary) code which chooses
   between DOOM- and Heretic-style nukage damage. Note that 
   currently, the game is using bit 12 of the sector type to indicate 
   that a BOOM extended sector should do Heretic-style damage. I 
   don't like this because it's not solving any problems; it's better
   than the system I had previously, which was hardcoded by gamemode,
   because it would let the user pick the damage type in any game-
   mode. I'm still not sure what the best combination of solutions 
   for custom floor damage will be -- I say combination because in
   the end, the sector type, TerrainType, ExtraData, etc. could all 
   have different means of providing damage values. The bit 12 toggle
   has never been documented and you should not try to use it. It is 
   very likely to disappear, as there aren't that many free sector 
   bits left and I think that toggling between 2 static damage types 
   using one is wasteful when more general solutions are possible.

=====================================================================
08/07/04

Finished adding the very last Heretic enemies, the Gargoyle and
Gargoyle Leader (the EDF and source call them Imps since I cannot
type Gargoyle over and over >_<).

Finally added the crashstate field to mobjinfo, and EDF support for
it. So now your dead falling monsters can switch into a different 
frame when they hit the ground (note: not useful with the DEADFLOAT 
flag at all ;)

I generalized the code in A_SkullAttack so that anything doing a pure
SKULLFLY attack can call it (this includes the Heretic Imp, but not
the Maulotaur, who does his charge a bit differently). The new
function is P_SkullFly.

I ripped out almost all the existing TerrainTypes and floorclip code
and replaced it with a new system, with some parts adapted from
zdoom -- some serious problems had crept in through the various 
versions and it was getting difficult to put up with it. Plus, if I
want to generalize the floorclip system to allow variable terrain
clipping or monster effects, it had to happen anyways.

Three things happen as a result of this:

1. TerrainTypes now work perfectly with deep water! When a normal
   thing descends past a deep water surface, a splash is formed there
   at that time. When missiles or bouncers cross the surface at all,
   they splash (so shooting up OR down through water causes 
   splashing).

2. Missiles now cause TerrainType hits. People requested this a long
   time ago, but with the state of the system I didn't even want to
   try it then. If you want a missile that doesn't splash, give it
   the flags2 bit NOSPLASH and it won't (that goes for anything else
   too).
   
3. v3.29 demos recorded with TerrainTypes on are forever broken.
   Sorry, it had to be done. I couldn't preserve the old system. This
   is much like when Lee ripped out BOOM's extremely inefficient
   thinker-based friction algorithm -- BOOM demos with friction 
   cannot play back properly either, but he had no way to preserve
   the old friction system without either some serious hacks or total
   code explosion. SargeBaldy estimates the number of v3.29 Gamma
   demos to be exactly zero, and so I really doubt this hurts anyone
   anyways. In some ways it is fortunate that Eternity has not seen
   much use yet. It lowers the compatibility woes when things have to
   be changed in fundamental ways like this (which is rare).
   
   Note that recording demos with beta versions of Eternity is 
   unsupported and always has been. I can't keep track of changes
   across betas, only across the major version number -- the code 
   would become impossible to handle otherwise. If you need to record
   a demo on a beta version of Eternity, you better keep that beta 
   version forever, because the demo will probably desync a few betas
   later.

=====================================================================
08/06/04

Added all the Heretic ammo objects, just for the hell of it.

=====================================================================
08/05/04

Eternity now officially has feature creep. I just can't quit adding
stuff ;)  After noticing what Heit did in zdoom, I added a function
called P_SubRandom, which can safely subtract two random values
without incurring ambiguity in order of evaluation. Lee Killough had
alreadly eliminated all such expressions, but he did so by adding
temp values everywhere, which while it worked fine, makes the code
look messy and less readable. P_SubRandom fixes that.

At some point I also went through and found anywhere that a thing is
thrusted along an angle and changed all those calculations to calls
to the P_ThrustMobj function. No use having a function like that if
none of the code uses it. Having small functions for these common
operations makes writing new code much faster and more uniform.

=====================================================================
08/03/04

Finalized various details on stuff done during the past week.

Added ability for Iron Lich whirlwinds to update their tracer to
the Iron Lich's new target whenever their current tracer goes bad.
This allows the Lich to "direct" its existing whirlwinds toward any
new target it acquires. This keeps them from spinning off into walls
prematurely and just sitting there until they time out (although they
still do that if the Lich doesn't acquire a new target that the
whirlwind can follow).

Added flags3 CANNOTPUSH flag and added it to everything from Heretic
that should have it. I'm not aware of any DOOM items that should have
this flag, as it mainly applies to objects that pretend to be
missiles but are not (like D'Sparil's blue sparks and the goo that
comes out of pods when you shoot them). The Eternity TerrainTypes
splashes do need it, but I really count them as Heretic things
anyways, since that's where they originated ;)

I am beginning the final stages of preparation for v3.31 final 
release. There is still a ton of documentation work to be done :(

=====================================================================
08/02/04

Added Heretic Iron Lich. Added codepointers AproxDistance, LichFire,
LichWhirlwind, LichAttack, WhirlwindSeek, LichIceImpact, and 
LichFireGrow.

Added a damage field to mobj_t which mirrors the value in mobjinfo_t.
This was necessitated by the Iron Lich's fire pillar projectiles,
which must do zero damage until they have become visible. This adds
more flexibility to the damage that things can do by making the value
writable and determined on a per-thing basis rather than per-thing-
type.

Added flags3 EXPLOCOUNT flag, which is used to keep Iron Lich
whirlwinds from blowing up like missiles until a certain condition
is met. That condition is when the object's special2 (counter 1)
field is greater than its special3 (counter 2) field. This flag is
rather situational and probably won't see much editor use.

Revised the CounterJump and HealthJump codepointers so that they can
support both immediate values and values from counters. Added more
operations to the SetCounter and CounterOp codepointers.

Added extended parameters to the MBF Scratch codepointer so that it
can get its damage value as a constant from Unknown 1 (as it always 
has), from the thing's damage field, or from a counter. This makes
it very flexible without breaking compatibility.

Added 2 new special effects to the HticExplode pointer -- Maulotaur
floor fire explosions and Timebomb of the Ancients explosions. True
that the Timebomb of the Ancients won't be in the engine for a while
yet, but that code's there waiting for it and can, of course, be used
by editors.

Finally eliminated all the commented-out and #if 0'd code in info.c,
reducing the file to nothing but some legacy comments and the
declarations of the sprnames, states, and mobjinfo pointers and 
their corresponding NUM* variables.

Eliminated all the unused DeHackEd number enumeration values for
mobjinfo. The remaining ones are the ones that are actually used,
and they use value assignments to make them keep the right values.
I want to do the same thing for frames, but I'm having trouble
finding out which frame enum values are used due to the sheer number
of them and because of the difficulty of isolating only frame enum
values in the source (even regexps catch a lot of identifiers that
aren't frame enum values).

=====================================================================
08/01/04

Added the dmgspecial field to the EDF thingtype and support for it in
P_DamageMobj. Added MaulotaurCharge and Whirlwind damage specials.

=====================================================================
07/31/04

Added SectorColormap Small function.

=====================================================================
07/30/04

Rewrote P_CollectThings and made it part of the new MobjCollection
system. This is another OO-like structure which is manipulated only
through functions which can be found in p_mobj.c -- this gets rid of
some of the weirdness such as use of a pointer-to-pointer-to-pointer,
and reduces some duplicated code in the segments that use reallocated
mobj pointer arrays.

Added Heretic Maulotaur, eliminating ETCMinotaurus and all of its
associated resources in the process. As stated earlier, almost all of
the Maulotaur's code was already in the engine. Added the flags3
INVULNCHARGE bit to resolve a fixme on the special treatment of
SKULLFLY'ing Maulotaurs which was #if 0'd out after the addition of
EDF.

=====================================================================
07/29/04

Added Heretic volcanoes. Added new codepointers SetTics,
VolcanoBlast, and VolcBallImpact.

Added a new parameter to the BeastPuff codepointer to allow disabling
the application of momentum to the puff objects.

=====================================================================
07/26/04

Added a failsafe to the Chase codepointer so that it cannot cause
infinite recursions when used in an object's spawn state.

=====================================================================
07/23/04

Got around to fixing a couple of issues in the menu system. String
console variables being subjected to input via the menu system, such
as savegame names, now have their current value copied to the tempo-
rary input buffer (except when on the savegame menu and the value is
"empty slot"). I also simultaneously fixed it to use the replaceable
"empty slot" string that is defined through DeHackEd, rather than a
locally defined copy of that same string. The DeHackEd string had 
been orphaned at some point and wasn't being used.

This removes the painful necessity of retyping the same savegame name
over and over every time you save to the same slot. I'm really not
sure why fraggle left this out, seeing that it was in MBF already and
the code to do it is only a bit more complicated than the code to
clear out the input buffer. This was a heavily requested feature, but
I put it off 'til now because (once again) I figured it was going to
be difficult to fix. It wasn't.

Also made a couple of the menu help messages (displayed at the bottom
of the screen) sensitive to menu key bindings. They'll tell you one
of the proper keys to press, rather than always displaying the engine
default of "enter". There's one I haven't fixed, though.

This is just misc stuff I'm mopping up while waiting to send the
source to SoM so he can fix the Spectre bug introduced either by
hires or by the column optimization code (he knows which but I do
not ^_^). Once that's done, we'll be ready to make preparations for
some beta testing and then the release.

=====================================================================
07/22/04

Moved par time determination code from g_game.c to p_info.c.

Finished implementation of global MapInfo lump support. The global
MapInfo lumps are named EMAPINFO (*not* MAPINFO to avoid future
Hexen conflicts!). As mentioned earlier, they cascade and allow the
latest definition for a map to become the one that is used. HOWEVER,
I did NOT use the libConfuse parser!

I started working on a libConfuse implementation, and before I was
even half done I had about 150 lines of asinine and redundant code.
I realized it wasn't going to work and trashed it all immediately.
Instead, I put some extra code into the existing parser that lets it
go into "global" parsing mode. It only adds about 10 or so lines of
code to the existing parsing functions, and works MUCH better.

Another obvious bonus is that the syntax is almost 100% consistent
with in-header MapInfo (the difference is that in global MapInfo, the
blocks are named for the maps they belong to (ie "MAP01"), and in the
in-header flavor, there can only be one block which must be named
"level info").

Did some minor testing of this, goofing with the START map and
several DOOM levels. It seems to work brilliantly, but of course it
needs a more thorough beatdown to be sure of its correctness.

But no, the format is not zdoom/Hexen-compatible. Sorry. >:D

This completes virtually everything in the code that is necessary for
v3.31 final release. ::ominous drum rolls echo like thunder::

=====================================================================
07/18/04

Moved the sky texture determination code from r_sky.c to p_info.c.

=====================================================================
07/17/04

Began the final changes for v3.31 final -- the implementation of the
global MapInfo lump. Support for map header MapInfo is not being
removed, but rather augmented. MapInfo embedded into map headers will
override the information provided in global lumps.

The global lumps will be additive, such that the definition for the
current map will come from the LATEST MapInfo lump, but other maps
can still come from prior ones. I am planning at this point to use
libConfuse to parse the global lump, so its syntax will be EDF-like
rather than the same as in-header info.

The first course of action was to put all the info_* variables into
a new struct (a long-standing TODO), the LevelInfo structure. This
didn't take long at all.

The second thing to be done, which will take longer, is "centralizing"
MapInfo such that it becomes the DEFAULT place to get map-dependent
information from, rather than an alternative to numerous other
sources scattered around the executable and determined one-by-one
through complicated decisions that muddy up the source code.

This process has been started by moving the f_finale code for deter-
mining the intermission text, backdrop, and music to p_info.c, and
also the automap level name code in hu_stuff.c to p_info.c.

I removed the commented-out list of sprite constants from info.h
(the old location of the static thing types and frames). I said a
while back I might leave that stuff for historical interest, but it
adds +200kb to the source code and thus eliminating it is a good 
thing IMO. People can just download the BOOM or MBF source if they
really want to sit and stare at the way things were once done ;)

=====================================================================
07/16/04

With the help of the zdoom source, I finally figured out what was
breaking the rising pit at the end of Heretic E4M1. For some weird
reason, Raven decided to make raiseAndChangeTexture plats go into an
eternal stasis after completing their action. As you may know if you
are an advanced editor, plats in stasis lock out any other floor
actions on the sector in question. This is why the pit at the end of
E4M1 does not rise more than once in Heretic, even though it would 
if you converted the map to DOOM.

For now at least, these types of plats will go into stasis when
playing in Heretic mode. It would be nice, of course, if a map author
could control that somehow.

=====================================================================
07/15/04

Finally added the PrBoom comp_stairs fix for MBF. Lee accidentally
munged comp_stairs up really badly, such that most levels wouldn't
even work under it if comp_stairs was on (but would without it).
I just decided to not spend a lot of time trying to exactly under-
stand cph's fix, and copied the ENTIRE new function from PrBoom.

I got around to this because someone finally found a map that broke
because of it under Eternity and bothered to complain about it to me.
If you need something fixed, please tell me.  I base my priorities
on the more minor stuff largely on user requests these days.

=====================================================================
07/14/04

Deleted the ClericSparkle Eternity TC object and its associated
states and codepointer. Absorbed the previous functionality of the
P_ClericSparkle function into the Heretic SpawnGlitter pointer by
adding some new parameters to it.

Added a new codepointer -- CounterOp. It lets you do an operation on
two counters and store the result in a third (any of the 3 involved
counters may be the same counter, too). This pointer makes the whole
set of Counter codepointers a complete assembly language for frames!
There are still a few things you can't do (ie store the result of a
comparison rather than jump on it), but I'll probably address these
based on user requests, since I cannot fully anticipate what is and
is not needed.

=====================================================================
07/08/04

Finally got around to adding a filter parameter to the cmdlist
console command, so now you can filter for commands that start with
a particular letter of the alphabet. I also fixed a masked bug in
that command -- if there had been any non-hidden commands that
started with the letter Z, they wouldn't have shown up because it
used a < where it needed <=. Of course, the only Z command is
currently z_print, and it is an undocumented debug command ;)

Fixed the MapInfo levelpic and endofgame to work properly under
most if not all circumstances. I became aware of the endofgame issue
after looking through the Caverns of Darkness source. Seems Joel
fixed the problem for CoD but forgot to tell me about it ^_^

=====================================================================
07/07/04

Added dynamic automap bindings, eliminating the automap key_* config
variables. Had to change some semantics in the key bindings system
slightly, as well as break up the logic in AM_Responder, for it to
work properly.

Twiddled the key repeat settings so that the delay is shorter and
the repeat rate is slower. Also verified that key repeat *should* be
enabled. Without it, a lot of stuff becomes irritating to use, and
it is always on under Allegro in DOS too.

Broke up the hideous mess in AM_drawWalls. Most of the insanely
complex predicates in that function have been scooted off into their
own static inline boolean functions. It is so much more readable now!

=====================================================================
07/06/04

Changed the SDL flags in i_main.c into a #define instead of using a
local variable. Stack space on the main line of execution should be
strictly conserved, as it can never be reclaimed during execution,
but will never be used again.

=====================================================================
07/04/04

Repaired a bug in the cast call system that would ignore sound events
which occured on the first missile or melee attack state.

=====================================================================
07/03/04

Began improvements to the key bindings system to support multiple
binding classes. Binding classes allow a single key to have multiple
bindings, as long as each one is in a different class. This restores
the BOOM level of functionality while retaining the SMMU flexibility
of being able to bind actions to more than one key.

Added dynamic bindings for the menu system and eliminated the menu
key_* variables.

Made the -cdrom code in G_LoadDefaults be conditionally skipped when
compiling under Linux, since -cdrom is currently broken for that
platform.

=====================================================================
06/24/04

Got around to rewriting the EDF compressed frame definition code to
relax the syntax of cmp fields significantly. They now allow arbi-
trary whitespace, which is ignored, and quoted values. Quoted values
allow stuff like BEX flag strings to contain characters that would
otherwise be ignored or cause errors (like pipes and spaces).

This is really how I wanted cmp fields to work from the beginning,
but I was in a hurry during the initial implementation because many
other things also needed to get done. This doesn't break any backward
compatibility; it only improves what can be done with the formatting
of cmp fields.

=====================================================================
06/21/04

See, I told you my pace was broken :(

I have been more occupied by my many other projects -- Dungeon
Keeper, CQIII, RayCaster, et al., and Eternity has been suffering
because of it.  CQIII development is going to need a new Eternity 
release, however, so I have a new incentive to get back to it.

Found out wads added via GFS don't set the "modifiedgame" flag,
because for some dumb reason, functions in d_main.c set that flag
every time they add wads to the game, instead of having such a flag
set somewhere in w_wad.c -- oh well, it's fixed now, and when a GFS
adds wads, the game will realize it has been modified.

Added code in w_wad.c to track the handle of the very first wad file
added to the game. This handle will always belong to the engine
resource wad (eternity.wad), and is therefore useful for figuring out
if the user has replaced something inside it.

This was needed to make the startmap auto-disable itself when new
wads are added, but ONLY if the startmap comes from the resource wad.
If a user modification provides its own startmap, then the game will
still be able to use it because of this. I didn't want to disable the
ability for user modifications to provide new startmaps, since that
is a potential editing feature, and one we might choose to exploit
for Chex Quest III, which is finally beginning to make some more
serious progress now.

=====================================================================
06/01/04

After discovering that Eternity could attempt to call Small scripts
recursively after all, despite my efforts to the contrary, I was
required to rewrite the entire system for starting scripts, which has
put a significant delay on the release of the final version of EE
v3.31 (I estimate the delay will last the rest of the summer since it
has seriously broken my pace of work and discouraged me for a while).

Everywhere starting a script that could possibly be doing it recur-
sively must now test if the VM it is using is currently executing, 
and if it is, it has to create a child SmallContext structure which 
contains a clone of the VM and its own invocation data. These 
SmallContext objects create a tree (more of a chain, really), and as
each ends its execution, the data segment is copied back to the 
parent, and the parent continues.

It's unfortunate that the Small VM isn't already reentrant when using
the same AMX structure. For some reason, Thiadmer has kept the code
and the context married to each other, rather than allowing multiple
contexts to function over one code/data area, like languages such as
Lua can do. I'll admit to actually considering changing to another
scripting language again for about a day. But, I really LIKE Small
despite its few ultimately minor problems, and the amount of work to
change languages at this point would be astronomical once again. So
I put that idea out of my mind and proceeded to come up with that
elaborate and slightly hackish method of making Small behave as a
reentrant system.  I have yet to test scripts actually executing in a
reentrant situation, however, and I dread doing so.

=====================================================================
05/24/04

Finally added savegame support for the Small scripting system. The
levelscript and gamescript VMs both must have their data segments
saved.  Since Eternity doesn't support sleeping or waiting scripts,
there is no need to save the heap/stack or registers, and thus the
savegame code is significantly simpler than it would be otherwise.

The list of currently scheduled callbacks also has to be saved.
Although at runtime they are stored in a double-linked list, their
order is considered undefined and therefore I can simply relink
them on load.  This allows me to store them just like thinkers are
stored -- back to back with a special terminating value that tells
me when to stop reading.  So simple and easy I almost have to laugh.

With this, the last true obstacle to releasing a version of Eternity
with Small support for editing is eliminated.  The only things that
have to be done now are getting enough docs and tutorials done that
people can learn how to use it effectively, and of course, continuing
to add more native functions so that it can quickly catch up to and
overtake ACS and other scripting languages.  I believe I am well on
the way to this, but I must keep up my current fast pace.

Once all the natives are done, Small will be incredibly powerful;
this isn't just conjecture any more. It's starting to become a 
reality, and I'm very excited about it.

Added the ability for Small callbacks to pause under certain
circumstances. The SetCallback function now takes a flags parameter
that can specify those options.

=====================================================================
05/23/04

I should note that during the last month I have added a ton of
Small native functions, but have not been mentioning them in the
changelog. Mea culpa.

Finally figured out a SMMU bug that was causing Eternity to think
levels were new whenever you added a single lump file or played demos
using -file or -playdemo.  The code in w_wad.c that keeps track of
the IWAD's file handle would inappropriately reassign the IWAD
handle to any single file that was opened because it was using an
uninitialized variable (damn it, fraggle! :P)

Once again, SargeBaldy has helped me track down a demo sync problem.
fraggle made it to where Lee's autoaim toggling could be used in the
normal game and not just in beta emulation mode. The problem is, Lee
depended on the value of "beta_emulation" to keep autoaiming on
during old demos. When fraggle removed the beta_emulation variable,
he inadvertently opened up a situation for demo sync problems.

SargeBaldy was using a console script to force autoaim off at
startup, since Eternity didn't yet save this variable in the config
file (an issue directly related to this sync problem, as it wasn't
saved in savegames or demos either).  I've fixed it by, of course,
saving it in demos, savegames, and the config file from now on.

Sarge has been one of my most loyal users, and his concern over
improving Eternity's usability and demo sync have proven themselves
priceless over and over.  I definitely think he is on his way to
getting his name on the Special Thanks line of the help screen. He
deserves it as much as anybody who's there already, if not more.

=====================================================================
05/20/04

Made the pause at the end of execution optional, by user request.
The pause is there because Windows slams console windows for Win32
programs shut as soon as the program stops execution. This is rude
and provides no time for the user to read any error or exit messages,
making an at least optional pause necessary.

=====================================================================
05/16/04

By popular demand and because I think it is important for compatibi-
lity, I have restored the BOOM/MBF "traditional menu" feature, which
enables use of the original DOOM main menu.  This should fix problems
with various wads, including Hell Revealed 2, which rely on the
precise behavior of the old main menu to be usable.

The stuff that had to be done to emulate the old main menu fully
included defining the actual menu, causing it to be modified at run
time when in DOOM II, and then making the skull pointer behave
differently (in DOOM, it used an absolute hard-coded height to skip
to the next item; under fraggle's more intelligent system it auto-
spaces the graphics and skull positions using the graphics, but this
would break under wads like HR2).  I also had to restore the
"traditional_menu" config item and add a console variable for it.

I'd say it took me about 15 minutes, so my earlier concerns of it
being difficult were unfounded. Sometimes you just gotta try doing
something before you know what kind of effort it will take :P

=====================================================================
05/07/04

Removed old FraggleScript EV_OpenDoor and converted the EV_DoGenDoor
function to use the new EV_DoParamDoor.  Parameterized specials are
almost identical to BOOM extended linedef specials, except that they
allow complete customization of the parameters, instead of being
restricted to a set of speeds, heights, etc.  This allows Small to
create new effects without causing the code explosion which I had
previously feared.  The way in which the BOOM gen linedef code was
written is quite amenable to being extended in this manner. All I
have to do is add a new enum value after the generalized ones which
indicates to use a value which was passed to the function in an
"extended values" struct.  So for gen linedefs, the code segments
continue to function the same.  For parameterized actions, they can
get special values.

Rewrote EV_DoGenFloor to use the new EV_DoParamFloor. Same as above,
except for floors instead of doors. The Small FloorAction function is
needed by the start map, which I am working on restoring to full
functionality.

Found a BOOM bug which was in Eternity that was fixed by BOOM v2.02 
but missed by Lee (keep in mind that Lee was writing MBF while 
TeamTNT was still working on BOOM 2.02, so there are some inconsis-
tencies like this which still need to be caught).

The bug was an interesting one which was originally in DOOM. Floor
and ceiling actions that raise or lower by the shortest lower texture
would sometimes choose the wrong height if any sidedef around them
had the "no texture indicator", which is "-".  Internally, DOOM
remaps this to the number zero. 

The problem is that the first texture in the texture directory is
also number zero, and that happens to be the AASHITTY/AASTINKY which
are notoriously unusable.  The reason they can't be used is because
of this -- DOOM considers them to be the same as no texture.

The problem was in the check when lowering or raising floors and
ceilings. id forgot they used zero to mean no texture, and so it was
treating zero as if it were AASTINKY, and getting that texture's
height. If it was shorter than any of the other textures around the
sector, it would end up being chosen incorrectly.

BOOM fixed this for the DOOM function in v2.00 or v2.01, and thus the
original linedefs work properly when comp_floors is off. But, whoever
wrote the BOOM generalized linedef code that does the same thing
forgot to fix that bug there as well until Jim Flynn found it in 
v2.02. prboom didn't have this problem because it is based off of
BOOM v2.02, whereas Eternity is descended from MBF, which is based
on BOOM v2.01.

=====================================================================
05/02/04

Identified and repaired a possible crashing bug in Lee's LineEffect
codepointer.  It passed a locally declared dummy linedef to the
activation functions.  Unfortunately, some of the code called by
those functions ends up storing pointers to the line which triggered
the effect (ESPECIALLY for switches).  Since once A_LineEffect 
returns, the line doesn't exist in memory any more, this could cause
stack or heap corruption (the latter being extremely rare).

Fixed by making it static, but I must note with some concern that
activating line effects in this manner is just not a good idea. Yes,
the original source does it a few times for the 666/667 effects, but
then DOOM had a lot of stuff in it that shouldn't have worked, yet
did by either luck or because of DOS4GW. No future code I write will
allow use of linedef specials in this manner, since it could lead
to some unreliable side-effects on the rest of the map.

Found a dead structure type and function prototype in p_spec.h for
the old BOOM thinker-based friction model.  Lee rewrote this in MBF
but missed killing this stuff in the header.  I removed it all and
left a comment to note where it went.

=====================================================================
04/27/04

Rewrote HU_CentreMsg into HU_CenterMessage, adjusting it in prepa-
ration for use by Small (it was previously only usable via Fraggle-
Script, and didn't use the standard message duration). It also now
uses the qstring structure instead of maintaining its own reallocated
string. Thus continues my quest to get everything using qstring that
can use it.

=====================================================================
04/15/04

Added line continuation back into the custom libConfuse lexer, but
only inside quoted strings. This allows them to be broken across
lines, which may come very much in handy if I add the ability to
define completely new string values in EDF. This might become needed
to support other features soon. Replacement of builtin strings will
still remain a BEX-only feature, however. It's done there much better
than EDF would be able to do it, and there's no need to have the
same functionality in two places (plus there's bexinclude, which
really makes it like one place anyways).

This would also allow long frame cmp fields to be split across lines.
One has to be careful to preserve the terse syntax, however. Any
extra whitespace before the line continuance slash would mess up the
cmp field parser. Whitespace after the continuance is ignored, of
course, allowing the start of the next part of the string to be
arbitrarily indented (you could in fact even put in more linebreaks
without additional continuance symbols, but this is considered
deprecated and I won't document that ability, since it is detrimental
to the syntax).

=====================================================================
04/13/04

Added a bunch of new codepointers:

* SetCounter -- provides 12 different operations for manipulating
     the three internal "special" fields that things have
* CopyCounter -- lets you copy one counter to another
* CounterJump -- just like HealthJump, except it works on any of the
     three counter fields.
* CounterSwitch -- this is probably the most powerful decision-making
     codepointer possible, and it is equivalent roughly to an ASM
     jump table or C switch statement. You give it the DEH number of
     the first state in a block of consecutively-defined states, and
     then the number of states that are in that block. It then uses
     the zero-based value in the selected counter field to branch to
     one of those states. When used with the RNDMOD operation in
     SetCounter, this is MUCH better than using chains of RandomJump
     states. I immediately rewrote ChexBuddy's AI in the CQIII EDF
     to use this pointer, and it's much cleaner and makes him use
     his weapons more uniformly.

Fixed the V_DrawPatchTL calls to use a flex tran level approximately
equivalent to the BOOM tranmap level. Much to my chagrin, this was
forgotten in all the excitement before beta 7 launch.

=====================================================================
Changes since Eternity Engine v3.31 beta 6
=====================================================================
=====================================================================
04/11/04

Applied the final outstanding patch to the portal code to add anchor
type 299, which I ALMOST forgot to do.

Prepared all documentation for the new release.

=====================================================================
04/10/04

Made the last few minor adjustments required to compile the DOS
version and tested it out.  Seems to work like a charm.  However,
the assembly versions of R_DrawColumn and R_DrawTLColumn are now
out of sync with the C versions, and thus need to be adjusted to
work again -- but my x86 assembly skills are lacking.  I may have to
learn a bit more to fix them so that Eternity can remain at maximum
speed on that platform.

Added a new codepointer, HealthJump.  It allows frame transfers to
be controlled by the amount of health a thing has, and can compare
that amount against a given number in seven different ways.  This
is one of a few new "frame scripting" codepointers I intend to add.
Although Small will be able to do frame transitions eventually, I 
think these codepointers will prove useful for EDF mods even with 
scripting in place, because they are fast to use, allowing you to
remain in one language rather than jumping back and forth.

I really did want to release today, but various things, including my
allergies, got in the way, so it won't happen tonight.  Sorry!

=====================================================================
04/08/04

Finished work on V_TileFlat, which doesn't exist as a single func-
tion at all now.  The 2x version of this function won't work on any
buffer, however, because making it do so would have just made it
slower. The VBuffer setup function tests to see if the buffer is
really 640x400 or not, and if not, makes it use the general scaled
function instead.

Turned out V_PatchWrapperS wasn't exactly kosher, as it started
causing heap corruption again today.  SoM and I together nailed down
a series of small problems in the function, one of which was appar-
ently a sensitivity to some bad patches in Heretic (!!!). Now it
seems to work properly (and it might be a bit faster too).

Eternity now locks almost perfectly at 35 FPS in 640x400 for me,
something it didn't do before the rewrite. Since the major drawing
functions are all pointerized now (V_DrawPatch, V_DrawBlock, and
V_DrawBackground being the major 3), I can probably feel comfortable
with releasing a beta really soon, as in possibly tomorrow if I can
get everything ready fast enough.  I still need to fix a couple of
lingering DOS issues and test that build out. Hopefully no hidden
problems will be revealed.

Of course, the revisions to the drawing system are far from finished.
I'll probably be revising and tweaking various elements of it for
several versions to come, just to get extra speed here and there,
or to make some of the old code nicer.  We'd eventually like to be
able to draw directly to the SDL screen surface instead of triple
buffering like we have to do right now.  Some of the work I've done
in the past few days is amenable to having this happen in the future.

=====================================================================
04/07/04

Created module v_block.c

Added a v_mode command-line parameter so that you can override the
video mode stored in the config file, in case Eternity can't seem to
work in the current video mode.  You have to know the appropriate
number of the mode you want though.  I'll publish a list somewhere
before release.

Started rewriting the block drawing functions -- V_DrawBlock now 
works similar to the new patch system -- the proper version is called
from V_DrawBlock through a function pointer in the VBuffer object
passed to it (btw, I realized this is a form of polymorphism in C --
pretty sweet in my opinion).

When I started to work on V_TileFlat, which is the function that
draws tiled flat backgrounds for the menus and intermission screens,
I found something weird in the code that does the lowres, 320x200
drawing:

   for (y = 0 ; y < SCREENHEIGHT ; src = ((++y & 63)<<6) + back_src)
      for (x = 0 ; x < SCREENWIDTH/64 ; x++)
      {
         memcpy (back_dest,back_src+((y & 63)<<6),64);
         back_dest += 64;
      }
      
Since "src" is never used inside this loop, the statement
   
   "src = ((++y & 63)<<6) + back_src"

has no side effects, EXCEPT for incrementing y by one.  This means 
that it's doing a bunch of unnecessary work every time the top loop
iterates.

Now, I wondered why such a weird thing would be in this code, so I
started tracing back its history.  First I looked in MBF and as I re-
membered, Lee Killough had rewritten the code there to support hires.
I started to suspect that maybe he'd made a mistake, because it turns
out his loop for hires has the same increment statement for its outer
loop, but in that case, the inside of the loop DOES use the "src" 
variable.

So, I checked the same code in BOOM, and it was the original code
from Linux DOOM, which was a bit different. Here's what it looks
like:

   for (y=0 ; y<SCREENHEIGHT ; y++)
   {
      for (x=0 ; x<SCREENWIDTH/64 ; x++)
      {
         memcpy (dest, src+((y&63)<<6), 64);
         dest += 64;
      }
      if (SCREENWIDTH&63)
      {
         memcpy (dest, src+((y&63)<<6), SCREENWIDTH&63);
         dest += (SCREENWIDTH&63);
      }
   }

At first, this confused me even worse. You can see that their outer
loop does indeed only increment y. But, they have this weird "if"
statement outside the inner loop that tests if the screen width is
not divisible by 64. In a case that it were not, it would draw the
remaining fractional portion of the flat at the end of the current
row on the screen.  But, DOOM only had one resolution, 320x200.
"SCREENWIDTH & 63" is a constant expression which never changes 
value, so that "if" statement is NEVER entered.

So, it seems that either id accidentally put in some totally un-
necessary code, or this is left over from WAY BACK in the alphas when
DOOM was supposed to support several extended resolutions!

What's funny is that when Lee rewrote the code and realized that
test was unnecessary, he ended up accidentally duplicating the
increment statement of his hires loop in the lowres loop.  So even
though he got rid of one redundancy, he introduced another. I just
find that ironic somehow, and it's a great illustration of the some
of the many woes of maintenance programming :)

=====================================================================
04/05/04

SoM figured out the bug in V_DrawBlock. He was just initializing the
y coordinate to the wrong value by mistake.

=====================================================================
04/03/04

Created module v_patch.c

Rewrote and restructured all the V_DrawPatch functions so that the
proper version (unscaled, 2x scaled, or general scaled) gets called
through a new VBuffer object, which can represent the screen or any
arbitrary memory buffer.  Also moved the column drawing into
functions which are called through arrays of function pointers which
are indexed by the drawing type (normal, translated, translucent, or
translated and translucent).  This renders maximum flexibility for
combining the rendering types without requiring the basic patch
drawing loops to be duplicated over and over (while this solution is
a bit like the one in zdoom, I didn't borrow any of Randy's code this
time ;)

Rewrote some code segments to exploit the new VBuffer facility,
including most notably the console background code. It was previously
using a gross hack of temporarily redirecting screens[1] to its own
private buffer, then calling V_DrawPatch. VBuffers make that kind of
crap totally unnecessary.

I removed V_DrawPatchFlexTL and just made V_DrawPatchTL use the
flex tran table. However, I still need to fix some of the calls to it
so that they send in a value which is roughly equivalent to whatever
percentage the current BOOM translucency value is. This won't be
difficult, I just have better things to do right now.

=====================================================================
04/01/04

There won't be any April Fool's jokes in the changelog, so don't
worry about that :P

Preemptively repaired several problems in SoM's retrofitting of the
DOS video code to work within the bounds of the generalized drawing
code.  DOS still only currently has 320x200 and 640x400 modes.  I
might consider adding some more modes for it eventually, but that's
REALLY low priority.

Tweaked a few variables in i_video.c and r_ripple.c to make them
static where it was possible.  Also, reformatted the DOS i_video.c
file because it was still an ugly mess, with tabbed and untabbed 
lines freely intermingling, and several peoples' code-writing styles
all jumbled up.

=====================================================================
03/31/04

Initial integration of SoM's generalized drawing code to allow high
resolutions.  There are some issues, but we will tackle them one by
one.

=====================================================================
Changes since Eternity Engine v3.31 beta 5
=====================================================================
=====================================================================
02/28/04

Making final preparations for a leap year release of Eternity v3.31
public beta 6.

I updated the DOS and MinGW makefiles a few days ago, and there were
no major problems building either of those versions. The MinGW make-
file still desparately needs dependency information, and the info in
the DOS makefile is not perfectly up to date (so it is possible that
modifying a few headers could break some modules).  I really need to
find out how to auto-generate dependency information at compile-time
with GCC, because I know it can be done. fraggle showed me a makefile
that did this once, but I failed to fully understand it, and now I'm
not sure I even have it any more. It would certainly save a lot of
work.

=====================================================================
02/23/04

Continued addressing some user complaints in preparation for beta 6
launch:

1. Generalized DR door types wouldn't allow you to retrigger them
   while they were opening or closing already. Added some code to
   allow this outside of older demos. This kind of minor change
   doesn't justify a comp variable. Who *wouldn't* want the doors
   to function as expected, anyways?
   
2. The map console command would try to start any string given it as
   a map. This lead to some pretty weird behavior if you specified a
   non-existant map, or a lump that existed, but was not a map. It 
   now checks against both of these possibilities, and will report 
   an error message if you give it a bad map name.
   
3. When using -warp, the console would end up with scraps left over
   on the game border if the screen size was less than maximum.
   fraggle did some strange things to the startup code, and there
   was a dead segment in D_Display that should have been getting
   called to take care of this on the first frame that a map was
   rendered. Fixed by checking for autostart in D_DoomMain and 
   (re)setting certain variables to force a border redraw.
   
4. Made some changes so that SDL ignores mouse motion events until
   I_StartFrame has been called the first time. This keeps it from
   queueing mouse motion during startup -- including the call to
   SDL_WarpMouse in the video init -- and then having the player
   pointing off to some wild angle and/or moving around when a map
   starts using -warp. The DOS version may or may not still suffer 
   this problem. Needs testing, I suppose.

=====================================================================
02/22/04

Trying to make progress toward beta 6 release by mopping up some
remaining issues that have been noted by users. Also finding some
other odds-and-ends stuff to take care of.

Rewrote WriteCentredText (note British spelling, heheh) in mn_misc.c
to use the qstring structure instead of maintaining its own reallo-
cating buffer. I'm going to continue doing this until qstring is
used everywhere it can possibly be used.

Also fixed a minor issue where hitting backspace when on the first
help screen would play the "previous menu" sound, even though it
wasn't moving back to a previous screen. A very small oversight in
the menu logic ;)

Moved the particle floor clipping code to P_ParticleThink to complete
streamlining of R_ProjectParticle in response to the previous archi-
tectural change. This is a much more logical location for this code.
The fact it ended up in R_ProjectParticle in the first place was pro-
bably a suggestion that the projection system should have been re-
written much earlier.

=====================================================================
02/20/04

Repaired particles to work with portals by changing the particle
projection to be performed by sector, as normal vissprites are
projected.

Particles have to maintain sector links, and each sector has a list
of the particles that are in it. P_ParticleThinker updates the links
when it moves the particles. This is still significantly less than
what has to be done to maintain mobj position, and part of the
position setting was already being done in R_ProjectParticle anyways,
to get at sector properties such as light level and colormap. The
R_PointInSubsector call which was performed there is now unnecessary,
since particle_t has a subsector pointer.

This is going to come in handy for adding all those new effects I
have planned for Millennium too, since those effects require looking
at an always up-to-date subsector pointer in the particle (ie, a
particle which lives infinitely until it hits the ground, and then
begins to fade).

=====================================================================
02/19/04

Added support for a combined thingtype flags field to EDF. This
allows you to forget about which flags go with which fields, and was
one of the first user requests to be made with respect to EDF. It
just took me a while to come up with a good way to do it ^_^

I rewrote all of the DeHackEd flag parser code to enable this, and
cleaned it up quite a bit in the process. dehflags_t lists are now
terminated by a NULL entry, eliminating the need for a macro using
sizeof to determine the length of the list. All the thing type flags
are also now in one master list rather than three separate ones.

I also added two more fields, addflags and remflags -- these let you
add or subtract a flag list from the thing's current flags, and can
be used in both definitions and delta structures. I realized there
was a need for this a long time ago, but it really needed the above
feature to be finished first for it to be effective. Also, the new
addition of dynamic monster types to zdoom has provided me with an
impetus to get some stuff finished >:D

Changed the EDF thingtype doomednum field to not be inherited. This
makes the most sense to me.

=====================================================================
02/15/04

Tweaked my fix to the sky code again, so that it acts uniformly with
respect to single- and multipatch textures. Otherwise, "long" skies,
which wrap less often around the game world, would be detected as
multipatch textures and would not be stretched when they were short.

This does, however, place something of a limit on what type of
multipatch textures can be used as skies. If you have a multipatch
texture with a patch larger than the texture but which is supposed to
tile where the texture height cuts off, it will not work properly.

Since I have to cut the texture off at the max of the texture height
and the tallest patch height to support Heretic- and Hexen-style 
skies, I can't support general multipatch textures that are meant to 
tile at the texture's height, yet contain patches taller than the 
texture.

I highly doubt this will cause any compatibility issues, but it might
surface as an issue in the future. I'll probably add a note about it
to the sky transfer linedef docs in the editref.

=====================================================================
02/12/04

Completely rewrote the console script running code. It was a gross,
amateur-looking mess, mostly thanks to my early work on it to fix
bugs from SMMU. Now, it is a formalized finite state automaton lexer, 
and it uses the new qstring structure I have written, which provides 
very secure reallocating string buffers. This removes a static limit 
on line length, and fixes the bug where commands on the last line of 
the file would not be run, since they didn't end with a \n. (Thanks
to SargeBaldy for drawing my attention to this neglected code and the
last line bug).

Also rewrote the libConfuse lexer to use the qstring structure, since
the code that m_qstr.c is based on was originally the qstring code in
libConfuse 2.0 -- I have simply generalized and encapsulated it so it 
can be used throughout the engine. This is another unforeseen benefit 
of my having previously integrated libConfuse directly, instead of 
compiling it as a static library or even as a DLL.

=====================================================================
02/11/04

Found out that my previous fix to sky textures wasn't totally right.
Tweaked the code further to be more correct. MBF's sky.wad example
works much better now.

=====================================================================
02/04/04

Upgraded the internal Small VM to v2.4.0 -- this version has lots of
fixes over the previous version, as well as a lot of new language
and VM features.

Added even more new Small natives.

=====================================================================
02/02/04

Added TID system for identifying mapthings in scripts. Restored
StartScript codepointer to full functionality, and added several new
Small natives to test out TIDs. Wrote a fixed point math module for
Small.

=====================================================================
01/28/04

Fixed the fastspeed field for thing types to accept floats in the
same way that the speed field accepts them. This is something I just
forgot to do when I originally implemented the new speed field
behavior.

=====================================================================
01/27/04

Added thingtype inheritance to EDF. E_ProcessThing is now potentially
recursive. When a thingtype inherits from a parent, it tries to
process the parent type first. If the parent type has already been
processed, then it's ok and nothing will happen. Otherwise, it'll
get processed, and recursively process any parent type it might have.

When a thing type inherits from a parent type, its own definition
will be treated more or less like a thingdelta, such that only fields
that are explicitly specified will override those copied in from the
parent.

The only attribute which is not inherited is the DeHackEd number.
This always has to be different, and must be resolved before thing
types are processed, thus it cannot be inherited.

Here's a small example that would create a new Baron enemy whose
only real difference is that he would be 50% translucent:

   thingtype MyNewBaron
   {
      inherits = BaronOfHell
      doomednum = 20001
      translucency = 32768
   }
   
As you can see, inheritance allows definitions for similar thing
types to be drastically minimized, and absolutely no copying or
pasting is required.

Note some changes had to be made to the speedset and nukespecial
code to allow for this, but they were very minor.

=====================================================================
01/26/04

Identified SargeBaldy's problem in a number of crashing maps to be
zero-length REJECT lumps. Time for a lengthy explanation:

In DOOM, maps with zero-length REJECT lumps are accepted and run ok,
although possibly with undefined REJECT behavior (if I am right, the
REJECT would act differently every time you play the map). Although
all the REJECT loading code was the same as it is in Eternity, DOOM's
Z_Malloc would return a 32-byte block when you requested a block of
size zero. This is very odd behavior for any memory manager, and can
result in the type of undefined behavior I describe above.

In BOOM, the entire zone system was rewritten, and one change made to
Z_Malloc was to make zero-size allocations return NULL, as C malloc
and most other sane memory managers will do. This would, however,
leave the rejectmatrix pointer NULL, and since the reject-using code
never checks it for validity, it would segv the first time something
called P_CheckSight. Apparently, this problem is common to all
BOOM-derived source ports. prboom simply refuses to load such maps at 
all currently.

I have fixed the problem (for now at least) by adding code which
generates an "empty" reject matrix when the lump size is zero. It
allocates a buffer of the appropriate size for the map, then fills it
with zeroes (which means that the reject is not useful for helping
reduce line-of-sight calculations).

To be technical, zero-length REJECT lumps are NOT appropriate. The
behavior in the original engine is undefined, and really only worked
by accident. I believe part of the blame for utilities allowing zero-
length REJECTS rests on the Unofficial DOOM Specs, which incorrectly
say that the lump is "optional," which can possibly be interpreted as
meaning it is allowed to be of zero length. Technically, this is not
true, and the REJECT should ALWAYS be the proper size for the map,
EVEN if it is only filled with zeroes.

But, this problem is easy to detect and fix within the engine, so I
will allow it, mainly because it fixes maps which worked (albeit
inconsistently) with vanilla DOOM. 

My fix *could* be improved by actually building a meaningful reject 
matrix for the map, but this would require reject builder code to be 
added to the engine, and isn't something I want to undertake right 
now. Consider it room for possible future expansion.

=====================================================================
01/25/04

Another crashing problem in the portal code was identified within the
past two days. SoM created a "bandaid" patch for the problem, but I
finally nailed down the real cause today to be child portals not
having their minx and maxx members initialized. Fix was simple.

Restored my earlier code to functionalize the portal creation code in
p_spec.c, and changed a chain of if/else if's in R_RenderPortals into
a switch. Also fixed a couple of issues such as missing "void" key-
words in parameter lists, and moved the rportal_t typedef back into
r_portal.h along with its struct.

=====================================================================
01/22/04

An initial problem in the portal system has been fixed and it has
been reintegrated.

I have had to change the way particles are projected, however. As of
right now, they won't work inside portals because of this. In order
for particles to be compatible with portal rendering, they would need
to be projected subsector by subsector, as other vissprites are
projected. This would be a major architectural change for the parti-
cle system, but I think it's probably the best direction to move in.

=====================================================================
01/20/04

Started portal code integration. Experienced problems immediately
which would not be resolved for several days.

Added code to z_zone.c which can print out the entire zone heap block
structure to file. This will be very useful in the future for de-
bugging and optimization. Also changed an assert call in Z_Init into
a RANGECHECK define and altered the code to make it the same as it
is in prboom. This "sanity check" code tests some zone system
invariants which must be true, or else the entire system will not
work.

=====================================================================
01/19/04

Fixed the graphic used on the video options menu to test translucency
settings for all game modes.

=====================================================================
01/14/04

Modified libConfuse to support ignoring text between conditional
function pairs. This allows an "ifenabled" function for EDF which
can weed out DOOM or Heretic definitions when playing the other
game mode.

Now, this raises some issues, which I have addressed as follows:

1. By default, when Eternity loads its own root.edf, it will enable
   only the current game mode. The other game modes will be disabled,
   thus saving a bunch of memory.

2. When user EDFs are loaded, all game modes are enabled by default.
   This allows for backward compatibility, and also allows user EDFs
   to explicitly shut off game modes using the "disable" function.
   
3. As for non-EDF mods which rely on the existence of Heretic stuff
   in DOOM, I haven't solved this yet, but I'm working on some ideas.
   For now you'd need to make a dummy EDF that includes root.edf,
   just to force Heretic definitions to be read. That's kinda silly.

=====================================================================
01/12/04

Continued adding stuff that I need.

1. Added MissileSpread, which I also discussed in the forums a bit.
   It lets a thing instantaneously shoot out N projectiles evenly
   over a given angular sweep (the sweep is always centered on the
   actor's angle with this pointer). This relieves editors from the
   duty of making large sequences of MissileAttack frames with only
   the angle parameter being different.
   
2. Rewrote the translation table code and added support for custom
   sprite translations.  Translation lumps are 256 bytes long and
   contain 1-byte indices (0-255) into the palette. This is the same
   format that's used by the BOOM hud/status bar CR* lumps, and also
   the same format used internally for player translations.
   
   Translation lumps must be between the new markers T_START and
   T_END.  If no T_START lump is found, no custom translations will
   be available.
   
   To use this in EDF, you specify the "translation" field in a
   thingtype, like this:
   
   thingtype <name>
   {
      translation = <number> | <lump name>
   }
   
   If a number is provided, the thing will use one of the internal
   player translations (valid numbers are 0 through 14, with 0
   meaning no translation, and the rest of the numbers being in the
   same order as the colors are for the colour console command -- if
   a number outside the range is provided, it gets wrapped into
   range automatically).
   
   If a lump name is provided, the thing will use the custom
   translation contained in that lump (if the lump doesn't exist
   between T_START and T_END, an error will occur).
   
   This is something else I had always been planning on doing, but
   never got around to. This project has given me an excuse to wipe 
   out a growing number of TODO's. This stuff ought to help Eternity 
   gain a bit more credibility in the editing world.

=====================================================================
01/11/04

Since I've been working on a new editing project of my own, I've
been adding some doo-dads which I've found myself needing. It would
appear that editing for your own port is a very good way to find out
what can be done to add more to it ^_^

1. Added the BulletAttack pointer which I mentioned on the forums.
   Now enemies can use custom bullets too ;)
   
2. Added a variable to EDF called doom2_title_tics. It lets you set
   the length of time that the DOOM II title screen shows. I imagine
   I'll be adding a lot more of these kinds of misc settings
   eventually, but this is the only one for now.
   
3. Added a new flags3 bit, SUPERFRIEND. This allows you to make a
   friend which won't ever attack other friends, even in retaliation.
   Sometimes really powerful friends just shouldn't attack at all,
   since they'll more than likely kill you. Plus, if a friend is a
   meaningful character, it may not make sense for him to retaliate
   (would Robin throw a batarang at Batman? I should hope not!).
   
4. Added a console command called whistle. It lets you teleport one
   friendly thing of a given type to your location. This was inspired
   partially by Lee Killough's changelog note on trying to make a way
   for the player to call his dogs. While teleporting is not what he
   envisioned, it is much easier than overriding the normal AI, it
   will work from anywhere in the map, and for some types of friends,
   it may be natural for them to be able to teleport to you. It's
   a lot of fun when used appropriately ^_^
   
I also discovered a very sinister bug which was preventing EDF from 
being loaded by GFS. The "M_GetFilePath" routine which I wrote a 
while back was starting its process one off the end of the 
destination buffer. Apparently I have been very lucky, since this 
function is called all over the place, and could have caused serious 
effects by corrupting other variables (which is what it was doing to 
the GFS structure's EDF file name).

=====================================================================
01/05/04

Applied schepe's patch to SargeBaldy et al.'s problem of the game
crashing when you alt+tab out of fullscreen mode. I_FinishUpdate
needed to check the return value of SDL_LockSurface. If the lock
fails, the surface is currently invalid and can't be written to.

It just so happens that a DirectX fullscreen hardware surface isn't
valid when you alt+tab out of an application using it, so this is
where the segv was coming from. Unfortunately, the SDL docs are
rather vague about when a surface could become invalid or what you
have to do to handle it, so I never put any contingency code in for
such an event. Thanks to schepe once again for fixing some of the
ugliest problems to ever visit us ^_^

=====================================================================
12/27/03

schepe helped figure out what was causing demo desyncs on so-called
"death exit" demos. fraggle juggled some of the level transition
code around such that the player wasn't getting marked as "reborn"
before P_SetupLevel was called. So, when he would be spawned at
level start, the same stuff that happened in DOOM would not happen.
Fixed easily by restoring the original code order. Doesn't seem to
affect anything adversely; this was probably just a mistake in SMMU.

=====================================================================
12/23/03

Finally fixed the LFN drag and drop issue. Problem wasn't with LFNs
in general, but with paths that had .'s in them. I was using strchr
to look for the extension, when I needed to use strrchr, which looks
for the requested character starting from the "right" end of the
string (ie where the file extension should be).

=====================================================================
EOF
=====================================================================