The editor number for player start spot 5 is now stored in the game info
so that there's only one place where this check needs to be done.
- Fixed: WIF_NOAUTOAIM only worked for projectiles unlike Skulltag's original
implementation.
SVN r1997 (trunk)
savegames would hold the full file path for wads that had been specified
with backslash characters, because GetWadName() would not trim off the
path.
SVN r1994 (trunk)
former used fistp, which is not portable across platforms, so cannot be
used in the play simulation. They were only suitable for the renderer.
xs_Float.h also has a very fast float->fixed conversion, so FLOAT2FIXED
uses that now.
(And I also learned that the FPU's round to nearest is not the rounding I
learned in grade school but actually Banker's Rounding. I had no idea.)
(Also, also, the only thing that could have made quickertoint faster than
toint was that it stored a 32-bit int. I never timed them, and I doubt in
practice there was any real difference between the two.)
- Changed atan2f to atan2. Using floats is not a win, because the result is
returned as a double on the x87 stack, which the caller then needs to cast
down to a float using fst/fld.
SVN r1990 (trunk)
* Looping sounds that have been playing for a very long time, were evicted,
and then were restarted need to have their positions clamped to lie
within the bounds of the sounds. If we try to set a start position very
far beyond the end, it will overflow inside FMOD and not work.
* A start time of 0 is not actually valid and means the sound was never
assigned a start time.
- The latter bug also reveals a problem with starting looped sounds evicted:
They need to be assigned a start time so if they should have the opportunity
to start later, they will be properly synchronized.
SVN r1987 (trunk)
Both Hexen and Heretic depend on such projectiles not doing it as do many
mods that create snow/rain effects plus any terrain splash mod.
SVN r1984 (trunk)
are scaled to the height of a 200 pixel tall sky. Skies taller than 240
use the same scale as a 240 tall sky but are shifted down to make the
top of the texture align with the top of the screen when looking fully up.
Thus, by using a sky texture with a height of 240 or more pixels, the sky
will be drawn with square pixels instead of the vertically elongated ones
imposed by Doom's native 320x200 resolution.
SVN r1978 (trunk)
- Improved sky stretching a bit: It now only stretches the sky as tall as it
needs to be: 228 pixels, not 256. It no longer stretches horizontally,
either.
The reason it stretches to 228 and not 200 pixels is because Doom shifted
its sky texture down 28 pixels. By stretching to 228 pixels, we can keep
the sky tiled at the same height on the horizon. Skies 200 pixels tall
(or more) will continue to tile at the center of the screen when looking
directly ahead.
SVN r1976 (trunk)
time as the polled timer so that the timer does not start running until the
first time it is used.
- Removed the srand() call from D_DoomMain(), because it started the game
timer running prematurely, and we never call rand() anywhere. (Not to
mention, even if we did use rand(), always seeding it with 0 is rather
pointless.)
SVN r1974 (trunk)
unsigned integer that can use all 32 bits. They must therefore use
the unsigned mul instruction rather than the signed imul instruction.
- Fixed several signed/unsigned comparison and possibly uninitialized
variable warnings flagged by GCC.
SVN r1965 (trunk)
player sprites will retain the same precision they had when they were
rendered as part of the 3D view. (needed for propery alignment of flashes
on top of weapon sprites) It worked just fine for D3D, but software
rendering was another matter. I consequently did battle with imprecisions
in the whole masked texture drawing routines that had previously been
partially masked by only drawing on whole pixel boundaries. Particularly,
the tops of posts are calculated by multiplying by spryscale, and the
texture mapping coordinates are calculated by multiplying by dc_iscale
(where dc_iscale = 1 / spryscale). Since these are both 16.16 fixed point
values, there is a significant variance. For best results, the drawing
routines should only use one of these values, but that would mean
introducing division into the inner loop. If the division removed the
necessity for the fudge code in R_DrawMaskedColumn(), would it be worth it?
Or would the divide be slower than the fudging? Or would I be better off
doing it like Build and using transparent pixel checks instead, not
bothering with skipping transparent areas? For now, I chop off the
fractional part of the top coordinate for software drawing, since it was
the easiest thing to do (even if it wasn't the most correct thing to do).
SVN r1955 (trunk)
Christoph Oelckers
Randy Heit