mirror of
https://github.com/fabiangreffrath/woof.git
synced 2025-08-03 12:47:01 -04:00
1090 lines
36 KiB
Plaintext
1090 lines
36 KiB
Plaintext
Here are the things I've changed/added:
|
|
|
|
|
|
05/16/98
|
|
|
|
1. Unknown Things
|
|
-----------------
|
|
|
|
Changed handling of unknown thing types from an abort with an error msg.
|
|
to a continuation with a warning msg posted to the screen.
|
|
|
|
File affected: p_mobj.c
|
|
|
|
|
|
05/14/98
|
|
|
|
1. New Player Starts
|
|
--------------------
|
|
|
|
Added Player Starts 5-8 using doomednums of 4001-4004. This complies
|
|
with DosDoom and other ports. These starts are ignored when spawning
|
|
Things, so 8-player support is NOT implemented.
|
|
|
|
Files affected: p_mobj.c, doomdef.h
|
|
|
|
|
|
|
|
05/12/98
|
|
|
|
1. MT_PUSH/MT_PULL
|
|
------------------
|
|
|
|
Modified OVER/UNDER height/radius table in info.c for the
|
|
change of numbers from 4001->5001 and 4002->5002.
|
|
|
|
2. OVER/UNDER
|
|
-------------
|
|
|
|
Removed OVER/UNDER code for final Phase I source release.
|
|
Here is a list of the files changed, with their rev numbers
|
|
just prior to the change.
|
|
|
|
1.9 d_net.c
|
|
1.4 doomstat.c
|
|
1.54 g_game.c
|
|
1.43 info.c
|
|
1.6 m_cheat.c
|
|
1.56 m_misc.c
|
|
1.21 p_enemy.c
|
|
1.34 p_map.c
|
|
1.22 p_mobj.c
|
|
1.13 p_user.c
|
|
1.12 doomstat.h
|
|
1.9 info.h
|
|
1.33 makefile
|
|
|
|
|
|
05/05/98
|
|
|
|
1. Documentation and Reformatting
|
|
---------------------------------
|
|
|
|
Added documentation to these files and reformatted them:
|
|
|
|
doomdef.h
|
|
m_menu.c
|
|
p_map.c
|
|
p_mobj.c
|
|
p_user.c
|
|
m_misc.*
|
|
m_bbox.*
|
|
d_event.h
|
|
|
|
2. Removed RECOIL and OPT_BOBBING defines
|
|
-----------------------------------------
|
|
|
|
Removed these from all the files where they appeared.
|
|
|
|
|
|
05/04/98
|
|
|
|
1. Player Bobbing
|
|
-----------------
|
|
|
|
Fixed problem where the player is pressed against a wall while on ice and
|
|
he's still trying to move forward with no success. The momentum code is
|
|
used to drive the bobbing effect, and--though no movement was occurring--
|
|
momentum was still present, causing bobbing to occur. The fix was to kill
|
|
momentum. Compatibility-optioned.
|
|
|
|
File affected: p_map.c
|
|
|
|
|
|
04/22/98
|
|
|
|
1. HU_Start
|
|
-----------
|
|
|
|
Added a call to HU_Start() when leaving the Setup Screens to pick up any
|
|
message changes that were made. Now you don't have to wait until the
|
|
next level to see the changes.
|
|
|
|
|
|
2. Reset to Defaults
|
|
--------------------
|
|
|
|
Added a button item on each of the Setup screens to allow you to reset values
|
|
to the default values. Also collapsed more of the code.
|
|
|
|
From the boom.txt file:
|
|
|
|
"8) Reset to Default Values
|
|
|
|
A "Reset to Default Values" button appears in the upper-right-hand
|
|
corner of each Setup screen (and on the first screen where there are
|
|
multiple screens). When selected, this button blinks.
|
|
|
|
This button allows you to reset all options on this Setup screen (or
|
|
set of screens) to their default values. This is useful if you've
|
|
made a number of changes that don't seem to work together, and you'd
|
|
like to get back to a baseline.
|
|
|
|
Pressing Enter will give you a dialogue box that asks you whether you
|
|
'really' want to reset to the default values. Pressing 'N' exits the
|
|
dialogue without resetting. Pressing 'Y' resets all values.
|
|
|
|
Note: Each screen has its own reset button. There is no single reset
|
|
button that covers _all_ options that appear in all Setup screens. If
|
|
you want to reset _all_ options to their default values, you'll need
|
|
to activate each button separately."
|
|
|
|
Files affected: info.c, m_menu.c
|
|
|
|
|
|
04/14/98
|
|
|
|
1. Recoil, Bobbing, and Monster Remember
|
|
----------------------------------------
|
|
|
|
These items now take immediate effect when toggled from the Setup screens,
|
|
except if a demo is playing or being recorded, or a net game is taking place.
|
|
In those cases, the effect will occur later.
|
|
|
|
File affected: m_menu.c
|
|
|
|
|
|
2. #if PUSHER
|
|
-------------
|
|
|
|
Found this wrapped around an 'allow_pushers = true' in g_game.c. Since
|
|
there's no -DPUSHER in makefile, and all push code is now enabled, I removed
|
|
the wrapper.
|
|
|
|
File affected: g_game.c
|
|
|
|
|
|
|
|
04/13/98
|
|
|
|
1. ESC and F1
|
|
-------------
|
|
|
|
Cemented ESC to the MENU action and F1 to the HELP screen action when
|
|
in normal game play. This ensures that a player can always bring up
|
|
the Main Menu and HELP screens if they get themselves into a key binding
|
|
bind.
|
|
|
|
Neither ESC nor F1 can be bound to another action that is available at
|
|
the same time as MENU and HELP. (I.e you can't rebind F1 to SAVE GAME.)
|
|
|
|
Files affected: g_game.c, m_misc.c, m_menu.c
|
|
|
|
|
|
04/12/98
|
|
|
|
1. New Setup Screens
|
|
--------------------
|
|
|
|
Added these screens:
|
|
|
|
Enemies
|
|
|
|
At the moment, this only has the 'remember' option. This is where
|
|
any AI options should be placed in the future.
|
|
|
|
Messages
|
|
|
|
Options related to HUD messages (mainly colors).
|
|
|
|
Chat Strings
|
|
|
|
Provides the ability to change chat strings. String width is
|
|
limited to what will display on this screen. DEL, left and right
|
|
cursor movement, shifted keys, and overstrike are allowed.
|
|
|
|
|
|
2. Setup/Help Screen Mods
|
|
-------------------------
|
|
|
|
Flopped the "SETTING|ACTION" description on all screens to be
|
|
"ACTION|SETTING". Most noticeable on the HELP screen, where groups had to
|
|
be rearranged to accomodate the flop. The Chat Strings caused this change,
|
|
since they look more natural the new way, especially when editing them.
|
|
|
|
Also consolidated the Setup Screen keystroke handling code and tables
|
|
so that common code paths and table structure could be used. Trimmed 600+
|
|
lines of code. Needed to see all the Setup screen possibilities before
|
|
doing this.
|
|
|
|
Files affected for #1,#2: m_menu.c, m_misc.c, info.c, d_main.c
|
|
|
|
|
|
|
|
04/04/98
|
|
|
|
1. Joystick Support
|
|
-------------------
|
|
|
|
Added support for joysticks. Calibration needs to be done using ASETUP so
|
|
that the joystick information is available in allegro.cfg. Support is for
|
|
up to 4 buttons. Used a CH Flightstick Pro, so will watch for any incoming
|
|
problems from different types of joysticks.
|
|
|
|
Verified rebinding of joystick buttons 1-4, and use of joystick to navigate
|
|
the menu screens.
|
|
|
|
Files affected: i_system.c, i_video.c, m_misc.c, g_game.c, m_menu.c
|
|
|
|
|
|
2. Main Menu Order
|
|
------------------
|
|
|
|
Per user suggestion, rearranged ordering of Main Menu to place more often-used
|
|
items at the top.
|
|
|
|
Tested with Doom shareware, Doom, Ultimate Doom, and Doom2.
|
|
|
|
File affected: m_menu.c
|
|
|
|
|
|
04/03/98
|
|
|
|
1. Placed a border around the outside of the color palette in the Automap
|
|
setup screen.
|
|
|
|
Added a "don't show" symbol (X) in slot 0 of the palette. When this is
|
|
chosen, the color is set to zero, which the Automap code interprets as
|
|
"don't show".
|
|
|
|
Allowed slot 247 to be active again (it was CYAN) and to represent pure
|
|
BLACK, since that color is no longer available in slot zero.
|
|
|
|
Files affected: m_menu.c, info.c
|
|
|
|
|
|
04/01/98
|
|
|
|
1. Fixed two Seg Violations caused by dereferencing NULL pointers in the
|
|
Setup menus. These are only seen when running in DOS Mode. Running in
|
|
a Win95 DOS window does not show the problem.
|
|
|
|
2. Added Automap screen to the Setup menus. Now you can set automap colors
|
|
using a color palette rather than changing the numbers in BOOM.CFG.
|
|
|
|
Files affected: m_menu.c, info.c
|
|
|
|
|
|
03/30/98
|
|
|
|
1. Extended HELP Screens
|
|
------------------------
|
|
|
|
Added user-defined HELP screens.
|
|
|
|
If you press ENTER while on BOOM's dynamic HELP screen, and HELP01 has
|
|
been defined in a PWAD, HELP01 is displayed. From there, repeated ENTERs
|
|
will display HELP02, HELP03, ... to an upper limit of HELP99.
|
|
|
|
File affected: m_menu.c
|
|
|
|
|
|
2. Setup Menus
|
|
--------------
|
|
|
|
Added the first few of several Setup Menus. They can be reached via the
|
|
"Setup" item on the Main Menu.
|
|
|
|
When on a Setup screen, these actions are allowed:
|
|
|
|
Up Arrow and Down Arrow move you from one item to the next.
|
|
|
|
ENTER highlights an item and lets you change it. Any item that gets
|
|
changed is immediately in effect.
|
|
|
|
Left Arrow brings up the previous screen if present.
|
|
|
|
Right Arrow brings up the next screen if present.
|
|
|
|
Backspace leaves this Setup screen and brings up the Setup menu.
|
|
|
|
ESC leaves Menus entirely.
|
|
|
|
(Of course, if you rebind the keys used with menus, you can perform the
|
|
above actions with the new keys...)
|
|
|
|
|
|
The Setup Menu now contains
|
|
|
|
Key Bindings
|
|
|
|
All bindable actions are represented in groups.
|
|
|
|
If a key is bound to an action, and that key was previously bound
|
|
to another action that could be performed in the same input 'mode'
|
|
then the two bindings are swapped. I.e. if F1 brings up HELP and F2
|
|
brings up SAVEGAME, and you bind F2 to HELP, F1 will move over and
|
|
be bound to F2.
|
|
|
|
(Binding multiple keys to the same action should be possible in
|
|
Phase 2.)
|
|
|
|
You can bind mouse buttons in the same manner as keys, but in
|
|
Phase 1, you're limited to the run, strafe, use, and forward actions.
|
|
Phase 2 should expand these to _any_ action.
|
|
|
|
Joysticks aren't supported at the moment, but are represented...
|
|
|
|
|
|
Weapons
|
|
|
|
This is mainly where you can define your weapon preferences. As in
|
|
Key Bindings, if you plug a weapon into a slot, whatever was there
|
|
moves over to where the new setting came from.
|
|
|
|
|
|
Status Bar / HUD
|
|
|
|
Nothing unusual here.
|
|
|
|
|
|
Files affected: m_menu.c, info.c, d_main.c. (D_main.c was changed to support
|
|
taller menu graphics by redrawing the status bar more often.)
|
|
|
|
|
|
03/25/98
|
|
|
|
Fixed headsecnode use that was misusing memory. Required
|
|
setting it to NULL when a level started.
|
|
|
|
File affected: g_game.c
|
|
|
|
|
|
03/21/98
|
|
|
|
|
|
1. Pushers
|
|
----------
|
|
Changed all pusher code to use controlling linedefs. Removed all the old
|
|
code that was using constant values based on sector special types.
|
|
|
|
The effects have been expanded, and are controlled by new linedef types
|
|
and an on/off switch in the sector type.
|
|
|
|
Constant pushers
|
|
----------------
|
|
Two types of constant pushers are available, wind and current. Depending
|
|
on whether you are above, on, or below (special water sectors) the ground
|
|
level, the amount of force varies.
|
|
|
|
The length of the linedef defines the 'full' magnitude of the force, and
|
|
the linedef's angle defines the direction.
|
|
|
|
line type above on under
|
|
--------- ----- -- -----
|
|
wind 224 full half none
|
|
current 225 none full full
|
|
|
|
The linedef should be tagged to the sector where you want the effect. The
|
|
special type of the sector should have bit 9 set (0x200). If this bit
|
|
is turned off, the effect goes away. For example, a fan creating a wind
|
|
could be turned off, and the wind dies, by changing the sector type and
|
|
clearing that bit.
|
|
|
|
Constant pushers can be combined with scrolling effects and point pushers.
|
|
|
|
Point pushers
|
|
-------------
|
|
Two types of point pushers are available, push and pull.
|
|
|
|
The previous implementation of these was SECTOR-SPECIFIC. The new
|
|
implementation ignores sector boundaries and provides the effect in a
|
|
circular area whose center is defined by a Thing of type 4001 (push)
|
|
or 4002 (pull). The effect will not occur if there is no line-of-sight
|
|
from a 'candidate' Thing to the center point.
|
|
|
|
You now also don't have to set any option flags on these Things. A new
|
|
linedef type of 226 is used to control the effect, and this line should be
|
|
tagged to the sector with the 4001/4002 Thing.
|
|
|
|
The length of the linedef defines the 'full' magnitude of the force, and
|
|
the force is inversely proportional to distance from the point source. If
|
|
the length of the controlling linedef is L, then the force is reduced to
|
|
zero at a distance of 2L.
|
|
|
|
The angle of the controlling linedef is not used.
|
|
|
|
The sector where the 4001/4002 Things reside must have bit 9 set (0x200)
|
|
in its type. If this is turned off, the effect goes away.
|
|
|
|
Point pushers can be combined with scrolling effects and constant pushers.
|
|
|
|
Affected files: p_map.c, p_spec.c, makefile, st_stuff.c, g_game.c,
|
|
m_misc.c, p_mobj.c, p_user.c, p_spec.h, doomdef.h, info.c, info.h,
|
|
p_mobj.h, p_saveg.c.
|
|
|
|
|
|
2. Msecnode Freelist
|
|
--------------------
|
|
Nodes that are used to populate the touching_sectorlist and
|
|
touching_thinglist lists are now retrieved from and returned to a freelist
|
|
of nodes. When a node request is made and no nodes are available, a new
|
|
one is Z_Malloc'ed. Nodes are never Z_Free'd until the level is finished.
|
|
This should improve performance, but probably won't be noticeable.
|
|
|
|
|
|
3. Resurrected Monsters Sticking Together
|
|
-----------------------------------------
|
|
The Archvile resurrection code checked to see if the candidate corpse would
|
|
fit in the space around it. Corpses are considered non-solid (so you can
|
|
pass through them) so they would always fit, even if they ended up sharing
|
|
space with a neighbor after resurrection.
|
|
|
|
This bug is fixed.
|
|
|
|
File affected: p_enemy.c
|
|
|
|
|
|
03/20/98
|
|
|
|
1. Friction
|
|
-----------
|
|
Changed all friction (ice/sludge) code to use controlling linedefs.
|
|
Removed all the old code that was using constant values based on sector
|
|
special types. All features prior to this build have been carried over
|
|
(bouncing off walls, overcoming inertia from a dead stop, proper effect
|
|
when hanging out over ledges, etc.).
|
|
|
|
Now, to use increased or decreased friction, a new linedef type (223) is
|
|
available. The length of the linedef controls the type and magnitude of
|
|
the friction variance. Lengths from 1->99 are used for sludge-like sectors.
|
|
(A length of 67 is equivalent to the sludge effect in prior builds.)
|
|
A length of 100 gives you normal friction. Lengths from 101->200 will
|
|
give you icy floors. (A length of 189 is equivalent to the icy effect in
|
|
prior builds.)
|
|
|
|
The controlling linedef should be tagged to the sector(s) where you want
|
|
the effect. The special types of the sectors should have their FRICTION_MASK
|
|
bit turned on. (ox100) See log_jff.txt for details on generalized sector
|
|
types. One quick way to turn off the effect is to have a switch that
|
|
changes the sector type in a way that turns that bit off. You could
|
|
then have a 'change floor texture and type' switch that 'melts the ice' in a
|
|
sector, and turns it from icy to normal. Or a 'change floor texture and type'
|
|
switch that 'freezes' the floor, creating ice.
|
|
|
|
If there is more than one controlling linedef for a sector, the one with
|
|
the most friction will prevail. (Sludge beats ice.)
|
|
|
|
Details on a new structure needed for all this to work
|
|
------------------------------------------------------
|
|
Sector_t has a thinglist that is a linked list of every object whose
|
|
center point is in a sector.
|
|
|
|
I'm interested in knowing the complete list of objects that either are
|
|
partially in a sector or are entirely in a sector. This would be a
|
|
superset of 'thinglist'.
|
|
|
|
Thinglist works nicely because the links run through the mobj_t's of the
|
|
objects, so it's easy to add and delete objects from the world by playing
|
|
with these links.
|
|
|
|
In converting friction and pushers from Thing control to linedef control,
|
|
I've found that I can't rely on 'thinglist' to handle all the cases that
|
|
will arise as moving Things cross sector boundaries. For example, assume
|
|
sector A and sector B share a linedef, and A's floor is higher than B's
|
|
floor. A player perched on the linedef could have his center point in B,
|
|
but his feet on A's floor. A search through A's thinglist won't find him,
|
|
so any sector A effect won't be applied.
|
|
|
|
To deal with this problem, I've created a new structure
|
|
|
|
typedef struct msecnode_s
|
|
{
|
|
sector_t* m_sector; // a sector containing this object
|
|
struct mobj_s* m_thing; // this object
|
|
struct msecnode_s* m_tprev; // prev msecnode_t for this thing
|
|
struct msecnode_s* m_tnext; // next msecnode_t for this thing
|
|
struct msecnode_s* m_sprev; // prev msecnode_t for this sector
|
|
struct msecnode_s* m_snext; // next msecnode_t for this sector
|
|
} msecnode_t;
|
|
|
|
We create a new 'thinglist' called 'touching_thinglist' that links together
|
|
a set of these nodes, each node representing a Thing that encroaches on a
|
|
sector. (Whether its center point is in the sector or not.) 'thinglist'
|
|
then becomes a subset of 'touching_thinglist'.
|
|
|
|
We also create a second set of links through these nodes, call it
|
|
'touching_sectorlist', and add it to each Thing's mobj_t structure. As a
|
|
Thing is spawned and moves through the world, this set of links is used
|
|
to identify all the sectors the Thing encroaches upon.
|
|
|
|
In the following diagram, Thing N encroaches on sectors M and M+1.
|
|
Thing N+1 encroaches on sectors M and M+2.
|
|
|
|
|
|
Thing N Thing N+1
|
|
(touching_thinglist) (touching_thinglist)
|
|
| |
|
|
= | = |
|
|
| | | |
|
|
| V | V
|
|
-------- --------
|
|
| | | |
|
|
Sector M ||-- | | <------ | | <------
|
|
| node | | node |
|
|
(touching_sectorlist) ------> | | ------> | | ------>
|
|
| | | |
|
|
-------- --------
|
|
^ | ^ |
|
|
| | | |
|
|
| | | |
|
|
| V | |
|
|
-------- | |
|
|
| | | |
|
|
Sector M+1 ||-- | | <-----------------------
|
|
| node | | |
|
|
(touching_sectorlist) ------> | | ----------------------->
|
|
| | | |
|
|
-------- | |
|
|
| | |
|
|
| | |
|
|
| | |
|
|
= | V
|
|
--------
|
|
| |
|
|
Sector M+2 ||-- | | <------
|
|
| node |
|
|
(touching_sectorlist) -----------------------> | | ------>
|
|
| |
|
|
--------
|
|
|
|
|
|
|
|
=
|
|
|
|
When a Thing is spawned, a node gets created for each sector the Thing
|
|
appears in, and the node is linked into the lists.
|
|
|
|
When a Thing vacates a sector, a node is unlinked and deleted.
|
|
|
|
When a Thing enters a sector, a node is created and linked in.
|
|
|
|
When a Thing is in a sector both before and after a move, no nodes are
|
|
deleted or added.
|
|
|
|
When a Thing is removed, its nodes are unlinked and deleted.
|
|
|
|
Since movement is handled at the 'Thing' level, mobj_t->touching_sectorlist
|
|
allows quick access to all nodes belonging to the Thing.
|
|
|
|
Since sector effects are handled by Thinkers, and applied across all
|
|
Things in a sector, sector_t->touching_thinglist allows quick access to all
|
|
nodes of affected Things.
|
|
|
|
FUTURE WORK: Keep a free list of nodes. When a node is deleted, put it on
|
|
the list. When a node is needed, take it from the list. Only go to the
|
|
memory management routines when the free list is NULL.
|
|
|
|
|
|
03/12/98
|
|
|
|
1. Checked in a friction fix that should better deal with the fact that
|
|
player speed seems to affect how friction is determined. In a
|
|
constant-friction world, this doesn't matter, but when friction is
|
|
expected to change exactly at a sector boundary, it presents a problem.
|
|
This should fix Jonathan's problem of jumping over a high-friction area
|
|
but 10% of the time picking up high friction when landing on the other
|
|
(normal) side.
|
|
|
|
2. Adjusted the 'getting started' movement in a high-friction sector
|
|
to simulate a slow start but gaining your footing after about 2 seconds.
|
|
Suggested by Paul.
|
|
|
|
3. Set friction to the original value if the IDCLIP cheat is on, reported
|
|
by Gary.
|
|
|
|
4. Turned off any pusher effects if the IDCLIP cheat is on.
|
|
|
|
|
|
03/10/98
|
|
|
|
Checked in the following:
|
|
|
|
a) A friction bug fix similar to the previous one (neighboring sectors).
|
|
|
|
b) new cheat codes for friction (TNTICE), pushers (TNTPUSH), and over/under (TNTOVER). The global variables are still present, but commented out of the configuration code. I did not touch any of the savegame or demo code, so Lee can adjust the use of the globals to his liking.
|
|
|
|
c) a version of m_menu.c with the #defines removed from around the HELP code. This code now behaves in the manner described by LEESFIXES.
|
|
|
|
Here's the behavior at this point:
|
|
|
|
ID Shareware [Read This]->ad [Enter key]->old help
|
|
BOOM Shareware [Read This]->ad [Enter key]->new help
|
|
ID Shareware [F1]->ad [Enter key]->old help
|
|
BOOM Shareware [F1]->new help [Enter key]->menu
|
|
|
|
ID DOOM [Read This]->ad [Enter key]->old help
|
|
BOOM DOOM [Read This]->ad [Enter key]->new help
|
|
ID DOOM [F1]->ad [Enter key]->old help
|
|
BOOM DOOM [F1]->new help [Enter key]->menu
|
|
|
|
ID Ult DOOM [Read This]->old help [Enter key]->menu
|
|
BOOM Ult DOOM [Read This]->credits [Enter key]->new help
|
|
ID Ult DOOM [F1]->old help [Enter key]->menu
|
|
BOOM Ult DOOM [F1]->new help [Enter key]->menu
|
|
|
|
ID DOOM2 [F1]->old help [Enter key]->menu
|
|
BOOM DOOM2 [F1]->new help [Enter key]->menu
|
|
|
|
|
|
03/09/98
|
|
|
|
1. Fixed Bug in FRICTION Code
|
|
-----------------------------
|
|
|
|
Fixed a bug in the FRICTION code where you could pick up the friction value
|
|
of a lower sector if hanging out over the edge of an upper one. (Nasty
|
|
bugger to fix!)
|
|
|
|
Had to add a 'friction' field to mobj_t, so any savegames prior to this
|
|
are NG.
|
|
|
|
Modules affected: p_user.c, p_map.c, p_mobj.c, p_local.h, p_maputl.c,
|
|
p_mobj.h, doomdef.h
|
|
|
|
|
|
2. Seperately Bound Menu and Automap Keys
|
|
-----------------------------------------
|
|
|
|
Allowed menu, movement, and automap keys to be separately bound.
|
|
|
|
Modules affected: m_menu.c, m_misc.c, g_game.c, am_map.c
|
|
|
|
|
|
3. Invisible Sprite
|
|
-------------------
|
|
|
|
Added code--courtesy of Ty and Jim--to make the MT_PUSH Thing invisible.
|
|
(Prior to this it was a candle.) Gave MT_PUSH some height, width, and mass
|
|
to avoid possible math problems.
|
|
|
|
Modules affected: info.c, info.h
|
|
|
|
|
|
03/04/98
|
|
|
|
1. Dynamic BOOMHELP Screen
|
|
--------------------------
|
|
|
|
Shareware, DOOM1, and DOOM2 help screen are now dynamic. The key bindings
|
|
shown are what's current. The screen has been rearranged to group keys by
|
|
action. The plasma rifle, bfg, and ssg are not shown in shawareware. The ssg is
|
|
not shown in DOOM1.
|
|
|
|
This is wrapped by #define NEW_HELP_SCREENS.
|
|
|
|
Modules affected: m_menu.c, doomdef.h, makefile
|
|
|
|
|
|
02/27/98
|
|
|
|
1. Player Bobbing is now optional
|
|
---------------------------------
|
|
|
|
Player bobbing can now be controlled by the player_bobbing config option.
|
|
|
|
This is wrapped by #define OPT_BOBBING.
|
|
|
|
Modules affected: m_misc.c, p_user.c, makefile
|
|
|
|
|
|
2. Weapon Selection
|
|
-------------------
|
|
|
|
Put gamemode wrappers around SSG, plasma, and BFG at selection time
|
|
so that selecting these in registered DOOM or shareware DOOM will not
|
|
cause a Segment Violation.
|
|
|
|
Module affected: g_game.c
|
|
|
|
|
|
3. Weapon Ownership
|
|
-------------------
|
|
|
|
Changed the IDFA cheat so you can't own weapons that aren't in the version
|
|
of the game you're playing. Shareware status bar was showing plasma rifle
|
|
and BFG after IDFA.
|
|
|
|
Module affected: st_stuff.c
|
|
|
|
|
|
|
|
02/24/98
|
|
|
|
1. Added key_hud
|
|
----------------
|
|
|
|
Changed the name of the key_define config variable to key_hud since the
|
|
F5 key brings up the HUD now.
|
|
|
|
|
|
2. Weapon recoil
|
|
----------------
|
|
|
|
Added weapon recoil, including recoil during refire, which is when you
|
|
hold down the fire key. There are different recoil values for each
|
|
weapon, determined by experiment. The recoil is applied at the point
|
|
where the 'muzzle blast' appears rather than at the point where the key
|
|
is pressed, due to the slight delay when firing the BFG.
|
|
|
|
This is wrapped by #define RECOIL, as well as a weapon_recoil config switch.
|
|
|
|
|
|
3. Varying friction
|
|
-------------------
|
|
|
|
A certain amount of friction is applied to player movement so he slows
|
|
down in a realistic way. By decreasing the friction applied, we can
|
|
simulate an icy floor. By increasing it, we can simulate mud or sludge
|
|
or magnetic floors. Two new 'special sector' values, 18 and 19 are used;
|
|
18 for less friction, 19 for more. When the player enters such a sector,
|
|
the friction value changes. In all other sectors, the old friction value
|
|
is used. Friction is not applied when the player is in the air. Friction
|
|
_is_ applied if the player is walking across other Things when that is
|
|
allowed.
|
|
|
|
On both types of floors, 'getting started' is slowed down slightly, to
|
|
simulate getting your footing.
|
|
|
|
Future: apply varying friction to monster movement.
|
|
|
|
This is wrapped by #define FRICTION, as well as a variable_friction
|
|
config switch.
|
|
|
|
|
|
4. Wall bouncing
|
|
----------------
|
|
|
|
On an icy floor, the player can bounce off of walls if the angle of
|
|
approach is less than 45 degrees from the wall's normal. If greater than
|
|
45 degrees, the player will slide along the wall. Some momentum is lost
|
|
during the bounce, and you'll get the 'ooof' sound.
|
|
|
|
Future: if the player's speed is large enough, some damage is possible.
|
|
|
|
This is wrapped by #define FRICTION, as well as a variable_friction
|
|
config switch.
|
|
|
|
|
|
5. Push
|
|
-------
|
|
|
|
A new 'special sector' 20 allows for a 'water current' or 'wind' effect.
|
|
This is applied whether the player is on the ground or in the air.
|
|
|
|
There are two types of push that can be applied:
|
|
|
|
a) constant push across the sector
|
|
|
|
b) push emanating from a point in the sector, or drawing the player
|
|
toward a point in the sector
|
|
|
|
A new Thing, MT_PUSH, has been created. Place one in a sector 20 and the
|
|
code looks at the MT_PUSH's flags (options) to determine which type of
|
|
push is being applied. Bits 8->10 give the push magnitude, (values 0->7).
|
|
If bit 11 is set, then it's a type b) push, otherwise it's type a). For a
|
|
type a) push, the Thing's angle gives the push direction. For a type b) push,
|
|
if bit 12 is set, the player is pulled toward the push point, otherwise
|
|
he's pushed away.
|
|
|
|
Type a) push force is constant across the sector.
|
|
|
|
Type b) push force diminishes linearly as you get farther from the point
|
|
source.
|
|
|
|
This effect can be used to create wind tunnels or water currents, ala Quake.
|
|
|
|
Future: apply push to monsters.
|
|
|
|
Future: if the floor is a liquid, don't apply push when the player is off
|
|
the ground. (No water current in the air, eh?)
|
|
|
|
Future: Type b) push force could diminish exponentially.
|
|
|
|
This is wrapped by #define PUSHERS, as well as a allow_pushers config switch.
|
|
|
|
|
|
6. Sprite Height
|
|
----------------
|
|
|
|
THIS FEATURE IS A PHASE II ITEM. IT'S DISABLED FOR PHASW I BETA!
|
|
|
|
a) Added the ability to jump over a blocking Thing if your feet are above the
|
|
top of the Thing.
|
|
|
|
You can now stop while above a Thing, which means that you're standing
|
|
on top of it. This allows for using Things as stepping stones, or sitting
|
|
on the head of a monster. Walking across Things takes on the same
|
|
height-checking that takes place when moving up or down steps. Friction is
|
|
also applied, as if you were on the ground.
|
|
|
|
Special sector damage (i.e. lava) doesn't happen when you're perched atop a
|
|
Thing sitting in the sector. A push force in your sector may affect you.
|
|
|
|
Allowing this meant that the Thing heights needed to be corrected. In
|
|
ID's code, Thing heights weren't always right, but it didn't matter much.
|
|
Now, whenever the code initializes height for a spawned Thing, it will either
|
|
use the old value (in compatibility mode) or a new value (in non-compatibility
|
|
mode).
|
|
|
|
Added two new fields to mobj_t: above_thing, which points to the mobj_t
|
|
of the thing you're above, and below_thing, which points to the mobj_t
|
|
of the thing you're below.
|
|
|
|
Added special 'saving/loading game' code for these new fields following
|
|
Lee's example.
|
|
|
|
b) Added the ability to move under a blocking Thing if your head is below the
|
|
bottom of the Thing.
|
|
|
|
Everything is wrapped by #define OVER_UNDER, as well as an over_under
|
|
config switch.
|
|
|
|
WARNING: THIS FEATURE IS INCOMPLETE! IT HAS BUGS! IT IS HERE FOR OTHERS
|
|
TO EXAMINE.
|
|
|
|
|
|
02/21/98
|
|
|
|
1. Screen clear
|
|
|
|
Minor change: added screen clear and color band at startup. This is
|
|
commented out until after beta.
|
|
|
|
Addendum (2/24) : this might have been overwritten on purpose by Lee. Have to
|
|
see where to put it back in.
|
|
|
|
|
|
02/20/98
|
|
|
|
1. Initial sprite translucency
|
|
|
|
Added preliminary ability to draw translucent sprites. This requires
|
|
the presence of tranmap.wad. This has one lump, TRANMAP, which
|
|
contains tranmap[256][256], where
|
|
|
|
tranmap[i][j] = index of best matching color for Rk,Gk,Bk where
|
|
|
|
Rk = (Ri + Rj)/2
|
|
Gk = (Gi + Gj)/2
|
|
Bk = (Bi + Bj)/2
|
|
|
|
This means the painted color is the average of the existing color
|
|
and the new color. Averaging RGB values simulates translucency.
|
|
|
|
I copied R_DrawColumn, changed the copy's name to R_DrawTLColumn, and added the
|
|
changes at the point where the pixels are drawn. This keeps the
|
|
decision-making about translucency at a higher level, so as not to impact
|
|
performance more than necessary.
|
|
|
|
I wrote a program tranfilt.exe to create TRANMAP. It's in the
|
|
boomutil directory under my home directory on the server. Use its output
|
|
with WinTex to create the lump.
|
|
|
|
I added a config-file option "translucency". There's been some talk about
|
|
being able to turn this on/off generally for performance reasons. If we
|
|
decide not to have any default translucent Things (see below) we can remove
|
|
this later.
|
|
|
|
I added a TNTTRAN cheat code to turn translucency on or off for testing. I added
|
|
an MF_TRANSLUCENT bit to the p_mobj.h file to indicate that a sprite is
|
|
translucent, and modified several Thing definitions in info.c to make them
|
|
translucent. (I.e. imp, smoke, BFG blast, etc.) Look for MF_TRANSLUCENT.
|
|
These should be modified later when we decide which Things _should be_
|
|
translucent by default, if any (i.e. not imps). For Things that can be
|
|
seen during a level-editing session (i.e. imps) we'll need a way to turn
|
|
translucency on/off.
|
|
|
|
This work is preliminary, and does not handle translucent textures. The
|
|
solution there may be slightly different, and is a Phase II or III project.
|
|
|
|
|
|
02/14/98
|
|
|
|
1. User-defined keys (bindings)
|
|
|
|
ALL KEYS that trigger some action can now be defined in the config file.
|
|
Running BOOM with no config file will give you the key_* strings that can
|
|
be remapped. You're going to need a SETUP program though unless you
|
|
learned key codes in 4th grade. Now you can map your roommate's weapon
|
|
keys to garbage while he's asleep.
|
|
|
|
Here are all the keys that can be remapped. If you can think of any I
|
|
missed, let me know. (A few of these were already there.)
|
|
|
|
default.cfg key pressed
|
|
----------- -----------
|
|
key_right RIGHT ARROW
|
|
key_left LEFT ARROW
|
|
key_up UP ARROW
|
|
key_down DOWN ARROW
|
|
key_strafeleft ','
|
|
key_straferight '.'
|
|
key_strafe ALT
|
|
key_speed SHIFT
|
|
key_autorun CAPSLOCK
|
|
key_fire CTRL
|
|
key_use ' '
|
|
key_escape ESCAPE
|
|
key_help F1
|
|
key_savegame F2
|
|
key_loadgame F3
|
|
key_soundvolume F4
|
|
key_detail F5
|
|
key_quicksave F6
|
|
key_endgame F7
|
|
key_messages F8
|
|
key_quickload F9
|
|
key_quit F10
|
|
key_gamma F11
|
|
key_spy F12
|
|
key_pause PAUSE
|
|
key_backspace BACKSPACE
|
|
key_enter ENTER
|
|
key_map TAB
|
|
key_mapgobig '0' (zero)
|
|
key_mapfollow 'f'
|
|
key_mapmark 'm'
|
|
key_mapclear 'c'
|
|
key_mapgrid 'g'
|
|
key_reverse '/'
|
|
key_zoomin '='
|
|
key_zoomout '-'
|
|
key_chat 't'
|
|
key_chatplayer1 'g'
|
|
key_chatplayer2 'b'
|
|
key_chatplayer3 'i'
|
|
key_chatplayer4 'r' Will need to add more for players > 4
|
|
key_weapontoggle '0' (zero)
|
|
key_weapon1 '1'
|
|
key_weapon2 '2'
|
|
key_weapon3 '3'
|
|
key_weapon4 '4'
|
|
key_weapon5 '5'
|
|
key_weapon6 '6'
|
|
key_weapon7 '7'
|
|
key_weapon8 '8'
|
|
key_weapon9 '9'
|
|
|
|
2. New weapon toggle key
|
|
|
|
The 0 (zero) key can be used to toggle between your most preferred
|
|
weapons that still have ammo. The key always chooses 'the most preferred
|
|
weapon other than the one that's showing, that still has ammo'. Don't
|
|
like my key choice? See #1 above.
|
|
|
|
3. SSG
|
|
|
|
The SSG now _really_ comes up when you hit the '9' key. I had to extend
|
|
BT_WEAPONMASK from 3 bits to 4 to enable this.
|
|
|
|
4. New Quick Reverse key
|
|
|
|
The '/' key will give you that quick 180-degree turn like mouse players
|
|
can execute.
|
|
|
|
5. Caps Lock is now Autorun
|
|
|
|
The Caps Lock key toggles you in and out of Autorun. As Jim told me, it's
|
|
like hiring someone to hold down the SHIFT key while you play. Good way
|
|
to put it.
|
|
|
|
|
|
01/30/98
|
|
|
|
1. Faster end-mission display text
|
|
----------------------------------
|
|
|
|
In compatibility mode, the end-mission text is displayed in its normal, slow
|
|
manner. In non-compatibility mode, the text comes up all at once.
|
|
|
|
2. Delimiter 0 bug in P_BlockLinesIterator in p_maputl.c
|
|
--------------------------------------------------------
|
|
|
|
The lines list carried in each block of the blockmap always starts with
|
|
a 0 and ends with a -1. These are the delimiters, and the linedef values
|
|
of lines that appear in a block are inserted between the 0 and the -1.
|
|
I.e. 0,330,332,-1 means that linedefs 330 and 332 appear in this block.
|
|
The code in P_BlockLinesIterator was treating the delimiting starting 0
|
|
as linedef 0 and applying whatever function was passed to it to this line.
|
|
I bumped the 'list' pointer ahead of time to get past the 0 delimiter
|
|
before applying the function. BTW, a block with linedef 0 in it looks like
|
|
0,0,n,...,-1.
|
|
|
|
(Later on, Lee wrapped it in the compatibility flag because it threw
|
|
the crusher demo out of sync. Go figure.)
|
|
|
|
|
|
01/28/98
|
|
|
|
1. Pain Elemental fires Lost Souls through blocking lines.
|
|
----------------------------------------------------------
|
|
|
|
A Pain Elemental can fire Lost Souls through impassable, monsters can't
|
|
cross, and one-sided lines. This is the cause of Lost Souls who are found
|
|
wandering outside the map.
|
|
|
|
I included a check of the trajectory intersecting these kinds of lines, and
|
|
disallow the Lost Soul spawn if the trajectory is blocked.
|
|
|
|
Also added a check to make sure the Lost Soul actually appears in a
|
|
legal space, i.e. isn't being spawned above the ceiling or below the
|
|
floor of its new sector.
|
|
|
|
Though this is a bug, it might break demos, so it has the
|
|
compatibility flag wrapped around it.
|
|
|
|
2. Pain Elemental can't shoot Lost Souls if >20 already present
|
|
---------------------------------------------------------------
|
|
|
|
Lee already removed this limit, but I extended the compatibility wrapper to
|
|
include the counting process.
|
|
|
|
3. Archvile creates ghosts
|
|
--------------------------
|
|
|
|
These are those nasty, can't kill w/o a rocket bounce guys that walk through
|
|
walls after Archie resurrects their door-crushed remains.
|
|
|
|
I suggest 3 options:
|
|
|
|
a. no change (compatibility mode)
|
|
b. resurrected monsters are killable and cannot walk through walls
|
|
(bug fixed)
|
|
c. Archie ignores crushed monsters
|
|
|
|
Details:
|
|
|
|
When a monster dies, his new height is 1/4 his old height.
|
|
|
|
When a dead monster is crushed, he's turned into a GIB and given zero
|
|
height and zero radius.
|
|
|
|
When a monster is resurrected by Archie, Id multiplies the 'dead' height by
|
|
4 to restore it to normal. But if Archie's resurrecting a GIB, 4 times zero
|
|
is still zero. Id was also not restoring his radius.
|
|
|
|
So a ghost is a point-monster of zero height and width. He isn't killable
|
|
because you're always shooting over his head. Nearby rocket blasts killed
|
|
him because the blast radius code probably doesn't check height, just
|
|
existence w/in the radius.
|
|
|
|
To fix the bug, I restored the monster's height and radius at
|
|
resurrection time.
|
|
|
|
Everything else about him was ok. I also had to fix a check that Id had to
|
|
make sure the sector was tall enough to accept the resurrected monster.
|
|
This was done before the actual resurrection, and was using the GIB's zero
|
|
height, which always fit.
|
|
|
|
|
|
4. Added the TNTCOMP cheat code
|
|
-------------------------------
|
|
|
|
This toggles the compatibility flag on/off, for run-time checking of
|
|
compatibility-flag-wrapped code.
|
|
|
|
|
|
|
|
|
|
|