The fix (adding adjustment of fRenderInfo.fDestPtr) made kRenderJustXForceLeft behave as intended (left-aligning the edge of the bitmap rather than the side bearing of the first character) but cuts off shadows in some places (e.g. at the left edges of "BUDDIES" and "NEIGHBORS" in the mini KI). To ensure enough space for the shadow, and considering that all content was developed and visually optimized with the bug in place, it seems better to preserve the buggy behavior and make kRenderJustXForceLeft work exactly like kRenderJustXLeft.
Intended to make KI text (player list and chat) better readable on light and patterned backgrounds. In this WIP, all text on GUI controls is rendered shadowed.
This fixes the irregular dark fringes around light text when not exactly pixel-aligned that are caused by independent interpolation of color and alpha. It also makes calculations simpler for things to come.
In addition to being a prerequisite for shadowed text, this also fixes an issue sometimes seen at the bottom of the mini KI player list where characters with a descender were missing.
We already link against it, so that's just a waste of time. Also, cleanup
some unneeded ddraw includes. Remember that in Direct3D9, all devices can
render in windowed mode.
This changeset introduced a new plBitmap flag `kAutoGenMipmap`, which
trickles through the pipeline and becomes `D3DUSAGE_AUTOGENMIPMAP` in
standard DirectX texture creation. This flag is applied to all
DyanmicTextMaps. The end result is that DynamicTextMaps become fuzzy at a
distance, rather than choppy.
This is the beginning of efforts to reduce the scope of Windows.h. I have
shuttled it into hsWindows.h (again) and fixed the compilation of the
major apps. There is still some scope work that needs to be done, and the
Max plugin has not yet been addressed.
- plRefCnt duplicates hsRefCnt (Wtf?)
- hsNamedPipeStream nasty, unused
- VDB stuff in hsStream left over from Plasma 1 (realMyst/DIRT)
- hsColor32 moved to be less promiscuous
Rearrange some things so such that low-level CoreLib headers aren't quite
so crazy. For higher level stuff, you still need to include the
appropriate header.
Function and macro names for endianness were previously vague,
and on big-endian systems entirely misleading. The names are
now properly descriptive of what they actually do.
