* re-added screen blends for images from the hardware renderer.
* moved all postprocessing of the image out of the renderers.
* cleaned out a large piece of cruft for handling the palette in the frame buffer class. This was all a remnant of the old paletted backend that no longer exists. Nowadays the screen blend is just a postprocessing effect drawn over the 3D screen, there is no need to maintain any of it as global state anymore.
* since the engine doesn't produce paletted screenshots anymore there is no need to have handling for it in the generation code. This depended on otherwise obsolete information so it got removed along with that information.
This was implemented in a way that made it entirely impossible to load Build resources and make them usable for modding.
ZDoom had Build texture support for many years but the limitations the palette handling imposed made it impossible to use them.
It wasn't usable for anything more than to load Build maps and have them display properly - a feature that had to be removed because it was irreparably broken already.
With the forced palette override out of the way it should now be possible to implement loading of Build ART files as actually usable resources.
- moved testcolor and test fades into SWRenderer files.
These CCMDs work by hacking the default colormap and were never implemented for hardware rendering because they require many checks throughout the code.
Some benchmarking shows that on SSE systems it only harms performance and compared to the intrinsics version the gains are too marginal for something this infrequently called.
Doing 100000 calls of DoBlending results in a 5 ms decrease of using assembly vs intrinsics on a 3.4 GHz Core i7, meaning that even on a computer that is 10x slower you can still do 1000 or so blends per frame without a speed hit.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
- Fixed: When locating WhiteIndex and BlackIndex in the palette index 0 was skipped.
- Fixed: When filling an area black for vid_fps or pillarbox/letterbox use GPalette.BlackIndex instead of assuming palette index 0 is black.
SVN r3807 (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)
It must set it to 0 if the alpha is 0 to avoid problems with special
colormap detection.
- Changed SPECIALCOLORMAP_MASK again so that it does not interfere with
any valid setting. It must use a value with a 0-alpha because these
are guaranteed not to be produced by the DECORATE code elsewhere.
- Fixed precision issues with AddFixedColormap's search for identical colormaps.
- Added custom colormap support to texture composition code.
- Fixed initialization of FSpecialColormap::GrayscaleToColor. This is not
a mapping from the palette but from a [0,255] grayscale ramp and used to
apply colormaps to true color images for texture composition.
SVN r1867 (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)
which caused roundoff errors that made it less than 1/3 effective.
- Added support for "RRGGBB" strings to V_GetColor.
- Fixed: Desaturation maps for the TEXTURES lump were calculated incorrectly.
- Changed GetSpriteIndex to cache the last used sprite name so that the code
using this function doesn't have to do it itself.
- Moved some more code for the state parser into p_states.cpp.
- Fixed: TDeletingArray should not try to delete NULL pointers.
SVN r1312 (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)
- Removed AT_GAME_SET because it's no longer used anywhere.
- Converted the last remaining global classes to DECORATE.
- Fixed: Inventory.PickupFlash requires an class name as parameter not an
integer. Some Hexen definitions got it wrong.
- Converted Hexen's Pig to DECORATE.
- Replaced the ActorInfo definitions of all internal inventory classes with
DECORATE definitions.
- Added option to specify a powerup's duration in second by using a negative
number.
SVN r1137 (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)
- Reorganized the HackHack code so that the image creation was moved into
MakeTexture. This was necessary because Unload deleted the pixel data
and broke the whole thing.
- Fixed: FPatchTexture::HackHack and FDoomStatusbarTexture::DrawToBar used the
obsolete and uninitialized variable Near255.
- Removed the span creation code specific to FPatchTexture. It only has an
advantage when the lump has already been loaded in memory but since that
is no longer the case now the generic version in FTexture is actually better.
- Changed: FTexture::CopyToBlock no longer uses the spans but the pixel buffer
directly. Since most patches in multipatch textures are non transparent
the added overhead from creating the spans far outweighs any savings they
might provide. It is also simpler to handle for mirrored or rotated patches now.
- Changed: Textures only create the spans when really needed. Flats and native
textures, for example, do not and it only created needless overhead that they
were always created along with the pixel buffer.
- Made use of player and actor variables consistent in a_hereticweaps.cpp.
- Fixed: A few calls to P_SpawnPlayerMissile passed 0 as angle
SVN r911 (trunk)
