Consequently, if somebody used the chasecam while predicting, they would appear to lag
behind the camera, because their actor would be at its unpredicted position by the time
sprites were processed.
SVN r3603 (trunk)
(e.g. invulnerability). This should only be necessary for SM1.4 cards with buggy drivers. I
doubt the problem is very widespread. The one piece of SM1.4 hardware I obtained specifically
for testing purposes has no problems using shaders for these effects.
SVN r3200 (trunk)
of the field of vision, since it reduces the chances of duplicate sky columns output next to
each other compared to a straight tangent-to-angle calculation.
SVN r3189 (trunk)
- moved all code and data for Build tile management into FTextureManager.
- moved texture animation management into FTextureManager.
- changed: Animate textures only once per frame, not per view. Otherwise with animations that have sub-frame accuracy camera textures of the same area can show different animation frames if the frame changes falls between the rendering of the different views.
SVN r3026 (trunk)
* 0. Do not clear. This is the standard behavior.
* 1. Clear to black.
* 2. Clear to white.
* 3. Alternate between black and white every 128 ms.
* 4. Step through the palette one color at a time every 32 ms.
* 5. Epileptic seizure inducing random colors every frame.
SVN r2491 (trunk)
does not include xtoviewangle[centerx] in the mirroring so that the two columns at the center
of the screen do not map to the same angle. (BTW, this array is only used for the sky drawing.)
SVN r2487 (trunk)
- Added new sprite #### and frame character # to specify the behavior of sprite ---- on a
per-sprite and per-frame basis respectively.
SVN r2291 (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)
changing game code.
- made SpawningMapThing an argument of AActor::StaticSpawn instead of a global
variable.
- added a stub to the DECORATE parser for defining dynamic lights directly
in DECORATE. This is needed so that ZDoom remains compatible with any DECORATE
which uses this GZDoom feature in the future.
SVN r1935 (trunk)
which could cause crashes.
- Added custom special colormaps to DECORATE.
- Cleaned up special colormap code and removed lots of dependencies on the
knowledge of the tables' contents.
SVN r1860 (trunk)
completely ignore them, either).
- Separated light level fixing out of player_t's fixedcolormap parameter.
Using a fixed light level (e.g. PowerTorch) will no longer wipe out
colored lighting.
- Moved the blending rectangle drawing into a separate discrete stage, since
doing it while copying the 3D view window to the display now blends
underneath the weapon instead of on top of it.
- Consolidated the special colormaps into a single 2D table.
- Tweaked the special colormaps slightly to make the true color results more
closely match the paletted approximations.
- fb_d3d9_shaders.h was getting unwieldy, so I moved the shaders out of the
executable and into zdoom.pk3. Shaders are still precompiled so I don't need
to pull in a dependancy on D3DX.
- Added a few more shaders to accomodate drawing weapons with all the in-game
lighting models. These are accessed with the new DrawTexture tags
DTA_SpecialColormap and DTA_ColormapStyle.
- Player weapon sprites are now drawn using Direct3D and receive all the
benefits thereof.
SVN r1858 (trunk)
closer to the original. The old code was shorter but a little slower. The
new code is a bit faster than the original with VC++ and about the same
with GCC. Interestingly, GCC produces code for Killough's version that
performs about the same as the original, but when compiled with VC++,
Killough's is notably worse.
SVN r1813 (trunk)
regardless of pain chance.
- Changed screenblocks CVAR to be settable per game.
- Added SpawnSpotForced and SpawnSpotFacingForced ACS functions.
- Added pushfactor actor property.
SVN r1638 (trunk)
- Fixed: S_ChannelEnded didn't check for a NULL SfxInfo.
- Fixed: R_InitTables did a typecast to angle_t instead of fixed_t.
- Fixed: PowerProtection and PowerDamage applied their defaults incorrectly.
- Fixed: The damage type property didn't properly read its factor.
SVN r1257 (trunk)
so that all files are included by a central one instead of compiling
each one separately. This speeds up the compilation process by 25%
when doing a complete rebuild in Visual C.
- Cleaned up more header dependencies.
SVN r1226 (trunk)
- Made the speed a parameter to A_RaiseMobj and A_SinkMobj and deleted
GetRaiseSpeed and GetSinkSpeed.
- Added some remaining DECORATE conversions for Hexen by Karate Chris.
SVN r1144 (trunk)
registers AMD64 provides, this routine still needs to be written as self-
modifying code for maximum performance. The additional registers do allow
for further optimization over the x86 version by allowing all four pixels
to be in flight at the same time. The end result is that AMD64 ASM is about
2.18 times faster than AMD64 C and about 1.06 times faster than x86 ASM.
(For further comparison, AMD64 C and x86 C are practically the same for
this function.) Should I port any more assembly to AMD64, mvlineasm4 is the
most likely candidate, but it's not used enough at this point to bother.
Also, this may or may not work with Linux at the moment, since it doesn't
have the eh_handler metadata. Win64 is easier, since I just need to
structure the function prologue and epilogue properly and use some
assembler directives/macros to automatically generate the metadata. And
that brings up another point: You need YASM to assemble the AMD64 code,
because NASM doesn't support the Win64 metadata directives.
- Added an SSE version of DoBlending. This is strictly C intrinsics.
VC++ still throws around unneccessary register moves. GCC seems to be
pretty close to optimal, requiring only about 2 cycles/color. They're
both faster than my hand-written MMX routine, so I don't need to feel
bad about not hand-optimizing this for x64 builds.
- Removed an extra instruction from DoBlending_MMX, transposed two
instructions, and unrolled it once, shaving off about 80 cycles from the
time required to blend 256 palette entries. Why? Because I tried writing
a C version of the routine using compiler intrinsics and was appalled by
all the extra movq's VC++ added to the code. GCC was better, but still
generated extra instructions. I only wanted a C version because I can't
use inline assembly with VC++'s x64 compiler, and x64 assembly is a bit
of a pain. (It's a pain because Linux and Windows have different calling
conventions, and you need to maintain extra metadata for functions.) So,
the assembly version stays and the C version stays out.
- Removed all the pixel doubling r_detail modes, since the one platform they
were intended to assist (486) actually sees very little benefit from them.
- Rewrote CheckMMX in C and renamed it to CheckCPU.
- Fixed: CPUID function 0x80000005 is specified to return detailed L1 cache
only for AMD processors, so we must not use it on other architectures, or
we end up overwriting the L1 cache line size with 0 or some other number
we don't actually understand.
SVN r1134 (trunk)
surprised if this doesn't build in Linux right now. The CMakeLists.txt
were checked with MinGW and NMake, but how they fair under Linux is an
unknown to me at this time.
- Converted most sprintf (and all wsprintf) calls to either mysnprintf or
FStrings, depending on the situation.
- Changed the strings in the wbstartstruct to be FStrings.
- Changed myvsnprintf() to output nothing if count is greater than INT_MAX.
This is so that I can use a series of mysnprintf() calls and advance the
pointer for each one. Once the pointer goes beyond the end of the buffer,
the count will go negative, but since it's an unsigned type it will be
seen as excessively huge instead. This should not be a problem, as there's
no reason for ZDoom to be using text buffers larger than 2 GB anywhere.
- Ripped out the disabled bit from FGameConfigFile::MigrateOldConfig().
- Changed CalcMapName() to return an FString instead of a pointer to a static
buffer.
- Changed startmap in d_main.cpp into an FString.
- Changed CheckWarpTransMap() to take an FString& as the first argument.
- Changed d_mapname in g_level.cpp into an FString.
- Changed DoSubstitution() in ct_chat.cpp to place the substitutions in an
FString.
- Fixed: The MAPINFO parser wrote into the string buffer to construct a map
name when given a Hexen map number. This was fine with the old scanner
code, but only a happy coincidence prevents it from crashing with the new
code
- Added the 'B' conversion specifier to StringFormat::VWorker() for printing
binary numbers.
- Added CMake support for building with MinGW, MSYS, and NMake. Linux support
is probably broken until I get around to booting into Linux again. Niceties
provided over the existing Makefiles they're replacing:
* All command-line builds can use the same build system, rather than having
a separate one for MinGW and another for Linux.
* Microsoft's NMake tool is supported as a target.
* Progress meters.
* Parallel makes work from a fresh checkout without needing to be primed
first with a single-threaded make.
* Porting to other architectures should be simplified, whenever that day
comes.
- Replaced the makewad tool with zipdir. This handles the dependency tracking
itself instead of generating an external makefile to do it, since I couldn't
figure out how to generate a makefile with an external tool and include it
with a CMake-generated makefile. Where makewad used a master list of files
to generate the package file, zipdir just zips the entire contents of one or
more directories.
- Added the gdtoa package from netlib's fp library so that ZDoom's printf-style
formatting can be entirely independant of the CRT.
SVN r1082 (trunk)
arbitrary point. It has been replaced with a variant that takes a polyobject
as a source, since that was the only use that couldn't be rewritten with the
other variants. This also fixes the bug that polyobject sounds were not
successfully saved and caused a crash when reloading the game. Note that
this is a significant change to how equality of sound sources is determined,
so some things may not behave quite the same as before. (Which would be a
bug, but hopefully everything still sounds the same.)
SVN r1059 (trunk)
that animated icons can be done with it.
- Changed FImageCollection to use a TArray to hold its data.
- Fixed: SetChanHeadSettings did an assignment instead of comparing
the channel ID witg CHAN_CEILING.
- Changed sound sequence names for animated doors to FNames.
- Automatically fixed: DCeiling didn't properly serialize its texture id.
- Replaced integers as texture ID representation with a specific new type
to track down all potentially incorrect uses and remaining WORDs used
for texture IDs so that more than 32767 or 65535 textures can be defined.
SVN r1036 (trunk)
were doing some things in their destructor that needed to be done in the
Destroy method.
- Rewrote the interpolation code. Interpolations are no longer some objects
that are separate from the rest of the engine. Instead, they are owned by
the thinkers starting them. Also, polyobjects only spawn a single interpolation
for each polyobject instead of a single one for each vertex.
Also, different types of interpolation objects are used for different types
of interpolation so that they can do some additional work if eventually needed.
SVN r1018 (trunk)
