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.
- replaced some uses of FRACUNIT with OPAQUE when it was about translucency.
- simplified some overly complicated translucency multiplications in the SBARINFO code.
- Clang's optional runtime array bounds checking doesn't understand when we
intentionally "overflow" by doing this:
RGB32k[0][0][colorval]
It will warn that it was accessed at an index will past the bounds
of type 'BYTE [32]', which makes it less than useful for catching real
array bounds overflows. So now do this:
RGB32k.All[colorval]
And if you want this:
RGB32k[r][g][b]
Now do this:
RGB32k.RGB[r][g][b]
- allow setting 'Shadow' as default fuzz effect
- changed CVAR conversion that strings 'false' and 'true' get evaluated as integers 0 and 1 respectively so that changing boolean CVARs to int does not destroy their values.
SVN r3076 (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)
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)
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)
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)
They are not needed anywhere else.
- Changed the HackHack hack for corrupt 256 pixel high textures that
FMultiPatchTexture only calls a virtual function instead of doing any
type checks of the patch itself.
- Cleaned up the constant definitions in doomdata.h.
- Moved the TEXTUREx structures from doomdata.h to multipatchtexture.cpp
because they are used only in this one file.
- Removed some more typedefs from r_defs.h and doomdata.h
- Moved local polyobject data definitions from p_local.h to po_man.cpp.
SVN r1012 (trunk)
drawing function. The most improvement came from being able to turn some
constant variables into immediate values with self-modifying code, but I
also managed to reorder it to make it a little faster. It's about 9% faster
than VC++'s code and 19% faster than GCC's code. That's not a huge
improvement (for VC++), but at least it's measurable.
- Removed the solid fill "optimization" from rt_shaded4cols(), because in my
testing, it didn't help any and in fact, hurt just a little bit.
- In the name of simplification, all the rt_tlate* drawers were changed to do
the translation in one step and the drawing in another. This lets me call
the untranslated drawer to do the real drawing instead of mostly duplicating
them. Performance wise, there is practically no difference from before.
SVN r771 (trunk)
